This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
This table gives an overview of the major releases of the Specification. Detailed information about the 102
history of this document can be seen in “App. 2 Detailed History”. 103
104
Vers. State Date Author / Chapter Short description
1.0 WDP 6.5.2005 F.Kaufleitner B&R Base Document for TUV Concept approval
EPLsafetyProfile-V-1.0.doc
1.0.3 FWDP 19.10.2005 F.Kaufleitner B&R Changes due to TÜV meeting,
Version Released by TÜV EPLsafetyProfile-V1.03.doc
1.0.7b WDP 16.10.2007 F.Kaufleitner B&R Document for TUV Concept approval
EPLsafetyProfile-V1.07b.doc
Major changes with safety related aspects since version 1.03
Sub frame one AND sub frame two now uses the same CRC (CRC8, CRC16) polynomial. This has no effect on the immunity against data corruption, but it allows a much more simple implementation. Dedicated changes in chapter 5 and 8.
Sub frame two is additionally coded with the UDID of the corresponding SCM. This enables the possibility to detect errors when the same safety related application is installed identically within one network and the previous required openSAFETY domain separation (ether by firewall or unique SDN) fails. As a result, the requirement of an openSAFETY domain separation has been discarded. Dedicated changes in chapter 2 and 5.
Certificate No 968/EZ 300.00 / 08 by TÜV Rhineland
1.0.8 WDP 30.07.2008 Franz Kaufleitner B&R
EPSG WDP 304 V-1-0-8.doc
Major Changes with safety related aspects since version 1.07b
New openSAFETY frame type added for realizing “slim” SSDO services transporting more data and using the same bandwidth. This allows faster network startup. Changes in chapter 5.
New openSAFETY SSDO Service for realizing a “block Transfer” transporting data without acknowledge. This allows faster network startup. Changes in chapter 5.
Correction in segmented transfer (chapter 5.3.2.2) to get additionally bytes of payload data by not sending index/subindex all the time. This allows faster network startup.
“Connection Valid” bit added to SPDO protocol for being able to know when the data consumer is ready to really take over the data. This allows easier handling of safe output modules. Changes in chapter 5
New SOD crc which required changes in chapter 5 and 6. The new SOD crc allows the parameterization without requiring the services used for the parameterization to be safe.
1.1.0 WDP 29.10.2009 F.Kaufleitner B&R Base Document for EPSG & TÜV approval
EPSG WDP 304 V-1-1-0.doc
1.1.1 WDP 13.01.2010 F.Kaufleitner B&R
EPSG WDP 304 V-1-1-1.doc
Correction in processing data to avoid taking over a “frozen” RxSPDO frame (chapter 5.7.1.2.1)
Some minor changes due to TÜV certification
1.1.2 WDP 16.02.2010 F.Kaufleitner B&R
EPSG WDP 304 V-1-1-2.doc
Some minor changes due to TÜV certification
1.1.3 WDP 27.4.2010 F.Kaufleitner B&R Renaming POWERLINK safety to openSAFETY
1.1.4 WDP 15.3.2011 F.Kaufleitner B&R Base Document for EPSG & TÜV approval
EPSG WDP 304 V-1-1-4.doc
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 6/191
Major Changes with safety related aspects since version 1.1.3
Due to IEC 61508:ED2, security aspects updated: 2.3.2.1
CRC polynomial for frames with more than 8 byte payload changed to 0xBAAD: 5.1.1.8
Unclear specification elements within block transfer corrected: 5.3.1, 5.3.2.3, 5.3.2.7, 5.3.2.8
Abort code corrected: 5.3.2.9
Calculation for residual error probability updated: 8.1, 8.2, 8.3
New optional features:
o Number of Retries for Reset Guarding: 5.6.4, 5.6.4.6, 5.6.4.7, 5.7.6.2
o User Parameter (writeable at any time): 5.6.4, 5.6.4.18, 5.7.4
1.4.0 WDP 13.03.2013 R.Knall B&R
EPSG WDP 304 V-1-4-0.docx
Document version adapted according to the numbering for the openSAFETY certification set
Rearrange chapter “Parameterization Interface of SOD”
Document corrections since version 1.1.4
o Corrected calculation information for the basic and slim ssdo openSAFETY frames: 5.1.1.1
o Text changes to clarify meaning: 5.1.1.5, 5.2.1, 5.3, 5.3.1, 5.3.2.6, 5.6.4.6, 5.6.4.7, 5.6.4.8, 5.6.4.22, 5.7.10
o EPLv2 changed to Fieldbus, EPLsafety changed to openSAFETY: 7.2
o Corrected number of entries for SOD objects: 5.6.4.11, 5.6.4.12, 5.6.4.15, 5.6.4.20
o Corrected package diagram, to correctly identify timestamp instead of crc: 5.4.3.2
Major Changes with safety related aspects since version 1.1.4
openSAFETY Stack Version identification
o 0x1018 – Adding sub-index 0x08 and 0x09 to identify stack version: 5.6.4.8
o Process definition Fig. 77
Error handling improvements
o 0xC400 – Changing the numbering of the module status: 5.6.4.20
o Introducing object for collecting error statistics for a stack implementation: 5.6.4.4
Clarified wording, that SLIM SSDOs are not allowed for user parameter: 5.6.4.18
No longer part of SOD CRC due to no relevance for SN:
o 0x101B - SCM Parameters: 5.6.4.11
o 0x1201 – SSDO Communication Parameters: 5.6.4.13
o 0x1202 – SNMT Communication Parameters: 5.6.4.14
Additional parameter Sets :
o Description of error group/code handling with additional parameters: 5.4.3.2.1
o 0xC400-0xC4FE – Ability switch for a module to accept additional parameters: 5.6.4.20
o 0xE400-0xE4FE – SOD object to store additional parameter sets on SN: 5.6.4.23
o Adapting SN Power Up state diagram to implement additional parameter checks: 5.7.6.2, 5.7.6.3
Fig. 68. State diagram “SN Pre-Operational” 155 526
Fig. 69. State diagram “Check Additional Parameters” 157 527
Fig. 70. State diagram “SN Operational” 159 528
Fig. 71. Life guarding telegram 159 529
Fig. 72. State diagram “SCM Power Up” 160 530
Fig. 73. State diagram “SCM Operational” 161 531
Fig. 74. State diagram “SCM Safety Address Verification” 163 532
Fig. 75. State diagram “SCM Handle Single UDID Mismatch” 165 533
Fig. 76. State diagram “SCM Verify Parameters” 167 534
Fig. 77. State diagram “Handle SN version” 169 535
Fig. 78. State diagram “Activate SN“ 171 536
Fig. 79. Change Management Flow of Specification 174 537
Fig. 80. Certification flow of openSAFETY devices – e.g. on POWERLINK 175 538
Fig. 81. openSAFETY Logo 175 539
Fig. 82. Structure of POWERLINK safety frame 178 540
Fig. 83. System architecture for SIL 3 application (principle structure) 183 541
542
543
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 17/191
Equations 544
Equation 1. Calculation of time Syncrhonization Frequency 137 545
Equation 2. Binomial distribution, probability for “e” corrupted bits within a sub frame 179 546
Equation 3. Hyper-geometric distribution 179 547
Equation 4. Reduction of residual error probability by duplication of data 179 548
Equation 5. Reduction of residual error probability by proper polynomials 179 549
Equation 6. Reduction of residual error probability by data expectation 180 550
Equation 7. Final residual error probability of openSAFETY 180 551
Equation 8. Maximum message Rate per second to claim SIL 3 180 552
553
554
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 18/191
Definitions and Abbreviations 555
For Definitions and Abbreviations of POWERLINK Terms see the POWERLINK Specification. 556
557
Definitions 558
559
Device Vendor Information (DVI) Information for identifying a Safety Node
openSAFETY Layer The openSAFETY Layer defines services to fulfill the requirements of IEC 61508 / SIL 3 for reliability and safety.
openSAFETY Domain (SD) Address space for up to 1023 Safety Nodes
openSAFETY Address (SADR) Address of a Safety Node within an openSAFETY Domain
openSAFETY Domain Number (SDN)
Identification of an openSAFETY Domain
openSAFETY Network Management (SNMT)
Services for openSAFETY Layer Management
openSAFETY Object Dictionary (SOD)
Repository of all data objects accessible over openSAFETY Communication
openSAFETY Process Data Object (SPDO)
Object for process data exchange between openSAFETY Nodes
openSAFETY Service Data Object (SSDO)
Object for service data exchange between openSAFETY Nodes
Safety Node (SN) Node with any safety related function
Safety Configuration Manager (SCM)
Service which is responsible to manage safety related services such as configuration, parameterization and others. Each network with safety related features needs at least one SCM.
openSAFETY Domain Gateway (SDG)
Gateway to share data between different openSAFETY Domains
Unique Device Identification (UDID)
World wide unique identification of a device
560
Abbreviations 561
562
1oo1 One out of One (single channel) Architecture
1oo2 One out of Two Architecture
ACM Automatic Configuration Mode
ADR Address information (source or destination)
BGIA Berufsgenossenschaftliches Institut für Arbeitsschutz
CAN Controller Area Network
CN POWERLINK Control Node
CRC Cyclic Redundancy Check
CT Consecutive Time field (time stamp within a safety frame)
DBx Data Byte
DVI Device Vendor Information
DSADR Destination SADR
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 19/191
POWERLINK Ethernet POWERLINK
ID Frame Identification
IP Internet Protocol
LE Length field (specifies number of payload data bytes within a safety frame)
LSB Least Significant Byte
MCM Manual Configuration Mode
MN POWERLINK Managing Node
MSB Most Significant Byte
RxSPDO openSAFETY Receive Process data objects
SADR openSAFETY Address
SCM openSAFETY Configuration Manager
SCT Safety Control Time
SD openSAFETY Domain
SDG openSAFETY Domain Gateway
SDN openSAFETY Domain Number
SIL Safety Integrity Level
SN openSAFETY Node
SNMT openSAFETY Network Management
SOD openSAFETY Object Dictionary
SPDO openSAFETY Process Data Object
SPST Safe parameterization tool
SSDO openSAFETY Service Data Object
SSADR Source SADR
TADR Additional SADR for timing information
TCP Transport Control Protocol
TR Time Request Distinctive Number
TReq Time Synchronization Request
TRes Time Synchronization Response
TÜV Technischer Überwachungsverein
TxSPDO openSAFETY Transmit Process data objects
UDID Unique Device Identification
UDP User Datagram Protocol
563
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 20/191
References 564
[1]: Grundsatz für die Prüfung und Zulassung von „Bussystemen für die Übertragung 565
The Commissioner has to acknowledge each device 881
3.2.2.2 Configuration Setup using MCM 882
The commissioner has to enter the list of possible SADRs with the corresponding UDIDs 883
manually, therefore a safety related configuration tool must be used 884
The SCM will accept all configured SADR / UDID combinations 885
The SCM will not accept mismatches and will not repair mismatches as done in the ACM. This 886
means, all mismatches must be corrected by the commissioner by entering the corrected 887
value using the safety related configuration tool 888
3.2.3 Verification 889
The commissioner has to verify the safety functionality against the safety specification for the 890
application. In the case of device replacements or changes in the routing within the 891
communication layer, the commissioner has to continue with step 3.2.2. 892
893
If verification is carried out during commissioning, all combinations of exchangeable modules 894
must be verified. This is especially important in the case of complex modular machines (in 895
combination with MCM). 896
897
If verification is carried out due to maintenance, only the safety related functionality affected by 898
the maintenance task must be verified. 899
900
When verification is finished, an installation specific backup of the current configuration should 901
be made. 902
903
In case of an SCM replacement, a download of application files, parameters, and the 904
configuration has to be done otherwise the commissioning steps (installation, configuration 905
and verification) must be repeated. 906
907
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 33/191
3.3 Operation Terms 908
3.3.1 Transfer of Safety related Data 909
During operation, the safety related data transfer is handled by openSAFETY. The underlying network 910
is responsible for the data transport between the nodes with a defined timing quality. Loss of timing or 911
transport quality within the underlying communication layer is detected by the openSAFETY layer 912
(see chapter 5.7.2) and will result in loss of availability, but not in loss of safety. 913
914
Fig. 9. openSAFETY data flow example 915
3.3.2 Time Synchronization and Validation 916
In order to avoid any missed or sudden delays of data, network performance verification has to be 917
done. From time to time each consumer has to ask all connected producers for their relative time. By 918
comparing of the relative time, the elapsed time and the time information from any transfer, the 919
consumer will be able to check the topicality of the received data. 920
921
The network performance verification is a sequence during data transfer. At first a consumer sends a 922
“Time Request” message to the connected producer. After receiving this information the producer 923
sends its data with an additional code, which enables the consumer to identify this message as a 924
“Time Response”. By measuring the time delay between the “Time Request” and the “Time 925
Response”, the consumer is able to check whether the network is fast enough to meet the 926
requirements of the application depending on the worst case reaction time. 927
For a detailed description refer to chapter 5.7.2. 928
3.3.3 Life Guarding 929
With the service “life guarding” (see chapter 5.6.4.4) openSAFETY makes sure that only configured 930
SNs are operational in an openSAFETY network. SNs need an openSAFETY life guarding signal to 931
remain in the operational status. Otherwise they will go to pre-operational and therefore no longer 932
being a risk for the safety related network. 933
934
The interval of the life guarding signal is application specific, and is normally determined by the 935
amount of time needed to verify the safety functions of the application. 936
937
With organizational measurements, like switching off all SNs in case of reconfiguring the SCM, the risk 938
in this situation may be eliminated. As a result, the interval for the life guarding signal may be set to a 939
very large value (several days) for these cases. 940
SDN 2
Producer Consumer
SDN 1
Producer Consumer
SN1 SCM
SN2
SN3
SN3
SCM
SN4 SDG SN2
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 34/191
3.3.4 Startup after Power up or Reset 941
After Power Up the SCM (see chapter 5.7.9) handles the network verification. If there was no change 942
within the network, no special tasks are required. 943
3.3.5 Recover from Network Failure 944
Following a network breakdown, all affected SNs will enter the pre-operational state. Since 945
corresponding consumer SNs will get no further data, these nodes will enter the fail state. 946
After recovery of the network, all affected SNs send an SNMT_SN_in_PRE_OP service to the SCM. 947
The SCM then will start with the initialization of the SNs. 948
3.4 Maintenance Terms 949
3.4.1 Diagnostic Information 950
Diagnostic Information according to chapter 5.6.4 will be stored in the object 1001h, 1002h, 1003h by 951
the SN. This information can be read by the non safety related application. 952
3.4.2 Replace safety related devices 953
3.4.2.1 SN Replacement 954
After replacing the affected SNs, the maintenance technician has to decide: 955
If only one SN is replaced, is the SCM able to handle the replacement automatically? Only a 956
simple confirmation by the maintenance technician is requested. 957
If more than one SN is replaced, the configuration (see chapter 3.2.2) must be repeated and 958
verification of the safety functionality of the replaced SNs must be done (see chapter 3.2.3). 959
3.4.2.2 Replacement of SN running the SCM 960
If the configuration and the application with the corresponding parameters are available after the 961
replacement, the SCM replacement has no influence on the safety functions. If any data is lost, the 962
steps according to 3.2 must be repeated. In accordance with 3.2.3, a complete verification is 963
necessary (as it is required during commissioning). 964
3.4.3 Modification 965
After modification, the steps according to 3.2 must be repeated. In accordance with 3.2.3, a complete 966
verification is necessary (as it is required during commissioning). 967
968
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 35/191
3.4.4 Machine part changing 969
All changeable machine parts have to be verified against the safety specification for the application at 970
least one time according to the procedure listed in 3.2.3. After verification, the SCM knows the 971
configuration for all changeable machine parts, this means that after changing machine parts, no 972
further steps are required. 973
974
Open input situations due to missing producers after machine part changes must be handled by the 975
application. 976
3.4.5 Firmware update of safety related nodes 977
A firmware update for a safety related node is a vendor specific task. There is no service within 978
openSAFETY to support this task. 979
3.4.6 Machine check due to service interval 980
openSAFETY requires no special check. 981
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 36/191
4 Non safe Communication Layer 982
4.1 Requirements to Data Transport 983
The communication layer is responsible for transporting the data between the SNs. The coexistence of 984
standard nodes and safety related nodes is allowed. To avoid any possibilities of masquerading as 985
openSAFETY frames, non openSAFETY related nodes may not contain code which is able to 986
generate openSAFETY frames according to chapter 5 of this specification. 987
988
The communication layer is permitted to carry out read only access of data within the openSAFETY 989
frame. This must be done by accessing the data within the openSAFETY frame without using the 990
openSAFETY frame specific data corruption methods, such as CRC and data repetition of sub frame 1 991
in sub frame 2. 992
4.1.1 Transport of SPDO 993
The communication layer has to transport the SPDO data between the SNs. When using the Internet 994
in connection with openSAFETY, the established methods for encryption (Virtual Private Network, 995
VPN) have to be used. Within local area networks, organizational actions like firewalls have to be 996
implemented. 997
4.1.2 Transport of SSDO 998
The communication layer has to transport the SSDO data between the SNs. When using the Internet 999
in connection with openSAFETY, the established methods for encryption (Virtual Private Network, 1000
VPN) have to be used. Within local area networks, organizational actions like firewalls have to be 1001
implemented. 1002
4.2 Representation of Diagnostic Data 1003
The communication layer has to support services to provide openSAFETY specific diagnostic data 1004
according to chapter 5 of this specification. 1005
4.3 Safety Domain Protection and Separation 1006
In accordance with chapter 2 of this specification, the communication layer has to support proper 1007
security features to protect the openSAFETY domain against attacks from outside and to avoid 1008
interferences between separated openSAFETY domains. 1009
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 37/191
5 openSAFETY Layer 1010
5.1 openSAFETY Data Services 1011
5.1.1 Structure of openSAFETY Frame 1012
5.1.1.1 Basic openSAFETY Frame 1013
This chapter shows the structure of the Basic openSAFETY frame. The frame consists of two sub 1014
frames and is able to transport data up to 254 bytes of payload data. The error probability and the 1015
hamming distance in relation to the frame length can be viewed in Chapter 8. The frame uses two 1016
kinds of CRCs depending on the length of the payload data: 1017
1018
1019
Fig. 10. Data format of a basic openSAFETY frame up to 8 byte of payload data 1020
1021
Fig. 11. Data format of a basic openSAFETY frame from 9 byte of payload data 1022
1023
ID ADR LE CT(L) DB0 CRC16 DBn ID ADR CT(M) TR TADR DB0 CRC16
sub frame one / sub frame two
DBn
SDN
UDID of SCM
sub frame one / sub frame two
ID
ADR
LE CT(L) DB0 CRC8 DBn ID ADR CT(M) DB0 CRC8 DBn TR TADR
SDN
UDID of SCM
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 38/191
1024
Bit Offset
Octet Offset1 7 6 5 4 3 2 1 0
0 ADR (Bit 0-7)
1 ID ADR (8,9)
2 LE
3 CT (Bit 0-7)
4 … (n-1)+4 DB 0 to DB n
n+4 … n+4+o CRC-8 / CRC-16
n+5+o ADR (Bit 0-7) XOR SDN (Bit 0-7)
n+6+o ID ADR (8,9) XOR SDN (8,9)
n+7+o CT (Bit 8-15)
n+8+o TADR (Bit 0-7)
n+9+o TR TADR (8,9)
n+10+o … 2n+9+o DB 0 to DB n
2n+10+o … 2n+10+2o CRC-8 / CRC-16
Tab. 1 Basic openSAFETY frame 1025
Table Tab. 1 shows the structure of the Basic openSAFETY frame. The frame may be devided in two 1026
sub frames, called sub frame one and sub frame two. The grey colored lines within table Tab. 1 1027
indicate sub frame two. Sub frame two of SPDO and SSDO Frames (not SNMT Frames) are 1028
additionally coded with the UDID of the SCM using a logical XOR operation (see chapter 5.1.1.11). 1029
1030
The formula for the end position for the safety payload in the second frame is calculated baring the 1031
end position of the first frame in mind: ( ) . By reducing the formula the result is : 1032
. 1033
1034
1 Octet Offset refers to the start of the openSAFETY telegram.
n … number of payload data in bytes 0 ≤ n ≤ 254 o … CRC correction offset 0 ≤ n ≤ 8 o = 0 (CRC 8) 9 ≤ n ≤ 254 o = 1 (CRC16)
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 39/191
5.1.1.2 Slim SSDO openSAFETY Frame 1035
This chapter shows the structure of the Slim SSDO openSAFETY frame. The frame consists of two 1036
sub frames and is able to transport data up to 254 bytes of payload data. The error probability and the 1037
hamming distance in relation to the frame length can be viewed in Chapter 8. The frame uses two 1038
kinds of CRCs depending on the length of the payload data: 1039
1040
Fig. 12. Data format of a slim SSDO frame up to 8 byte of payload data 1041
1042
Fig. 13. Data format of a slim SSDO frame from 9 byte of payload data 1043
1044
Bit Offset
Octet Offset2 7 6 5 4 3 2 1 0
0 ADR (Bit 0-7)
1 ID ADR (8,9)
2 LE
3 CT (Bit 0-7)
4 … (n-1)+4 DB 0 to DB n
n+4 … n+4+o CRC-8 / CRC-16
n+5+o ADR (Bit 0-7) XOR SDN (Bit 0-7)
n+6+o ID ADR (8,9) XOR SDN (8,9)
n+7+o CT (Bit 8-15)
n+8+o TADR (Bit 0-7)
n+9+o TR TADR (8,9)
n+10+o … n+10+2o CRC-8 / CRC-16
Tab. 2 Slim SSDO openSAFETY frame 1045
Table Tab. 2 shows the structure of the Slim SSDO openSAFETY frame. The frame may be devided 1046
in two sub frames, called sub frame one and sub frame two. The grey colored lines within table Tab. 2 1047
indicate the data of sub frame two. The data of sub frame two is additionally coded with the UDID of 1048
the SCM using a logical XOR operation (see chapter 5.1.1.11). 1049
2 Octet Offset refers to the start of the openSAFETY telegram.
n … number of payload data in bytes 0 ≤ n ≤ 254 o … CRC correction offset 0 ≤ n ≤ 8 o = 0 (CRC 8) 9 ≤ n ≤ 254 o = 1 (CRC16)
sub frame one / sub frame two
ID ADR LE CT(L) DB0 CRC8 DBn ID ADR CT(M) CRC8 TR TADR
SDN
UDID of SCM
ID ADR LE CT(L) DB0 CRC16 DBn ID ADR CT(M) TR TADR CRC16
sub frame one / sub frame two
SDN
UDID of SCM
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 40/191
5.1.1.3 Address Field (ADR) 1050
The address field (ADR) defines the SADR of the SN. The field is a 10 bit value. By using the address, 1051
1023 devices can be addressed (ADR = 0 is not allowed). 1052
1053
The address Field within the second sub frame is also used to carry the openSAFETY domain number 1054
(SDN) information using a logical XOR operation (see chapter 5.1.1). 1055
1056
The ADR field may contain the SADR of the SN from which the frame is sent (source address) or for 1057
which the frame is designated (destination address). The source address is the SADR of the SN which 1058
sends the telegram, the destination address is the SADR of the SN which the telegram is sent to. 1059
1060
According the content of the ADR fields of both sub frames, the non safe communication layer is able 1061
to transport the data to the designated destination node without additional analyzing the ID field or 1062
other openSAFETY specific frame attributes. 1063
1064
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 41/191
5.1.1.4 ID Field (Frame Identification) 1065
The ID field identifies the frame. The following tables show the coding of the ID field. Reserved codes 1066
may be used in future specifications and may not be used, or ignored if received by actual nodes: 1067
Bit Offset
7 6 5 4 3 2 1 0
0 0 0 0 0 x
bit 9
of th
e
addre
ss fie
ld
bit 8
of th
e
addre
ss fie
ld
Not allowed (illegal Frame)
0 x X x x x reserved
1 0 0 x x x reserved
1 0 1 x x x SNMT
1 1 0 x x x SPDO
1 1 1 x x x SSDO
Tab. 3 Avaiable frame types 1068
For identification of the openSAFETY frame type, bits 5, 6 and 7 are used. Each frame type has 1069
different telegram types which are coded in bit 2, 3 and 4 of the ID field. The following table shows all 1070
used ID field combinations. 1071
Bit Offset
7 6 5 4 3 2 1 0
1 0 1 0 0 0
bit 9
of th
e a
ddre
ss f
ield
bit 8
of th
e a
ddre
ss f
ield
SNMT_Request_UDID
1 0 1 0 0 1 SNMT_Response_UDID
1 0 1 0 1 0 SNMT_Assign_SADR
1 0 1 0 1 1 SNMT_SADR_assigned
1 0 1 1 0 0 SNMT_Service_Request
1 0 1 1 0 1 SNMT_Service_Response
1 0 1 1 1 1 SNMT_SN_reset_guarding_SCM
1 1 0 0 0 x SPDO_Data_Only
1 1 0 0 1 x SPDO_Data_with_Time_Request
1 1 0 1 0 x SPDO_Data_with_Time_Response
1 1 1 0 0 0 SSDO_Service_Request
1 1 1 0 0 1 SSDO_Service_Response
1 1 1 0 1 0 SSDO_Service_Request_Slim
1 1 1 0 1 1 SSDO_Service_Response_Slim
Tab. 4 Used ID field combinations 1072
SSDO and SNMT services are divided into request and response telegrams. Bit 2 of the ID field is 1073
used to identify whether the telegram is a request or a response. 1074
Bit Offset
7 6 5 4 3 2 1 0
x x x x x 0 SSDO / SNMT Request
x x x x x 1 SSDO / SNMT Response
Tab. 5 Request / response identification 1075
Bits 0 and 1 of the byte where the ID field is located are used by the address field (see Tab. 1) 1076
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 42/191
5.1.1.5 Length Field (LE) 1077
The length field defines the number of payload data bytes within the frame. The acceptable value 1078
range is 0 – 240. This field additionally determines the type of CRC used for the frame. 1079
1080
LE value of Length Field Used CRC
LE value 0 – 8 CRC-8
LE value 9 – 240 CRC-16
LE value 241-255 reserved
Tab. 6 Relation between Length Field and used CRC 1081
5.1.1.6 Consecutive Time Field (CT) 1082
The consecutive time field is divided in an LSB part which is sent in sub frame one and an MSB part 1083
which is sent in sub frame two. Both 8 bit data sets together build the CT data set with a number range 1084
of 0 – 65535. The CT field is used for the internal timer value of the SN when sending the frame in 1085
case of an SPDO (see chapter 5.2), in case of an SSDO, the CT field describes the SOD access 1086
request number (see chapter 5.3.2). 1087
1088
The time base of the CT field is defined in object 1200h sub index 3h (see chapter 5.6.4.12). 1089
5.1.1.7 Payload Data Field (DB0 to DBn) 1090
This field contains the payload data. openSAFETY supports a payload data length from 0 up to 254 1091
bytes. Payload data length of 0 may be used for time synchronization services (see 5.2.3, 5.2.4). 1092
5.1.1.8 Cyclic Redundancy Check Field (CRC-8 / CRC-16) 1093
This field contains the CRC checksum for the sub frame(1 or 2) which is calculated using one of the 1094
polynoms referenced in table 7. The type of polynom used depends on the LE value and on the Frame 1095
Identfication. The error probability as well as the expected hamming distance is shown in 8.3.2. 1096
1097
Intended use Polynom Polynom Polynom according Reference [3]
Payload Data up to 8 Byte X8+X
5+X
3+X
2+X+1 12Fhex 0x97
Payload Data up from 9 Byte, SLIM SSOD Services only
X16
+X14
+X12
+X11
+X8+X
5+X
4+X
2+1 15935hex 0xAC9A
Payload Data up from 9 Byte, all services except SLIM SSDO
X16
+X14
+X13
+X12
+X10
+X8+X
6+X
4+X
3+
X+1 1755Bhex 0xBAAD
Tab. 7 CRC Polynoms 1098
1099
5.1.1.8.1 Rules for CRC generation: 1100
Seed value is 0 for CRC-8 as well as for CRC-16 1101
The most significant bit of the first byte is shifted in first 1102
The CRC will be calculated over all fields of the subframe excluding the CRC 1103
o Sub frame one: ADR, ID, LE, CT(L), DB0 – DBn 1104
o Sub frame two: ADR, ID, CT(H), TADR, TR, DB0-DBn 1105
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 43/191
The CRC-8 follows the encoding rules of an UNSIGNED8 data type (see chapter 5.5.4.4). 1106
The CRC-16 follows the encoding rules of an UNSIGNED16 data type (see chapter 5.5.4.4). 1107
5.1.1.9 Time Request Address (TADR) 1108
In case of SPDO (see chapter 5.2) this field is used as an additional SADR field for the address of an 1109
SN which responds to the time synchronization request. 1110
For SSDO and SNMT this field represents either a source or destination SN address (see chapter 5.3, 1111
5.4) 1112
5.1.1.10 a SN Time Request Distinctive Number Field (TR) 1113
The time request distinctive number is a number between 0 and 63, which will be mirrored by the 1114
device in order to distinguish this message from other time request messages. 1115
5.1.1.11 UDID of SCM coding (UDID of SCM) 1116
The 6 Byte UDID of the SCM is coded using a logical XOR operation to the first 6 bytes of sub frame 1117
two of SPDO and SSDO services. SNMT service is not coded. By doing this, mismatches in the 1118
openSAFETY Domain separation (see 2.3.2.2) will be detected. 1119
1120
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 44/191
5.2 Safety Process Data Object (SPDO) 1121
SPDOs are used for transmitting safety-critical process data as well as time synchronization 1122
request/response data from an SPDO producer to the SPDO consumers. Reception of an SPDO by 1123
an SPDO consumer is determined by the address of the SPDO producer. 1124
5.2.1 SPDO Frame Types 1125
The ID field (bit 2-4) identifies the SDPO frame type. Three different frame types are distinguished: 1126
Data Only frames 1127
Data with Time Request frames 1128
Data with Time Response frames 1129
1130
Following Table shows the coding of the ID field: 1131
1132
Bit Number of ID Field Frame Type
7 6 5 4 3 2 1 0
1 1 0 0 0 X bit 8,9 of
the address
field
SPDO_Data_Only
1 1 0 0 1 X SPDO_Data_with_Time_Request
1 1 0 1 0 X SPDO_Data_with_Time_Response
1 1 0 1 1 X Reserved
Tab. 8 SPDO Frame Types (ID Field, Bits 3,4) 1133
Bit 2 is used as a “connection valid” bit. If the time synchronization of all RxSPDOs to be synchronized 1134
over the TxSPDO is ok, the bit is set to 1b, otherwise it is to be set to 0b. 1135
1136
Example: 1137
We have an SN with 3 RxSPDOs and 2 TxSPDOs. RxSPDO 1 and 2 are to be synchronized 1138
using TxSPDO 1. RxSPDO 3 is to be synchronized using TxSPDO 2. 1139
The synchronization of RxSPDO 1 is not OK. 1140
The synchronization of RxSPDO 2 and 3 is OK. 1141
The TxSPDO 1 is to be sent with the connection valid bit set to 0b (RxSPDO 1 not OK && 1142
RxSPDO 2 OK -> not OK). 1143
The TxSPDO 2 is to be sent with the connection valid bit set to 1b (RxSPDO 3 OK). 1144
1145
Typically every RxSPDO does have its own TxSPDO for synchronization. The connection valid bit is 1146
used by a producer to signal to it’s consumers that the payload data sent by the producer is valid and 1147
the time synchronization for this channel has been performed successfully. 1148
1149
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 45/191
5.2.2 Data Only Frame 1150
The Data Only Frame is used to transmit process data from an SN (SPDO producer) without a time 1151
synchronization request or response. The data can be consumed by any other SN (SPDO consumer). 1152
1153
Together with the data (Data), the SPDO producer provides its SN address (ADR) as well as the 1154
number of payload data bytes transmitted (LE) and the current value of its internal timer (CT). 1155
1156
SPDO Producer
ADR
SSADR
ID
SPDO_
Data_Only
LE
Payload
Length
CT
Internal
Time
Data
Payload
Data
TR
0
TADR
0
Indication
Indication
Indication
Request
SPDO Consumers
1157
Fig. 14. SPDO Data Only Frame 1158
Field Information Content / Value
ADR Address of SPDO producer SSADR
ID SPDO_Data_only 11000xxxb
LE Number of payload data bytes 0 - 254
CT Internal time value of SPDO producer Time
Data Payload data Data
TR Not used 0
TADR Not used 0
Tab. 9 SPDO Data Only Frame 1159
1160
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 46/191
5.2.3 Data with Time Request Frame 1161
The Data with Time Request Frame is used to transmit process data from a SN (SPDO producer) with 1162
a time synchronization request to another SN addressed via TADR. The data can be consumed by 1163
any other SN (SPDO consumer). 1164
Together with the data (Data), the SPDO producer provides its SN address (ADR), the frame type (ID) 1165
as well as the number of payload data bytes (LE) transmitted, the current value of its internal timer 1166
(CT), a counter value for indicating the number of time requests (TR) and the address of the SN which 1167
is requested to provide its current internal time (TADR). 1168
1169
SPDO Producer
ADR
SSADR
ID
SPDO_Data_
With_Time_Req
LE
Payload
Length
CT
Internal
Time
Data
Payload
Data
TR
Time
Req.Cntr.
TADR
DSADR
Indication
Indication
Indication
Request
SPDO Consumers
1170
Fig. 15. SPDO with data and time request 1171
Field Information Content / Value
ADR Address of SPDO producer SSADR
ID SPDO_Data_with_Time_Request 11001xxxb
LE Number of payload data 0 - 254
CT Internal time value of SN Time
Data Payload data Data
TR Internal Time Request Counter 0 - 63
TADR Address of SN from which time information is requested DSADR
Tab. 10 SPDO with data and time request 1172
1173
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 47/191
5.2.4 Data with Time Response Frame 1174
The Data with Time Response Frame is used to transmit process data from an SN (SPDO producer) 1175
together with the internal timer value of the requested node. The data can be consumed by any other 1176
SN (SPDO consumer). 1177
1178
Together with the data (Data), the SPDO producer provides its SN address (ADR), the frame type (ID) 1179
as well as the number of payload data bytes (LE) transmitted, the current value of its internal timer 1180
(CT), the counter value for indicating the number of the time requests (TR) and the address of the SN 1181
which has issued the request (TADR). 1182
1183
SPDO Producer
ADR
SSADR
ID
SPDO_Data_
With_Time_Resp
LE
Payload
Length
CT
Internal
Time
Data
Payload
Data
TR
Time
Req.Cntr
TADR
DSADR
Indication
Indication
Indication
Request
SPDO Consumers
1184
Fig. 16. SPDO with data and time response 1185
Field Information Content / Value
ADR Address of SPDO producer SSADR
ID SPDO_Data_with_Time_Response 11010xxxb
LE Number of payload data 0 - 254
CT Internal time value of SPDO producer Time
Data Payload data Data
TR Time Request Counter value of corresponding request 0 - 63
TADR Address of the SN which issued the time information request DSADR
Tab. 11 SPDO with data and time response 1186
1187
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 48/191
5.3 Safety Service Data Object (SSDO) 1188
SSDOs are used for accessing the Object Directory of an SSDO-Server by an SSDO-Client. SSDO 1189
frames are identified by bits 7-5 (111b) of the frame ID. Bit 4 of the ID identifies an SOD-access (0b), 1190
Bit 3 identifes the type of openSAFETY frame to be used, which can be either a basic openSAFETY 1191
frame (0b) or a slim SSDO openSAFETY frame (1b). Bit 2 differentiates between request (0b) and 1192
response (1b) frames. 1193
5.3.1 SSDO Frame Types 1194
The ID field identifies the frame. The following frame types are distinguished: 1195
SSDO Service Request 1196
SSDO Service Response 1197
1198
Following Table shows the coding of the ID field: 1199
1200
Bit Number of ID Field Frame type
7 6 5 4 3 2 1 0
1 1 1 0 0 0 SSDO_Service_Request
1 1 1 0 0 1 SSDO_Service_Response
1 1 1 0 1 0 SSDO_Service_Request_Slim
1 1 1 0 1 1 SSDO_Service_Response_Slim
Tab. 12 SSDO Frame Types (ID Field, Bits 2,3,4) 1201
1202
The SSDO Service Request frame is used by an SSDO client to access the SOD of an SSDO server. 1203
With an SSDO Service Request Frame an SSDO client provides the server SN address (ADR), the 1204
length of the payload data (LE) and the Access Request Number SANo (CT-field). 1205
The first payload data byte (index 0) is used as a "Command Byte" (SACmd, Tab. 13) and specifies 1206
access type (Read/Write), transfer type (expedited/segmented), toggle bit and if this message 1207
initializes the transfer and if more segments are to be expected or this is the last segment of the 1208
transfer. In data bytes 1 and 2, the index of the accessed object dictionary entry, in data byte 3 the sub 1209
index of the accessed entry is specified. The SN address of the SSDO client is provided in TADR. 1210
1211
The maximum number of payload data is defined as 240 bytes. 1212
1213
The SSDO Service Response frame is used by an SSDO server to respond to a request from an 1214
SSDO client. 1215
1216
The SOD Access Request Number (SANo) is specific to each connection and incremented by one 1217
with every new SOD Access Request telegram. The response frame contains the SANo value of the 1218
corresponding service request. 1219
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 49/191
Bit No. Name Value Meaning
0 Access Type bit 0 SOD Read Access
1 SOD Write Access
1 Reserved 1 bit 0 Reserved
2 Abort transfer bit 0 Successful transfer
1 Abort transfer
3 Segmentation bit 0 Expedited SOD access
1 Segmented SOD access
4 Toggle bit 0 This bit shall alternate for each subsequent segment and not change its value in case of a repeated transmission. The first segment shall have the toggle bit set to 0. The toggle bit shall be equal for the request and the response frame.
1
5 Initiate transfer bit 0 No initiate transfer
1 Initiate transfer
6 End segment transfer bit 0 More segments to transfer
1 No more segments to transfer
7 Block transfer 0 Normal transfer
1 Block transfer
Tab. 13 SOD Access Command (SACmd) – Bit coding 1220
1221
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 50/191
5.3.2 SSDO Services and Protocols 1222
There are two types of SSDO services using different types of openSAFETY frames. The normal 1223
SSDO service using the basic openSAFETY frame may be used for all SSDO services. The slim 1224
SSDO service using the slim SSDO openSAFETY frame may only be used to download initializing 1225
data to a SN. The lack of having the data twice in the POWELINK safety frame must be compensated 1226
by verifying the data. This is done by only switching the SN to operational if the SOD CRC is correct. 1227
1228
The following SSDO services are defined: 1229
SSDO Download, which is subdivided into 1230
o SSDO Download Initiate 1231
o SSDO Download Segment 1232
1233
SSDO Upload, which is subdivided into 1234
o SSDO Upload Initiate 1235
o SSDO Upload Segment 1236
1237
SSDO Block Download, which is subdivided into 1238
o SSDO Block Download Initiate 1239
o SSDO Block Download Segment 1240
1241
SSDO Block Upload, which is subdivided into 1242
o SSDO Block Upload Initiate 1243
o SSDO Block Upload Segment 1244
1245
SSDO Abort 1246
1247
The block download/upload protocol is optional. Its advantage is that there are no response frames for 1248
the data segments. This results in less data traffic when transferring a big amount of data. To ensure 1249
that no overload is created, a inhibit time (minimum time between two segment telegrams) may be 1250
specified. If the block download/upload protocol is not implemented on a SSDO server, the SSDO 1251
client must use the segmented transfer protocol. 1252
1253
The following figures show the SSDO segmented, block and expedited download and upload 1254
protocols. 1255
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 51/191
Client Server Client Server
SSDO segmented download SSDO expedited download
SSDO download initiate
SSDO download segment
SSDO download segment
SSDO download segment
(last)
SSDO download initiate
SSDO block download
SSDO block download initiate
SSDO block download segment
SSDO blockdownload segment
SSDO block download segment
(last)
ServerClient
1256
Fig. 17. SSDO download protocols 1257
Client Server Client Server
SSDO segmented upload SSDO expedited upload
SSDO upload initiate
SSDO upload segment
SSDO upload segment
SSDO upload segment
(last)
SSDO upload initiate
Client Server
SSDO block upload
SSDO block upload initiate
SSDO block upload segment
SSDO block upload segment
SSDO block upload segment
(last)
1258
Fig. 18. SSDO upload protocols 1259
1260
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 52/191
5.3.2.1 SSDO Download Initiate 1261
ADR
DSADR
ID
SSDO_Service_Request /
SSDO_Service_Request_Fast
LE
Payload
Length
CT
SANo
DB0
SACmd
TR
0
TADR
SSADR
IndicationRequest
Confirmation Response
DB1-2
Index
DB3
Sub-
Index
DB4-n
Payload Data
ADR
DSADR
ID
SSDO_Service_Response /
SSDO_Service_Response_Fast
LE
Payload
Length
CT
SANo
DB0
SACmd
TR
0
TADR
SSADR
DB1-2
Index
DB3
Sub-Index
SSDO Client SSDO Server
1262
Fig. 19. SSDO Download Initiate Protocol 1263
Request Frame
Field Information Content / Value
ADR Address of SSDO Server to be accessed DSADR
ID SSDO_Service_Request SSDO_Service_Request_Slim
111000xxb
111010xxb
LE Length of payload data 4 - 254
CT SOD Access Request number (SANo) 1 – 65535, 0 not allowed
DB0 SOD Access Command (SACmd) expedited or Segmented
00100001b or 00101001b
DB1, DB2 Index of SOD entry to be accessed 0 - 65535
DB3 Sub Index of SOD entry to be accessed 0 - 255
DB4 – DBn Payload data (In case of a segmented download, DB4-DB7 contains the data size of the payload data to be downloaded. If the data size is 0, the size is not indicated.)
Payload data
TR Not used 0
TADR Address of SSDO Client SSADR
1264
Response Frame
Field Information Content / Value
ADR Address of SSDO Client to be responded DSADR
ID SSDO_Service_Response SSDO_Service_Response_Slim
111001xxb
111011xxb
LE Length of payload data 4
CT Echo of SOD Access Request number 1 – 65535, 0 not allowed
DB0 SOD Access Command (SACmd) expedited or Segmented
00100001b or 00101001b
DB1, DB2 Index of SOD entry to be accessed 0 - 65535
DB3 Sub Index of SOD entry to be accessed 0 - 255
TR Not used 0
TADR Address of SSDO Server SSADR
Tab. 14 SSDO Download Initiate Protocol 1265
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 53/191
5.3.2.2 SSDO Download Segment 1266
ADR
DSADR
ID
SSDO_Service_Request /
SSDO_Service_Request_Fast
LE
Payload
Length
CT
SANo
DB0
SACmd
TR
0
TADR
SSADR
IndicationRequest
Confirmation Response
DB1-n
Payload Data
ADR
DSADR
ID
SSDO_Service_Response /
SSDO_Service_Response_Fast
LE
Payload
Length
CT
SANo
DB0
SACmd
TR
0
TADR
SSADR
SSDO Client SSDO Server
1267
Fig. 20. SSDO Download Segment Protocol 1268
Request Frame
Field Information Content / Value
ADR Address of SSDO Server to be accessed DSADR
ID SSDO_Service_Request SSDO_Service_Request_Slim
111000xxb
111010xxb
LE Length of payload data 4 - 254
CT SOD Access Request number (SANo) 1 – 65535, 0 not allowed
DB0 SOD Access Command (SACmd) middle segment or end segment
000x1001b
or 010x1001b
DB1 – DBn Payload data Payload data
TR Not used 0
TADR Address of SSDO Client SSADR
1269
Response Frame
Field Information Content / Value
ADR Address of SSDO Client to be responded DSADR
ID SSDO_Service_Response SSDO_Service_Response_Slim
111001xxb
111011xxb
LE Length of payload data 4
CT Echo of SOD Access Request number 1 – 65535, 0 not allowed
DB0 SOD Access Command (SACmd) middle segment or end segment
CT SOD Access Request number (SANo) 1 – 65535, 0 not allowed
DB0 SOD Access Command (SACmd) block transfer 10101001b
DB1, DB2 Index of SOD entry to be accessed 0 - 65535
DB3 Sub Index of SOD entry to be accessed 0 - 255
DB4 – DBn Payload data (In case of a segmented download, DB4-DB7 contains the data size of the payload data of the block. If the data size is 0, the size is not indicated.)
Payload data
TR Not used 0
TADR Address of SSDO Client SSADR
1275
Response Frame
Field Information Content / Value
ADR Address of SSDO Client to be responded DSADR
ID SSDO_Service_Response SSDO_Service_Response_Slim
111001xxb
111011xxb
LE Length of payload data 4
CT Echo of SOD Access Request number 1 – 65535, 0 not allowed
DB0 SOD Access Command (SACmd) block transfer 10101001b
DB1, DB2 Index of SOD entry to be accessed 0 - 65535
DB1, DB2 Index of SOD entry to be accessed 0 - 65535
DB3 Sub Index of SOD entry to be accessed 0 - 255
TR Not used 0
TADR Address of SSDO Client SSADR
1288
Response Frame
Field Information Content / Value
ADR Address of SSDO Client to be responded DSADR
ID SSDO_Service_Response 111001xxb
LE Length of payload data 4-254
CT Echo of SOD Access Request number 1 – 65535, 0 not allowed
DB0 SOD Access Command (SACmd) expedited or Segmented
00100000b
or 00101000b
DB1, DB2 Index of SOD entry to be accessed 0 - 65535
DB3 Sub Index of SOD entry to be accessed 0 - 255
DB4 – DBn Payload data(In case of a segmented upload, DB4-DB7 contains the data size of the payload data of the block. If the data size is 0, the size is not indicated.)
Payload data
TR Not used 0
TADR Address of SSDO Server SSADR
Tab. 18 SSDO Upload Initiate Protocol 1289
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 57/191
5.3.2.6 SSDO Upload Segment 1290
The SSDO client always requests a middle segment. Based on the response it receives from the 1291
SSDO server, the SSDO client has to decide if the SSDO server sent a middle segment or the end 1292
segment. 1293
ADR
DSADR
ID
SSDO_Service_
Request
LE
Payload
Length
CT
SANo
DB0
SACmd
TR
0
TADR
SSADR
IndicationRequest
Confirmation Response
DB1-2
Index
DB3
Sub-Index
DB1-n
Data
ADR
DSADR
ID
SSDO_Service_
Response
LE
Payload
Length
CT
SANo
DB0
SACmd
TR
0
TADR
SSADR
SSDO Client SSDO Server
1294
Fig. 24. SSDO Upload Segment Protocol 1295
Request Frame
Field Information Content / Value
ADR Address of SSDO Server to be accessed DSADR
ID SSDO_Service_Request 111000xxb
LE Length of payload data 4
CT SOD Access Request number (SANo) 1 – 65535, 0 not allowed
DB1, DB2 Index of SOD entry to be accessed 0 - 65535
DB3 Sub Index of SOD entry to be accessed 0 - 255
DB4 – DB7 Inhibit time Inhibit time
TR Not used 0
TADR Address of SSDO Client SSADR
1303
Response Frame
Field Information Content / Value
ADR Address of SSDO Client to be responded DSADR
ID SSDO_Service_Response 111001xxb
LE Length of payload data 4-254
CT Echo of SOD Access Request number 1 – 65535, 0 not allowed
DB0 SOD Access Command (SACmd) expedited or block transfer
10100000b
or 10101000b
DB1, DB2 Index of SOD entry to be accessed 0 - 65535
DB3 Sub Index of SOD entry to be accessed 0 - 255
DB4 – DBn Payload data(In case of a segmented upload, DB4-DB7 contains the data size of the payload data of the block. If the data size is 0, the size is not indicated.)
Payload data
TR Not used 0
TADR Address of SSDO Server SSADR
Tab. 20 SSDO Block Upload Initiate Protocol 1304
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 59/191
5.3.2.8 SSDO Block Upload Segment 1305
The SSDO server sends the segments using the inhibit time it got with the initiate block upload 1306
telegram. Based on the response the SSDO client has to decide if a middle segment or the end 1307
segment was sent. 1308
Confirmation ResponseDB1-n
Data
ADR
DSADR
ID
SSDO_Service_
Response
LE
Payload
Length
CT
SANo
DB0
SACmd
TR
0
TADR
SSADR
SSDO Client SSDO Server
1309 1310
Fig. 26. SSDO Block Upload Segment Protocol 1311
Response Frame
Field Information Content / Value
ADR Address of SSDO Client to be responded DSADR
ID SSDO_Service_Response 111001xxb
LE Length of payload data 4-254
CT Echo of SOD Access Request number 1 – 65535, 0 not allowed
DB0 SOD Access Command (SACmd) middle segment or end segment
100x1000b or 110x1000b
DB1 – DBn Payload data Payload data
TR Not used 0
TADR Address of SSDO Server SSADR
Tab. 21 SSDO Block Upload Segment Protocol 1312
1313
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 60/191
5.3.2.9 SSDO Abort 1314
ADR
DSADR
ID
SSDO_Service_Request /
SSDO_Service_Request_Fast /
SSDO_Service_Response /
SSDO_Service_Response_Fast
LE
Payload
Length
CT
SANo
DB0
SACmd
TR
0
TADR
SSADR
IndicationRequest DB1-2
Index
DB3
Sub-
Index
SSDO
Server
SSDO
Client
DB4-7
Abort
code
1315
Fig. 27. SSDO Abort Protocol 1316
Field Information Content / Value
ADR Address of the SSDO Client to be informed DSADR
ID SSDO_Service_Request SSDO_Service_Request_Slim SSDO_Service_Response SSDO_Service_Response_Slim
111000xxb
111010xxb
111001xxb
111011xxb
LE Length of payload data 8
CT SOD Access Request number (SANo) 1 – 65535, 0 not allowed
DB0 SOD Access Command (SACmd) 00000100b
DB1, DB2 Index of SOD entry 0 - 65535
DB3 Sub Index of SOD entry 0 - 255
DB4 – DB7 Abort code, see Table 8 Abort code
TR Not used 0
TADR Address of the SSDO Server initiating the abort SSADR
Tab. 22 SSDO Abort Protocol 1317
1318
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 61/191
The payload data of the abort frame consists of an error code which is defined in table 23. The abort 1319
code is encoded as UNSIGNED 32 value. 1320
1321
Abort code Description
0503 0000h Reserved
0504 0000h SSDO protocol timed out.
0504 0001h Client/server Command ID not valid or unknown.
0504 0002h Invalid block size.
0504 0003h Invalid sequence number.
0504 0004h Reserved
0504 0005h Out of memory.
0601 0000h Unsupported access to an object.
0601 0001h Attempt to read a write-only object.
0601 0002h Attempt to write a read-only object.
0602 0000h Object does not exist in the object dictionary.
0604 0041h Object cannot be mapped to the SPDO.
0604 0042h The number and length of the objects to be mapped would exceed SPDO length.
0604 0043h General parameter incompatibility.
0604 0047h General internal incompatibility in the device.
0606 0000h Access failed due to a hardware error.
0607 0010h Data type does not match, length of service parameter does not match
0607 0012h Data type does not match, length of service parameter too high
0607 0013h Data type does not match, length of service parameter too low
0609 0011h Sub-index does not exist.
0609 0030h Value range of parameter exceeded (only for write access).
0609 0031h Value of parameter written too high.
0609 0032h Value of parameter written too low.
0609 0036h Maximum value is less than minimum value.
0800 0000h General error.
0800 0020h Data cannot be transferred or stored to the application.
0800 0021h Data cannot be transferred or stored to the application because of local control.
0800 0022h Data cannot be transferred or stored to the application because of the present device state.
0800 0023 h Data cannot be transferred or stored to the application because application is busy.
Tab. 23 SSDO abort codes 1322
1323
All abort codes not listed in table 23 are reserved. 1324
1325
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 62/191
5.4 Safety Network Management (SNMT) 1326
The openSAFETY Network Management is node oriented and follows a logical master-slave structure. 1327
The SNMT Master is given by a SCM or a configuration tool. 1328
1329
The following SNMT services are provided: 1330
UDID request 1331
Node address assignment 1332
Extended Services distinguished within the DB0 field, comprising the following services: 1333
o communication state control 1334
o node guarding 1335
o additional node address assignment 1336
5.4.1 SNMT Frame Types 1337
The ID field (bit 2-4) identifies the SNMT frame type. The following table shows the different SNMT 1338
An Object Dictionary entry must be defined by the following items: 1714
Index 1715
“Index” denotes the objects position within the Object Dictionary. This acts as a kind of address 1716
to reference the desired data field. An “Index” must be declared as hexadecimal value. 1717
1718
Object 1719
An “Object” may be subdivided to sub-indices. The sub-index is used to reference data fields 1720
within a complex object such as an array or record. The sub-index is not specified here. 1721
1722
Object Type 1723
“Object Type” contains an entry according to Tab. 43. It is used to denote what kind of object is 1724
at that particular index within the Object Dictionary. The following definitions are used: 1725
1726
Object Type Comments Code
NULL A dictionary entry with no data fields 0
DOMAIN Large variable amount of data e.g. executable program code 2
DEFTYPE Denotes a static data type definition such as a Boolean, UNSIGNED16, float and so on
5
DEFSTRUCT Defines a record type 6
VAR A single value such as an UNSIGNED8, Boolean, float, Integer16, visible string etc.
7
ARRAY A multiple data field object where each data field is a simple variable of the SAME basic data type e.g. array of UNSIGNED16 etc. Sub-index 0 is of UNSIGNED8 and therefore not part of the ARRAY data
8
RECORD A multiple data field object where the data fields may be any combination of simple variables. Sub-index 0 is an UNSIGNED8 and therefore not part of the RECORD data
9
Tab. 43 Object type definitions 1727
1728
Name 1729
“Name” provides a simple textual description of the function of that particular object. 1730
“Name” must be in accordance to IEC 61131-3. It consists of: 1731
o domain prefix, indicating the association of the object to a functional domain, up to 4 1732
uppercase characters followed by underline 1733
o name (verbally). 1734
composed of word, each word must be leaded by an uppercase character followed by 1735
lowercase characters or digits, no underlines or spaces 1736
o data type postfix, indicating the data type of the object (underline followed by up to 5 1737
uppercase characters or digits) 1738
Total length of “Name“ must be equal or below 32 characters. 1739
1740
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 87/191
Data Type 1741
This entry provides information about the data type of the object. These include the following 1742
pre-defined static data types: BOOLEAN, floating point number, UNSIGNED Integer, Signed 1743
Integer, visible/octet string and DOMAIN (see 5.1.1.11). It also includes the pre-defined complex 1744
data types and may also include types which are either manufacturer or device specific. 1745
1746
It is not allowed to define records of records, arrays of records or records with arrays as fields of 1747
that record. In the case where an object is an array or a record, the sub-index is used to 1748
reference one static data type data field within the object. 1749
1750
Category 1751
“Category” defines whether the object is Mandatory (M) or Optional (O). A mandatory object 1752
must be implemented on a device. An optional object does not have to be implemented on a 1753
device. The support of certain objects or features however may require the implementation of 1754
related objects. In this case, the relations are described in the detailed object specification. 1755
1756
“Category” may be Conditional (Cond) if the M/O category of an object depends on the 1757
implementation of another object. 1758
1759
The following entries must be indicated for static data types only. In case of complex data types 1760
the respective entries must be provided for each sub-index individually. 1761
1762
Access 1763
This entry defines the access rights for a particular object. The view point is from the bus into 1764
the device. It can be one of the following: 1765
1766
rw read and write access
wo write only access
ro read only access
Const read only access, value is constant
Tab. 44 Access Attributes for Data Objects 1767
1768
Optional objects listed in the Object Dictionary with the attribute rw may be implemented as 1769
read only. Exceptions are defined in the detailed object specification. 1770
1771
Value Range 1772
This entry indicates the value range of the respective object. It may consist of one or more 1773
distinct values or ranges of values. If the item shown is a data type identifier, the complete value 1774
range of the mentioned data type must be allowed. 1775
1776
Default Value 1777
This entry indicates the initialization value that must be assigned by the profile implementation. 1778
For mappable objects, this value represents also the safe state value. 1779
1780
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 88/191
SPDO Mapping 1781
This entry indicates whether an entry may be mapped to an SPDO message. It can be one of 1782
the following: 1783
1784
Opt Object may be mapped into an SPDO
No Object must not be mapped into an SPDO
Tab. 45 SPDO Mapping Attributes for Data Objects 1785
1786
A complete static data type object definition (Object Type = VAR or DOMAIN) example is displayed 1787
below: 1788
1789
Index 1234h Object Type VAR
Name SSDO_VarDummyParameter_S16
Data Type INTEGER16 Category M
Value Range -15 000 .. 10 000 Access rw
Default Value 0 SPDO Mapping
Opt
Tab. 46 Static Data Type Object Definition Example 1790
1791
Complex data type object definitions (Object Type = ARRAY or RECORD) are of reduced form, 1792
because Access, Value Range, Default Value, and SPDO mapping must be defined individually for the 1793
sub-indices 1794
1795
Index 2345h Object Type ARRAY
Name SSDO_ArrayDummyParameter_AU16
Data Type UNSIGNED16 Category M
Tab. 47 Complex Data Type Object Definition Example 1796
1797
“Category” refers to the complex data type object as a whole, but not to the particular sub-1798
index. A mandatory object may be composed of mandatory and optional sub-indices. This 1799
means that the object must be supported but some of its sub-indices are optional. Defining 1800
optional objects with mandatory sub-indices is also permitted. This means that these sub-1801
indices must be supported if the object is implemented. 1802
1803
“Data Type” must contain a static data type for ARRAY type objects and a complex data type 1804
for RECORD type objects. 1805
1806
The definition of data type describing objects (Object Type = DEFTYPE or DEFSTRUCT) is shown in 1807
5.6.3. 1808
1809
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 89/191
5.6.2.1 Sub-Index Definition 1810
Complex object types (ARRAY, RECORD objects) are composed of up to 256 data items. Each data 1811
item may be addressed by an UNSIGNED8 type sub-index. 1812
Sub-Indices are used in the following way: 1813
Sub-Index 00h NumberOfEntries 1814
NumberOfEntries describes the highest available sub-index that follows, not considering FFh. 1815
This entry is encoded as UNSIGNED8, regardless the type of the object. If the object exists, 1816
NumberOfEntries is mandatory. Data Type and Category are not denoted in NumberOfEntries 1817
descriptions. 1818
1819
NumberOfEntries is described by this specification as shown below: 1820
Sub-Index 00h
Name NumberOfEntries
Value Range 1..15 Access rw
Default Value 15 SPDO Mapping
No
Tab. 48 NumberOf Entries Sub-Index Description Example 1821
1822
o For ARRAYs, NumberOfEntries may be modified (Access = rw) to show the number of 1823
occupied items in a list. For RECORDs, NumberOfEntries is constant (Access = ro or 1824
Const). 1825
1826
Sub-Index 01h - FEh Object Specific Data 1827
Sub-Indices between 01h and FEh hold the object’s payload data. The highest accessible index 1828
is given by NumberOfEntries. 1829
1830
Sub-Indices of RECORD type objects are defined as follows: 1831
Sub-Index 01h
Name RecItem1_U8
Data Type UNSIGNED8 Category M
Value Range 1..255 Access rw
Default Value 1 SPDO Mapping
Def
Tab. 49 Record Type Object Sub-Index Description Example 1832
1833
o “Name” is composed of a description text followed by a data type postfix. Refer to the 1834
object name rules for further information, the domain prefix is omitted. 1835
If a name entry is defined in a data type definition, the sub-index name is equal to it. 1836
1837
o “Category” refers to the respective sub-index only. Mandatory (M) means that the sub-1838
index must be implemented when the object is implemented. A mandatory sub-index 1839
does not force the hosting object to be mandatory. 1840
1841
1842
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 90/191
Sub-Indices of ARRAY type objects are defined as follows: 1843
Sub-Index 01h
Name ArraySubindex1
-- -- Category M
Value Range UNSIGNED16 Access rw
Default Value 0 SPDO Mapping
Opt
Tab. 50 Array Type Object Sub-Index Description Example 1844
1845
o “Name” consists of a description text. Refer to the object name rules for further 1846
information, the domain prefix and data type postfix are omitted. If a name entry is 1847
defined in a data type definition, the sub-index name must be equal to it. 1848
1849
o “Category” refers to the respective sub-index only. Mandatory (M) means that the sub-1850
index must be implemented when the object is implemented. A mandatory sub-index 1851
doesn’t force the hosting object to be mandatory. 1852
1853
o Despite the functional equivalence of all sub-indices in an array, more than one sub-index 1854
entry can be defined to a particular object to show differences of the Category, Access 1855
and / or SPDO Mapping options of the sub-indices. 1856
1857
Sub-Index FFh StructureOfObject 1858
Sub-index FFh describes the structure of the entry by providing the data type and the object type 1859
of the entry. Regardless of the type of the object, it is encoded as UNSIGNED32 and organized 1860
as follows: 1861
1862
MSB LSB
Bit-No. 31 - 24 23 - 16 15 - 8 7 - 0
Value 00h Data Type (refer Tab. 42) Object Type (refer Tab. 43
Tab. 51 Structure of Sub-Index FFh 1863
1864
It is optional to support sub-index FFh. If it is supported throughout the Object Dictionary and the 1865
structure of the complex data types is provided as well, it is possible to upload the entire 1866
structure of the Object Dictionary. If StructureOfEntry is not supported, sub-index FFh is 1867
reserved. 1868
StructureOfObject is not shown by object definitions in this specification. 1869
5.6.3 Data Type Entry Specification 1870
The static data types are placed in the Object Dictionary for definition purposes only. However, indices 1871
in the range 0001h - 0007h may be mapped in order to define the appropriate space of the RxSPDO 1872
(Dummy Mapping) as not being used by the device (do not care). The indices 0009h - 000Bh, 000Fh 1873
may not be mapped to an SPDO. 1874
1875
See Tab. 42, index range 0001h to 04FFh for data type specifying object dictionary entries. 1876
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 91/191
5.6.3.1 Static Data Types 1877
The static data type (Object Type = DEFTYPE) representations used are detailed in 5.4. 1878
1879
A device may optionally provide the length of the static data types encoded as UNSIGNED32 for read 1880
access of the index that refers to the data type. E.g. index 0007h (UNSIGNED32) contains the value 1881
20h=32d because the data type „UNSIGNED32“ is encoded using a bit sequence of 32 bit. If the length 1882
is variable (e.g. 000Fh = Domain), the entry contains 0h. 1883
5.6.3.2 Complex Data Types 1884
The predefined complex data types’ (Object Type = DEFSTRUCT) representations are provided in the 1885
respective paragraph or in the device profile. 1886
1887
For the supported complex data types, a device may optionally provide the structure of that data type 1888
for read access of the corresponding data type index. Sub-index 0 then provides the number of entries 1889
at this index not counting sub-indices 0 and 255 and the following sub-indices contain the data type 1890
according to Tab. 42 encoded as UNSIGNED16. 1891
1892
The entry at Index 0021h describing the structure of the Identity object 1893
SINF_DevVendorInfoRecord_TYPE is specified as follows: 1894
1895
Index 0021h Object Type DEFSTRUCT
Name SINF_DevVendorInfoRecord_TYPE
Sub-Index Component Name Value Data Type
00h NumberOfEntries 06h
01h VendorId_U32 07h UNSIGNED32
02h ProductCode_U32 07h UNSIGNED32
03h RevisionNo_U32 07h UNSIGNED32
04h SerialNo_U32 07h UNSIGNED32
05h FirmWareChecksum_U32 07h UNSIGNED32
06h ParameterChecksum_U16 06 h UNSIGNED16
07h ParameterTimestamp_U32 07h UNSIGNED32
Tab. 52 Complex Data Type Description Example 1896
1897
Standard (simple) and complex manufacturer specific data types can be distinguished by attempting to 1898
read sub-index 1h: For a complex data type, the device returns a value and sub-index 0h contains the 1899
number of sub-indices that follow; for a standard data type the device aborts the SOD Access because 1900
no sub-index 1h is available. 1901
5.6.4 Object Description 1902
Index (hex)
Object (Symbolic Name)
Name Type Acc. M/O
Common Parameters
1001 VAR error register UNSIGNED8 ro M
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 92/191
1002 VAR manufacturer status register UNSIGNED32 ro O
1003 ARRAY pre-defined error field UNSIGNED32 rw O
:::: :::: :::::::::::::::: :::::::::::: :::: ::::
100C RECORD life guarding SSDO_LifeGuardRecord_TYPE (20h)
rw M
100D VAR Refresh Time for Reset Guarding
UNSIGNED32 rw M
100E VAR Number of Retries for Reset Guarding
UNSIGNED8 rw O
1018 RECORD device vendor information SINF_DevVendorInfoRecord_TYPE (21h)
ro M
1019 VAR unique device id OCTET_STRING ro M
101A DOMAIN parameter download DOMAIN rw O
101B RECORD SCM specific parameters SSCM_SpecificParametersRecord_TYPE (29h)
rw O
Common Communication Parameters
1200 RECORD common communication parameters
SCOM_CommonCommParamRecord_TYPE (22h)
w M
1201 RECORD SSDO communication parameters
SSDO_CommParamRecord_TYPE (23h)
rw C**
1202 RECORD SNMT communication parameters
SNMT_CommParamRecord_TYPE (24h)
Receive SPDO Communication Parameter
1400 RECORD 1st RxSPDO communication parameters
SPDO_RxCommParamRecord_TYPE (25h)
rw
:::: :::: :::::::::::::::: :::::::::::: :::: ::::
17FE RECORD 1023nd RxSPDO communication parameters
SPDO_RxCommParamRecord_TYPE (25h)
rw
Receive SPDO Mapping Parameter
1800 ARRAY 1st RxSPDO mapping parameters
UNSIGNED32 rw O
:::: :::: :::::::::::::::: :::::::::::: :::: ::::
1BFE ARRAY 1023nd RxSPDO mapping parameters
UNSIGNED32 rw O
1903
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 93/191
1904
Index (hex)
Object (Symbolic Name)
Name Type Acc. M/O
Transmit SPDO Communication Parameter
1C00 VAR 1st TxSPDO communication parameters
SPDO_TxCommParamRecord_TYPE (26h)
rw M
:::: :::: :::::::::::::::: :::::::::::: rw O
1FFE VAR 1023nd TxSPDO communication parameters
SPDO_TxCommParamRecord_TYPE (26h)
rw O
User Parameter (writeable at any time)
2800 ARRAY 1st User Prameter UNSIGNED32 rw O
:::: :::: :::::::::::::::: :::::::::::: :::: O
2FFF ARRAY 2048th User Parameter UNSIGNED32 rw O
Transmit SPDO Mapping Parameter
C000 ARRAY 1st TxSPDO mapping parameters
UNSIGNED32 rw M
:::: :::: :::::::::::::::: :::::::::::: :::: O
C3FE ARRAY 1023nd TxSPDO mapping parameters
UNSIGNED32 rw O
SADR – DVI List
C400 RECORD 1st SADR-DVI List SSCM_SADRDVIListRecord_TYPE (27h)
rw C***
:::: :::: :::::::::::::::: :::::::::::: :::: ::::
C7FE RECORD 1023rd SADR-DVI List SSCM_SADRDVIListRecord_TYPE (27h)
rw C***
Additional SADR List
C801 ARRAY 1st SADR UNSIGNED16 rw C***
:::: :::: :::::::::::::::: :::::::::::: :::: ::::
CBFF ARRAY 1023rd SADR UNSIGNED16 rw C***
SADR – UDID List
CC01 RECORD 1st SADR-UDID List SSCM_UDIDSADRListRecord_TYPE (28h)
rw C***
:::: :::: :::::::::::::::: :::::::::::: :::: ::::
CFFF RECORD 1023rd SADR-UDID List SSCM_UDIDSADRListRecord_TYPE (28h)
rw C***
Additional Parameter List
E400 RECORD 1st Additional Parameter List SSCM_ ADDPARAList _TYPE (2Ah)
rw C***
:::: :::: :::::::::::::::: :::::::::::: :::: ::::
E7FE RECORD 1023rd Additional Parameter List
SSCM_ ADDPARAList Record_TYPE (2Ah)
rw C***
Tab. 53 Standard Objects 1905
1906
If a device supports SPDOs, the corresponding SPDO communication parameter and SPDO mapping 1907
entries in the Object dictionary are mandatory. 1908
1909
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 94/191
** The parameters only have to be available if the node can be an SSDO client. 1910
*** Only needs to be implemented if the device has SCM functionality 1911
1912
This chapter describes the standard object dictionary entries for a SN and SCM. The implementation 1913
of these objects may differ from the description within the specification. For example the “Main SADR” 1914
might be a read only parameter in case it is to be set using a dip switch. 1915
1916
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 95/191
5.6.4.1 Object 1001h: Error Register 1917
This object is an error register for the device. The device can map internal errors in this byte. If the 1918
value of the object is zero, the device is ok. All other values signal that the device is in an error state. 1919
The error codes for the error descriptions are described in Tab. 54. 1920
1921
Index 1001h
Name SERR_GeneralError_U8
Data Type UNSIGNED8 Category M
Value Range UNSIGNED8 Access ro
Default Value 0 SPDO Mapping Yes
Relevant for SOD checksum No
1922
Value interpretation 1923
Bit M/O Description
0 M generic error
1 O current
2 O voltage
3 O temperature
4 O communication error (overrun, error state)
5 O device profile specific
6 O Reserved (always 0)
7 O manufacturer specific
Tab. 54 Structure of the Error Register 1924
5.6.4.2 Object 1002h: Manufacturer status register 1925
This object is a status register for manufacturer purposes. In this document, only the size and location 1926
of this object is defined. 1927
Index 1002h
Name SERR_ManufacturerStatus_U32
Data Type UNSIGNED32 Category O
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping Yes
Relevant for SOD checksum No
1928
1929
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 96/191
5.6.4.3 Object 1003h: Pre defined error field 1930
The object at index 1003h stores the errors that have occurred on the device. Every new error is 1931
stored at sub.index 01h, older errors are moved to the next higher sub-index. In doing so, it provides 1932
an error history. Sub-index 0 provides the number of errors in the list. The list can be deleted by 1933
setting sub-index 0 to zero. 1934
1935
Index 1003h Object Type ARRAY
Name SERR_ErrorHistory_AU32
Data Type UNSIGNED32 Category O
Relevant for SOD checksum No
1936
Sub-Index 00h Number of errors
Name NumberOfEntries
Value Range 1..254 Access rw
Default Value 1 SPDO Mapping No
1937
Sub-Index 01h Error within the history list
Name Error_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1938
Sub-Index 02h - FEh Error within the history list
Name Error_U32
Data Type UNSIGNED32 Category O
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1939
1940
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 97/191
5.6.4.4 Object 1004h: Error statistics 1941
openSAFETY frames can be invalid or denied for various reasons. To ease the integration as well as 1942
testing of an openSAFETY stack implementation, various error counters can be used to determine, 1943
how an openSAFETY stack implementation has treated incoming packages. These objects are 1944
mandatory. Additionally 4 error counters are only implemented, if the corresponding openSAFETY 1945
stack implementation uses the appropriate modules. 1946
1947
Index 1004h Object Type ARRAY
Name SERR_ErrorStatistics_AU32
Data Type UNSIGNED32 Category O
Relevant for SOD checksum No
1948
Sub-Index 00h Number of error statistic entries
Name NumberOfEntries
Value Range 0Eh Access rw
Default Value 0Eh SPDO Mapping No
1949
Sub-Index 01h Defined payload length for the frame differs from the received data Name SFS_LENGTH
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1950
Sub-Index 02h Safety frame is too long
Name SFS_TOO_LONG
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1951
Sub-Index 03h Frame IDs differ between sub-frame 1 and 2 Name SFS_FRAME_ID
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1952
Sub-Index 04h Invalid SADR provided
Name SFS_SADR_INVALID
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1953
Sub-Index 05h Invalid SDN provided
Name SFS_SDN_INVALID
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1954
Sub-Index 06h Invalid TADR provided
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 98/191
Name SFS_TADR_INVALID
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1955
Sub-Index 07h CRC for subframe 1 is invalid
Name SFS_CRC1_INVALID
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1956
Sub-Index 08h CRC for subframe 2 is invalid
Name SFS_CRC2_INVALID
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1957
Sub-Index 09h Payload differs between sub-frame 1 and 2 Name SFS_DATA
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1958
Sub-Index 0Ah Cyclic frame rejected because not applicable for SN Name CYC_REJECT
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1959
Sub-Index 0Bh Generic cyclic frame error, frame was intended for SN Name CYC_ERROR
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1960
Sub-Index 0Ch SNMT/SSDO frame rejected because not applicable for SN Name ACYC_REJECT
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1961
Sub-Index 0Dh SNMT/SSDO retry
Name ACYC_RETRY
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1962
Sub-Index 0Eh Common error counter
Name COMMON_CTR
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 99/191
5.6.4.5 Object 100Ch: Life Guarding 1963
This object defines the Life Guarding Protocol. The guard time is the time interval in which the SN 1964
should receive a life time signal from the SCM. The life time factor multiplied by the guard time results 1965
in the life time of the node. The time interval for sending the life time signal to the SNs is calculated by 1966
dividing the GuardTime_U32 by the number of nodes. The guard time interval for a SN within the SCM 1967
is started after receiving the last guarding response from the SN. 1968
Index 100C h Object Type RECORD
Name SSDO_LifeGuard_REC
Data Type SSDO_LifeGuardRecord_TYPE Category M
Relevant for SOD checksum Yes
1969
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 2 Access ro
Default Value 2 SPDO Mapping No
1970
Sub-Index 01h Guard time for the lifetime protocol. The time base of this parameter is defined by CommonCommParam_REC. ConsecutiveTimeBase_I8.
The values range may be limited vendor specific due to implementation reasons to a smaller value than 2
32
Name GuardTime_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access rw
Default Value 10000000 SPDO Mapping No
1971
Sub-Index 02h Number of times how often the GuardTime_U32 may elapse before the node switches back from Operational to Pre-Operational
Name LifeTimeFactor_U8
Data Type UNSIGNED8 Category M
Value Range 1 .. 255 Access rw
Default Value 2 SPDO Mapping No
1972
5.6.4.6 Object 100Dh: Number of Retries for Reset Guarding 1973
This object contains the refresh interval of the Reset Guarding (see chapter 5.7.6.2). This defines the 1974
time delay between each individual SNMT_SN_reset_guarding_SCM signal sent by the SN to it’s 1975
accompanying SCM during operational and boot-up phases. The number of attempts during boot-up 1976
can be defined by 0x100E (see chapter 5.6.4.7). 1977
1978
Index 100Dh The sub-index provides the refresh time for the SNMT_SN_reset_guarding_SCM service. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name SNMT_ResetGuarding_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access rw
Default Value 100000 SPDO Mapping No
Relevant for SOD checksum No
1979
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 100/191
5.6.4.7 Object 100Eh: Refresh interval of Reset Guarding 1980
This object contains number of retries a SN performs to contact its accompanying SCM using Reset 1981
Guarding (see chapter 5.7.6.2) during boot-up of the SN. The time interval between each message is 1982
defined by 0x100D (see chapter 5.6.4.8). The parameter is optional and if omitted an infinite number 1983
of tries is assumed. 1984
1985
Index 100Eh This parameter is optional and sets the maximum number of Reset Guarding telegrams sent at boot-up. If the value is set to 255 the Reset Guarding telegram is infinitely repeated. If the value is set to 0 – 254 the Reset Guarding telegram is not sent anymore after the set number of repetitions.
Name SNMT_NoResetGuarding_U8
Data Type UNSIGNED8 Category O
Value Range UNSIGNED8 Access rw
Default Value Manufacturer specific
SPDO Mapping No
Relevant for SOD checksum No
1986
5.6.4.8 Object 1018h: Device Vendor Information 1987
This object contains the vendor specific device information. It also defines compatible devices. Any 1988
device with an identical Vendor-ID, Product code, Major Revision Number and a Minor Revision 1989
Number greater or equal to another device must be compatible. The manufacturer of a device has to 1990
verify and ensure the compatibility for minor revision changes on a safety related device. 1991
1992
Index 1018h Object Type RECORD
Name SINF_DevVendorInfo_REC
Data Type SINF_DevVendorInfoRecord_TYPE Category M
Relevant for SOD checksum No
1993
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 9 Access ro
Default Value 9 SPDO Mapping No
1994
Sub-Index 01h Vendor ID according EPSG Vendor List Name VendorID_32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1995
Sub-Index 02h The manufacturer-specific product code identifies a specific device version
Name ProductCode_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1996
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 101/191
Sub-Index 03h See specification below
Name RevisionNumber_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1997
Sub-Index 04h Serial Number of the device
Name SerialNumber_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1998
Sub-Index 05h Vendor specific FW Checksum
Name FirmWareChecksum_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
1999
Sub-Index 06h Contains the SOD parameter checksum container (to be calculated as described below).
Timestamp
CRC32
CRC32
…
Name ParameterChecksum_DOM
Data Type DOMAIN Category M
Value Range DOMAIN Access rw
Default Value 0 SPDO Mapping No
2000
Sub-Index 07h Parameter Timestamp, to be the same as in the ParameterChecksum object. The parameter timestamp is created by the configuration tool and is verified in each module at start-up by the SCM (see chapter 5.7.13). Timestamp format is seconds since 1.1.1970 (UNIX timestamp).
Name ParameterTimestamp_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
2001
Sub-Index 08h Checksum, which defines the openSAFETY stack implementation used for creating the device firmware
Name openSAFETY_Stack_ChkSum_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access ro
Default Value 0 SPDO Mapping No
2002
Sub-Index 09h Stores the version of the openSAFETY protocol implementation, using the method described below
Name openSAFETY_Stack_Version_U16
Data Type UNSIGNED16 Category M
Value Range UNSIGNED16 Access ro
Default Value 0 SPDO Mapping No
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 102/191
5.6.4.8.1 Manufacturer Revision number 2003
The manufacturer-specific Revision number consists of a major revision number and a minor revision 2004
number. The major revision number identifies a specific device behavior. If the device functionality is 2005
expanded, the major revision has to be incremented. The minor revision number identifies different 2006
versions with the same device behavior. 2007
2008
31 16 15 0
major revision number minor revision number
MSB LSB
Tab. 55 Structure of Revision number 2009
5.6.4.8.2 Calculation of the parameter checksum 2010
The parameter checksum object 0x1018/0x06 is a domain which contains the timestamp and n 32bit 2011
CRCs. The timestamp is to be shown also in object 0x1018/0x07. Each CRC is used to verify the 2012
correctness of up to 4k bit (4096 bit / 512 bytes) of SOD variables. When the SN is switched to 2013
operational, the whole SOD has to be checked against the CRCs contained in this object. Switching to 2014
operational is only allowed, if the timestamp of the SNMT command and the CRCs are correct. 2015
For calculating the CRC over the SOD only the actual data of relevant objects is used. Objects marked 2016
as not relevant for the CRC calculation are not to be considered for the calculation. Due to the fact that 2017
a maximum of 4k bit of data is allowed to be used for each CRC, more than one CRC may be 2018
necessary for securing the SOD of a large device. 2019
It is not scope of this document to describe how the parameters and the checksum container are 2020
written to the device. It is only necessary to ensure that the entire SN parameters have been written to 2021
the SN. Due to the fact that the timestamp and the CRCs are coupled together in the 0x1018/0x06 2022
Object, the SCM only has to verify the timestamp, to ensure that the correct parameter/crc set is on 2023
the SN. 2024
5.6.4.8.3 openSAFETY stack version 2025
The parameter object 0x1018/0x09 is UNSIGNED16 data object, which contains the version for the 2026
openSAFETY stack used to create the device firmware. The coding of this version number is 2027
displayed in table Tab. 56 2028
2029
15 0
major revision number minor revision number
MSB LSB
Tab. 56 Structure of openSAFETY version number 2030
2031
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 103/191
5.6.4.9 Object 1019h: Unique Device ID 2032
The object at index 1019h contains the Unique Device Identification (UDID) for the device. Each 2033
openSAFETY Vendor has to request an MAC Vendor ID and he has to ensure to put a unique number 2034
on each openSAFETY Device produced. Since the uniqueness of the UDID of connected SNs is 2035
verified by the SCM, the allocation of the UDID during the vendor’s production is not a safety critical 2036
production step. 2037
2038
The composition of the UDID is as following: 2039
3 byte MAC Vendor Id + 3 byte vendor-specific unique device number (e.g. serial number). 2040
e.g.: MAC Vendor ID: 006065 h 2041
Serial Number: 471112 h 2042
UDID: 00-60-65-47-11-12 2043
UDID 00-00-00-00-00-00 is reserved. 2044
2045
Index 1019h The UDID is a globally unique identifier which consists of 6 bytes.
Name SINF_UniqueDeviceID_OSTR6
Data Type OCTET_STRING6 Category M
Value Range OCTET_STRING6 Access Const
Default Value 0 SPDO Mapping No
Relevant for SOD checksum No
2046
5.6.4.10 Object 101Ah: Parameter Download 2047
This object is used for receiving an application specific parameter set from the SCM. The parameters 2048
are to be transferred in a specified format. 2049
Data Type Len Description
Item
1
UINT16 2 Index of the object
UINT8 1 Sub-Index of the object
UINT32 4 Length of the data for the object
DOMAIN n Data for the object
Item
2
UINT16 2 Index of the object
UINT8 1 Sub-Index of the object
UINT32 4 Length of the data for the object
DOMAIN n Data for the object
… … …
Tab. 57 Format for parameter transmission in 0x101a 2050
2051
In case of an additional parameter download, the above specified format is used as well, as specific 2052
information about the content of the download is transferred using the header for the additional 2053
parameter (see 5.6.4.10.1) 2054
Both, the normal parameter sets and additional parameter sets are transferred using the 0x101A 2055
object. On the SN, the SN has to determine which type of parameter set it is receiving, and react 2056
accordingly. 2057
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 104/191
Index 101Ah
Name SSDO_ParameterDownload_DOM
Data Type DOMAIN Category O
Value Range DOMAIN Access rw
Default Value 0 SPDO Mapping No
Relevant for SOD checksum No
2058
5.6.4.10.1 Additional Parameter Header 2059
2060
Additional parameter download uses a header to provide information about the parameter set. The 2061
following format is used for this header: 2062
2063
Data Type Len Name
UINT8 1 Parameter Set number
UINT8 1 Header Version (reserved for future use)
UINT16 2 SAddr of SN
UINT32 4 Octet size for parameter set without header
UINT32 4 CRC for parameter set without header
UINT32 4 Timestamp for parameter set
Tab. 58 Format for additional parameter header 2064
5.6.4.11 Object 101Bh: SCM Parameters 2065
The object at index 101Bh contains the SCM specific parameters. 2066
Index 101Bh Object Type RECORD
Name SSCM_SpecificParameters_REC
Data Type SSCM_SpecificParametersRecord_TYPE Category O
Relevant for SOD checksum No
2067
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 1 Access ro
Default Value 1 SPDO Mapping No
2068
Sub-Index 01h SCM configuration mode according to chapter 3.1.2.
0 … ACM
1 … MCM
Name ConfigurationMode_U8
Data Type UNSIGNED8 Category M
Value Range 0-1 Access rw
Default Value 0 SPDO Mapping No
2069
2070
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 105/191
5.6.4.12 Object 1200h: Common Communication Parameter 2071
This object contains the common communication parameters for the device. Sub-index 3 contains the 2072
consecutive time base for the module. It is not necessary for a device to support all possible time 2073
bases. The minimum requirement is to support a time base of 100μs (type 2). 2074
2075
Index 1200h Object Type RECORD
Name SCOM_CommonCommParam_REC
Data Type SCOM_CommonCommParamRecord_TYPE
Category M
Relevant for SOD checksum Yes
2076
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 4 Access ro
Default Value 4 SPDO Mapping No
2077
Sub-Index 01h openSAFETY Domain Number of the device Name SDN_U16
Data Type UNSIGNED16 Category M
Value Range 0 - 1023 Access ro
Default Value 0 SPDO Mapping No
2078
Sub-Index 02h openSAFETY Address of the SCM within the SD. Name SADR_U16
Data Type UNSIGNED16 Category M
Value Range 0 - 1023 Access ro
Default Value 0 SPDO Mapping No
2079
Sub-Index 03h time base for the CT field: 1 μs x 10
ConsecutiveTimeBase_I8
0 1 μs 1 10 μs 2 100 μs 3 1000 μs
Name ConsecutiveTimeBase_I8
Data Type INTEGER8 Category M
Value Range 0 - 3 Access rw
Default Value 2 SPDO Mapping No
2080
Sub-Index 04h UDID of the SCM
Name UDIDofSCM_ OSTR6
Data Type OCTET_STRING6 Category M
Value Range OCTET_STRING6 Access rw
Default Value UDID of the own SN
SPDO Mapping
No
2081
2082
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 106/191
5.6.4.13 Object 1201h: SSDO Communication Parameter 2083
This object defines the SSDO communication parameters of an SSDO client. 2084
2085
Index 1201h Object Type RECORD
Name SSDO_CommParam_REC
Data Type SSDO_CommParamRecord_TYPE Category C
Relevant for SOD checksum No
2086
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 2 Access ro
Default Value 2 SPDO Mapping No
2087
Sub-Index 01h The sub-index provides the timeout for an SSDO telegram. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name Timeout_U32
Data Type UNSIGNED32 Category M
Value Range 1-UNSIGNED32
Access rw
Default Value 500000 SPDO Mapping No
2088
Sub-Index 02h This sub-index provides the number of retries for an SSDO telegram. Name Retries_U8
Data Type UNSIGNED8 Category M
Value Range 0-255 Access rw
Default Value 0 SPDO Mapping No
2089
2090
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 107/191
5.6.4.14 Object 1202h: SNMT Communication Parameter 2091
This object defines the SNMT communication parameters of an SNMT master. 2092
2093
Index 1202h Object Type RECORD
Name SNMT_CommParam_REC
Data Type SNMT_CommParamRecord_TYPE Category C
Relevant for SOD checksum No
2094
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 2 Access ro
Default Value 2 SPDO Mapping No
2095
Sub-Index 01h The sub-index provides the timeout for an SNMT telegram. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name Timeout_U32
Data Type UNSIGNED32 Category M
Value Range 1-UNSIGNED32
Access rw
Default Value 500000 SPDO Mapping No
2096
Sub-Index 02h This sub-index provides the number of retries for an SNMT telegram. Name Retries_U8
Data Type UNSIGNED8 Category M
Value Range 0-255 Access rw
Default Value 0 SPDO Mapping No
2097
2098
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 108/191
5.6.4.15 Object 1400h –17FEh: RxSPDO Communication Par. 2099
This object defines from which SADR data is received. 2100
Attention: One producer can have more SADRs (one for each TxSPDO). Therefore one consumer 2101
can have more than one RxSPDO for the same physical producer. 2102
2103
Index 1400h – 17FEh Object Type RECORD
Name SPDO_RxCommParam_XXXh_REC
Data Type SPDO_RxCommParamRecord_TYPE Category O
Relevant for SOD checksum Yes
2104
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 0Ch Access ro
Default Value 0Ch SPDO Mapping No
2105
Sub-Index 01h Defines the SADR from which the RxSPDO data is to be received. Setting the SADR to zero, deactivates the SPDO.
Name SADR_U16
Data Type UNSIGNED16 Category M
Value Range 0-1023 Access rw
Default Value 0 SPDO Mapping No
2106
Sub-Index 02h Defines the SCT timer for the data from this RxSPDO (see chapter 5.7.1.2). The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name SCT_U32
Data Type UNSIGNED32 Category M
Value Range 1-UNSIGNED32
Access rw
Default Value 1 SPDO Mapping No
2107
Sub-Index 03h The sub-index provides the number of consecutive time requests. Name NumberOfConsecutiveTReq_U8
Data Type UNSIGNED8 Category M
Value Range 1-63 Access rw
Default Value 1 SPDO Mapping No
2108
Sub-Index 04h This sub-index provides the time delay between two sets of consecutive time requests. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name TimeDelayTReq_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access rw
Default Value 0 SPDO Mapping No
2109
Sub-Index 05h This sub-index provides the time delay between successful time synchronization and the next time
Name TimeDelaySync_U32
Data Type UNSIGNED32 Category M
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 109/191
Value Range UNSIGNED32 Access rw request. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Default Value 1 SPDO Mapping No
2110
Sub-Index 06h The sub-index provides the minimum allowed propagation delay between time request and time response. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name MinTSyncPropagationDelay_U16
Data Type UNSIGNED16 Category M
Value Range 1-65535 Access rw
Default Value 1 SPDO Mapping No
2111
Sub-Index 07h The sub-index provides the maximum allowed propagation delay between time request and time response. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name MaxTSyncPropagationDelay_U16
Data Type UNSIGNED16 Category M
Value Range 1-65535 Access rw
Default Value 1 SPDO Mapping No
2112
Sub-Index 08h The sub-index provides the minimum allowed propagation delay between sending and receiving a SPDO. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name MinSPDOPropagationDelay_U16
Data Type UNSIGNED16 Category M
Value Range 1-65535 Access rw
Default Value 1 SPDO Mapping No
2113
Sub-Index 09h The sub-index provides the maximum allowed propagation delay between sending and receiving a SPDO. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name MaxSPDOPropagationDelay_U16
Data Type UNSIGNED16 Category M
Value Range 1-65535 Access rw
Default Value 1 SPDO Mapping No
2114
Sub-Index 0Ah The sub-index provides the best case delay between sending the time request and setting up the time response. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name BestCaseTResDelay_U16
Data Type UNSIGNED16 Category M
Value Range 0-65535 Access rw
Default Value 0 SPDO Mapping No
2115
Sub-Index 0Bh The sub-index provides the time request cycle time. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name TimeRequestCycle_U32
Data Type UNSIGNED32 Category M
Value Range 1-UNSIGNED32
Access rw
Default Value 1 SPDO Mapping No
2116
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 110/191
Sub-Index 0Ch Contains the TxSPDO number with which the time request is to be sent. Name TxSPDONo_U16
This object defines the RxSPDO mapping parameters. The mapping parameters may be pre-defined 2118
by the vendor and read only. For a detailed description of the SPDO mapping, refer to 5.6.5. 2119
2120
Index 1800h – 1BFEh Object Type ARRAY
Name SPDO_RxMappParam_XXXh_AU32
Data Type UNSIGNED32 Category O
Relevant for SOD checksum Yes
2121
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 0-254 Access rw / ro
Default Value 0 SPDO Mapping No
2122
Sub-Index 01h The sub-index provides the mapping parameter for this RxSPDO Name SPDOMapping_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32
Access rw / ro
Default Value 0 SPDO Mapping No
2123
Sub-Index 02h - FEh The sub-index provides the mapping parameter for this RxSPDO Name SPDOMapping_U32
Data Type UNSIGNED32 Category O
Value Range UNSIGNED32
Access rw / ro
Default Value 0 SPDO Mapping No
2124
2125
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 111/191
5.6.4.17 Object 1C00h – 1FFEh: TxSPDO Communication Par. 2126
Each SN must have at least one TxSPDO, either for sending data (producer) or for the time request 2127
(consumer). 2128
2129
Index 1C00h – 1FFEh Object Type RECORD
Name SPDO_TxCommParam_XXXh_REC
Data Type SPDO_TxCommParamRecord_TYPE Category M/O
Relevant for SOD checksum Yes
2130
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 3 Access ro
Default Value 3 SPDO Mapping No
2131
Sub-Index 01h Defines the SADR that is used when broadcasting the data of the corresponding TxSPDO within the network. Setting the SADR to zero, deactivates the SPDO.
Name SADR_XXXh_U16
Data Type UNSIGNED16 Category M
Value Range 0-1023 Access rw
Default Value 0 SPDO Mapping No
2132
Sub-Index 02h The sub-index provides the refresh time of the Producer. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name RefreshPrescale_U16
Data Type UNSIGNED16 Category M
Value Range 1 - 32767 Access rw
Default Value 1 SPDO Mapping No
2133
Sub-Index 03h Defines the number of consecutive TRes for a received TReq. If the parameter is zero the TxSPDO can only be used for TReq telegrams (for devices which are consumers only).
Name NumberOfTRes_U8
Data Type UNSIGNED8 Category MC
Value Range UNSIGNED8 Access rw
Default Value 0 SPDO Mapping No
2134
5.6.4.18 Object 2800h – 2FFFh: User Par. (writeable at any time) 2135
These objects defines user parameters which can be written at any time. These parameters may not 2136
be part of the SOD CRC and access to these parameters using SLIM SSDO Services is prohibited. 2137
2138
The structure of these objects is vendor specific. 2139
This object defines the TxSPDO mapping parameters. The mapping parameters may be pre-defined 2141
by the vendor and read only. For a detailed description of the SPDO mapping, refer to 5.6.5. 2142
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 112/191
2143
Index C000h – C3FEh Object Type ARRAY
Name SPDO_TxMappParam_XXXh_AU32
Data Type UNSIGNED32 Category M/O
Relevant for SOD checksum Yes
2144
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 0-254 Access rw / ro
Default Value 0 SPDO Mapping No
2145
Sub-Index 01h The sub-index provides the mapping parameter for this TxSPDO Name SPDOMapping_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32
Access rw /
ro
Default Value 0 SPDO Mapping No
2146
Sub-Index 02h - FEh The sub-index provides the mapping parameter for this TxSPDO Name SPDOMapping_U32
Data Type UNSIGNED32 Category O
Value Range UNSIGNED32
Access rw /
ro
Default Value 0 SPDO Mapping No
2147
2148
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 113/191
5.6.4.20 Object C400h – C7FEh: SADR-DVI List 2149
This object only needs to be implemented if the SN has SCM functionality. It contains a list of all SNs 2150
within the SD. The list contains the parameters for each SN which are needed to verify the SN during 2151
start up. The maximum number of supported SNs is vendor specific. Therefore only the first two 2152
indices (C400h, C401h) are mandatory (one SN for the SCM and at least one additional SN), the rest 2153
are optional. 2154
2155
Index C400h – C7FEh Object Type RECORD
Name SSCM_SADRDVIList_XXXh_REC
Data Type SSCM_SADRDVIListRecord_TYPE Category C
Relevant for SOD checksum No
2156
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 0Fh Access ro
Default Value 0Fh SPDO Mapping No
2157
Sub-Index 01h Contains the expected SADR of the corresponding SN. Name SADR_U16
Data Type UNSIGNED16 Category M
Value Range 1-1023 Access rw
Default Value 0 SPDO Mapping No
2158
Sub-Index 02 Contains the Vendor ID of the corresponding SN. Name VendorId_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access rw
Default Value 0 SPDO Mapping No
2159
Sub-Index 03h Contains the product code of the corresponding SN. Name ProductCode_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access rw
Default Value 0 SPDO Mapping No
2160
Sub-Index 04h Contains the revision number of the corresponding SN. Name RevisionNumber_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access rw
Default Value 0 SPDO Mapping No
2161
Sub-Index 05h Status of the corresponding SN.
Name ModuleStatus_U8
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 114/191
Data Type UNSIGNED8 Category M Error States
0…missing
1…invalid
2…wrong SADR
3…UDID mismatch
4…wrong parameters
5…error additional parameters
6…incompatible version
7…127 reserved for future use
Positive States
128…valid
129…OK
130…255 reserved for future use
Value Range 0-6 Access Ro
Default Value 0 SPDO Mapping No
2162
Sub-Index 06h Reserved for compatibility reason.
Name Reserved
Data Type UNSIGNED16 Category M
Value Range UNSIGNED16 Access rw
Default Value 0 SPDO Mapping No
2163
Sub-Index 07h Timestamp of parameter set of the corresponding SN. Name ParameterSetTimestamp_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access rw
Default Value 0 SPDO Mapping No
2164
Sub-Index 08h Maximum length of the payload of a SSDO telegram. This parameter is important because not all SNs might support long SSDO frames.
Name MaximumSsdoPayloadLen_U16
Data Type UNSIGNED16 Category M
Value Range 8 – 254 Access rw
Default Value 8 SPDO Mapping No
2165
Sub-Index 09h This subindex provides the poll interval for the SNMT_SN_set_to_OP command. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8.
Name SnmtCrcPollInterval_U32
Data Type UNSIGNED32 Category M
Value Range UNSIGNED32 Access rw
Default Value 100 SPDO Mapping No
2166
Sub-Index 0Ah Contains the length of the parameter set for the corresponding SN. Name ParameterSetLength_U32
Data Type UNSIGNED32 Category O
Value Range UNSIGNED32 Access rw
Default Value 0 SPDO Mapping No
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 115/191
2167
Sub-Index 0Bh Contains the parameter set for the corresponding SN. This sub-index needs to be implemented if sub-index 0Ah was implemented.
Name ParameterSet_DOM
Data Type DOMAIN Category C
Value Range DOMAIN Access rw
Default Value 0 SPDO Mapping No
2168
Sub-Index 0Ch This is a bit filed where all optional protocols are to be specified.
Bit Value Description
0 0 Block up-/download not supported
1 Block up-/download supported
1 - 31
X reserved
Name OptionalFeatures_U32
Data Type UNSIGNED32 Category O
Value Range UNSIGNED32 Access rw
Default Value 0 SPDO Mapping No
2169
Sub-Index 0Dh Contains the inhibit time for the block up-/download. The time base of this parameter is defined by CommonCommParam_REC.ConsecutiveTimeBase_I8. This sub-index needs to be implemented if sub-index 0Ch was implemented.
Name InhibitTime_U32
Data Type UNSIGNED32 Category C
Value Range UNSIGNED32 Access rw
Default Value 0 SPDO Mapping No
2170
Sub-Index 0Eh Contains the SOD parameter checksum container (to be calculated as described below).
Timestamp
CRC32
CRC32
…
Name ParameterChecksum_DOM
Data Type DOMAIN Category M
Value Range DOMAIN Access rw
Default Value 0 SPDO Mapping No
2171
Sub-Index 0Fh Contains the parameter set for the corresponding SN. This can be used to store the information from 0x1080/0x06 for each SN, as it is read during the verification of the DVI.
Name RemoteParChecksum_DOM
Data Type DOMAIN Category C
Value Range DOMAIN Access rw
Default Value 0 SPDO Mapping No
2172
2173
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 116/191
5.6.4.21 Object C801h – CBFFh: Additional SADR List 2174
This Objects describe the addresses (SADR) of an SN. 2175
Sub index 1 describes the “Main-SADR” to which the corresponding address belongs. 2176
Sub index 2 describes an additional TxSPO address. 2177
The “Main-SADR” is the SADR of the 1st TxSPDO and is also used by the SSDO services. 2178
2179
Index C801h – CBFFh Object Type ARRAY
Name SSCM_SADRMembership_XXXh_AU16
Data Type UNSIGNED16 Category O
Relevant for SOD checksum No
2180
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 2 Access ro
Default Value 2 SPDO Mapping No
2181
Sub-Index 01h Contains the “Main-SADR” which uses the SADR for a TxSPDO Name SADR_U16
Data Type UNSIGNED16 Category M
Value Range 1-1023 Access rw
Default Value 0 SPDO Mapping No
2182
Sub-Index 02h Contains the TxSPDO number, the SADR is used for. Name TxSPDONo_U16
Data Type UNSIGNED16 Category M
Value Range 1-1023 Access rw
Default Value 0 SPDO Mapping No
2183
2184
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 117/191
Example: 2185
Index (hex) Sub-Index 0 Sub-Index 1 Sub-Index 2
C801 2 1 1
C802 2 2 1
C803 2 3 1
C804 2 1 2
C805 2 1 3
C806 2 0 0
2186
This configuration means: 2187
1st line : SADR 1 (Index – C800h) belongs to the SN with “Main-SADR” 1 and is used in TxSPDO 1 2188
2nd line : SADR 2 (Index – C800h) belongs to the SN with “Main-SADR” 2 and is used in TxSPDO 1 2189
3rd line : SADR 3 (Index – C800h) belongs to the SN with “Main-SADR” 3 and is used in TxSPDO 1 2190
4th line : SADR 4 (Index – C800h) belongs to the SN with “Main-SADR” 1 and is used in TxSPDO 2 2191
5th line : SADR 5 (Index – C800h) belongs to the SN with “Main-SADR” 1 and is used in TxSPDO 3 2192
6th
line : SADR 6 (Index – C800h) belongs to the SN with “Main-SADR” 0, 0 is not a valid SADR -> therefore this 2193
SADR does not belong to any SN 2194
We can see that the SN with “Main-SADR” 1 has 3 TxSPDOs using SADR 1, 4 and 5. SN 2 and 3 only 2195
have one SADR (therefore only 1 TxSPDO). 2196
2197
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 118/191
5.6.4.22 Object CC01h – CFFFh: SADR-UDID List 2198
These objects contain the information stating which UDIDs can belong to which SADR. One logical SN 2199
(described with the “Main-SADR”) can be switched between more than one physical module (modular 2200
machine parts). All valid modules (described by their UDID) are listed within these objects. 2201
2202
Index CC01h – CFFFh Object Type ARRAY
Name SSCM_SADRUDIDList_XXXh_AOSTR6
Data Type OCTET_STRING6 Category O
Relevant for SOD checksum No
2203
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 1-254 Access ro
Default Value 1 SPDO Mapping No
2204
Sub-Index 01h-FEh Contains the UDIDs which are allowed for the corresponding SADR. Name UDID_OSTR6
Data Type OCTET_STRING6 Category M
Value Range OCTET_STRING6 Access rw
Default Value 0 SPDO Mapping
No
2205
Example: 2206
2207
Index (hex) Sub-Index 0 Sub-Index 1 Sub-Index 2
CC01 2 50-aa-c0-43-56-3f 50-aa-c0-43-56-42
2208
This configuration means: 2209
For SADR 0001 (CC01h), two UDIDs are allowed. Either UDID 50-aa-c0-43-56-3f or 2210
50-aa-c0-43-56-42 are accepted as UDID for the module with SADR 0001. 2211
5.6.4.23 Object E400h – E7FEh: Additional Parameter List 2212
This object only needs to be implemented if the SN has SCM functionality. It contains a list of all 2213
additional parameter sets per SN within the SD. The maximum number of parameter sets per SN is 2214
16. Each element is implemented corresponding to it’s SADDR, therefore the address E400 2215
references SADDR 1, E401 references SADDR 2 and so on. Foreach parameter list entry, the index of 2216
the entry, the length of the parameter set and the parameter set itself has to be specified. None of 2217
these entries is relevant for the SOD checksum calculation. 2218
2219
All parameter sets are preceeded by their corresponding headers. For these headers see 5.6.4.10.1. 2220
2221
An SN is responsible to check, if the additional parameters transmitted are valid and can be used. 2222
Additionally, if an SN has the information, that he expects a set of additional parameters, but the SCM 2223
does not react on the SN Fail with a parameter download, the SN is not allowed to go to operational. 2224
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 119/191
2225
Index E400h – E7FEh Object Type ARRAY
Name SSCM_ADDPARAList_XXXh_ADO
Data Type DOMAIN Category C
Relevant for SOD checksum No
2226
Sub-Index 00h Number of Entries within this index.
Name NumberOfEntries
Value Range 0x00-0x10 Access ro
Default Value 0 SPDO Mapping No
2227
Sub-Index 0x01-0x11 Contains the first parameter set for this entry Name ParameterSet
Data Type DOMAIN Category O
Value Range DOMAIN Access rw
Default Value SPDO Mapping No
2228
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 120/191
5.6.5 Safety related PDO Mapping 2229
The real-time data transfer is performed by means of openSAFETY Process Data Objects (SPDO). 2230
Data length and mapping of application objects into SPDOs is determined by the corresponding SPDO 2231
mapping structures within the openSAFETY Object Dictionary. The mapping of application objects into 2232
an SPDO may be transmitted to a device during the device configuration process by applying the 2233
SSDO services to the corresponding entries of the Object Dictionary. 2234
2235
The length of SPDOs of a device is application-specific and has to be specified via the corresponding 2236
mapping object. 2237
2238
There are two uses for SPDOs. The first is data transmission and the second data reception. Transmit 2239
SPDOs (TxSPDOs) and Receive SPDOs (RxSPDOs) can be distinguished. Devices supporting 2240
TxSPDOs are SPDO producers and devices which are able to receive SPDOs are called SPDO 2241
consumers. 2242
2243
SPDOs are described by the SPDO communication parameter and the SPDO mapping parameter. 2244
For each SPDO, the pair of communication and mapping parameters is mandatory. The structures of 2245
this data types are explained. 2246
2247
SPDO communication parameter describes the communication capabilities of the SPDO. 2248
SPDO mapping parameter describes mapping for each object contained in SPDO payload data 2249
to object dictionary entries and vice versa 2250
2251
SPDO mapping may be variable or static. Static mapping is pre-defined by the vendor and may not be 2252
modified in any way. Variable mapping may be configured during commissioning. 2253
5.6.6 Transmit SPDOs 2254
The TxSPDO communication parameters are described by indices 1C00h – 1FFEh 2255
(SPDO_TxCommParam_XXXh_REC). An SN can support up to 1023 TxSPDOs. Only the 2256
implementation of the first TxSPDO is mandatory. The amount of additional TxSPDOs is vendor 2257
specific. The TxSPDO mapping parameters are described by indices C000h – C3FEh 2258
(SPDO_TxMappParam_XXXh_AU32). The data to be transmitted will be assembled according to the 2259
corresponding mapping data. 2260
2261
Sending SPDO data is implicitly limited to the operational state. 2262
2263
Refer to chapter 5.6 for the corresponding entries within the SOD. 2264
2265
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 121/191
5.6.7 Receive SPDOs 2266
The RxSPDO communication parameters are described by indices 1400h – 17FEh 2267
(RxSPDOCommParam_XXXh_REC). An SN can support up to 1023 RxSPDOs. The implementation 2268
of RxSPDOs is optional (e.g. an input module, which is a simple producer, does not need to have a 2269
RxSPDO). The RxSPDO mapping parameters are described by indices 1800h – 1BFEh 2270
(SPDO_RxMappParam_XXXh_AU32). The received data will be transferred to the communication 2271
objects assigned to them by the RxSPDO mapping parameters. The application accesses the 2272
received SPDO data by reading out these communication objects. 2273
2274
Receiving SPDO data is implicitly limited to the operational state. 2275
2276
Refer to chapter 5.6 for the corresponding entries within the SOD. 2277
5.6.8 SPDO Mapping Parameter 2278
The indices 1800h – 1BFEh (SPDO_TxMappParam_XXXh_AU32) and C000h – C3FEh 2279
(SPDO_RxMappParam_XXXh_AU32) contain the mapping parameters for transmitting and receiving 2280
SPDOs. For both indices, sub-index 0 contains the number of valid mapping entries which is also the 2281
number of communication variables (SOD entries) to be transmitted/received. The sub-indices 01h to 2282
‘number of entries’ contain information about the mapped application variables. These entries describe 2283
the SPDO contents by their index, sub-index and length (see Tab. 59). All three values are 2284
hexadecimal. The length entry contains the length of the object in bits (01h – FFh). This parameter can 2285
be used to check the overall mapping length. 2286
2287
The structure of a mapping entry (sub-index 01h – FEh) is as follows: 2288
b31 – b16 b15 – b8 b7 – b0
Index (16bit) sub-index (8bit) data length (8bit)
Tab. 59 Structure of SPDO mapping entry 2289
The commissioner is responsible for the correctness of the mapping data. If objects are mapped which 2290
may not be mapped according to the object attribute, the SN will not change to Operational. If data 2291
within a RxSPDO is not used by the consumer, it may be mapped to the data types ( index 0001h – 2292
0007h ). They serve as “dummy entries”. The corresponding data within the RxSPDO is not evaluated 2293
by the device. This feature is useful if a TxSPDO is used for several consumers, each only utilizing 2294
parts of the transmitted data. It is not possible to map those “dummy entries” into a TxSPDO. 2295
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 122/191
5.6.9 SPDO Mapping Example 2296
2297
Fig. 41. SPDO mapping example 2298
The SN with “Main-SADR” 12 is an input module with 32 digital inputs. 2299
The SN with “Main-SADR” 13 is an output module with 8 digital outputs. 2300
The SN with “Main-SADR” 14 is an output module with 16 digital outputs. 2301
2302
Assume that the inputs are available at SOD-index 6000h sub-indices 01h – 04h and that the data 2303
type is UNSIGNED8. Also assume that the outputs need to be written to SOD index 6200h sub-indices 2304
01h respectively 01h and 02h. The data type again is UNSIGNED8. Then, assume that SN 13 needs 2305
the information from the 3rd
input byte and SN 14 needs the information from the 1st and 4
th input byte. 2306
2307
The communication parameters from SN12 (producer) looks as following: 2308
Index Sub-Index Data Description
1C00h 1 12 The TxSPDO is broadcast under the SADR 12
Tab. 60 Mapping example table 1 2309
2310
The mapping of SN 12 (producer) may be specified as follows: 2311
Index Sub-Index Data Description
C000h 0 4 four valid mapping entries
1 60 00 01 08 h Mapping entry 1: 8bits of the object from index 6000h sub-index 1 are mapped into the SPDO
2 60 00 02 08 h Mapping entry 2: 8bits of the object from index 6000h sub-index 2 are mapped into the SPDO
3 60 00 03 08 h Mapping entry 3: 8bits of the object from index 6000h sub-index 3 are mapped into the SPDO
4 60 00 04 08 h Mapping entry 4: 8bits of the object from index 6000h sub-index 4 are mapped into the SPDO
Tab. 61 Mapping example table 2 2312
2313
SN
CN with multiple SNs
SN
MN
SCM
FM
CN
Modular CN with multiple SNs
SN
Direct Communication between a SN and a
specific bit of another SN
SADR 14
SADR 12
SADR 13
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 123/191
This TxSPDO mapping could be a pre-defined mapping. Input 2 is mapped into the TxSPDO although 2314
it is not needed by any of the SNs. 2315
2316
According to the mapping parameters the payload data of the TxSPDO looks as following: 2317
Byte Data
1 Input Byte 1
2 Input Byte 2
3 Input Byte 3
4 Input Byte 4
Tab. 62 Mapping example table 3 2318
2319
The communication parameter for SN 13 is specified as follows: 2320
Index Sub-Index Data Description
1400h 1 12 SN 13 will map the data of a received TxSPDO from SADR 12 according to the mapping entries
Tab. 63 Mapping example table 4 2321
2322
The mapping of the SN 13 looks as following: 2323
Index Sub-Index Data Description
1800h 0 2 two valid mapping entries
1 00 06 00 10 h Mapping entry 1: 16 bits of the RxSPDO are mapped into the object at index 0006h sub-index 0
2 62 00 01 08 h Mapping entry 2: 8bits of the RxSPDO are mapped into the object at index 6200h sub-index 1
3 00 05 00 08 h Mapping entry 2: 8bits of the RxSPDO are mapped into the object at index 0005h sub-index 0
Tab. 64 Mapping example table 5 2324
As described above, SN 13 is only interested in the 3rd
input byte of SN 12. Therefore, the first two 2325
input bytes (first two bytes of the RxSPDO) are ignored by using “dummy mapping”. The 4th byte is 2326
also mapped to a “dummy entry”. This is required because only RxSPDOs which have the same 2327
length as the mapped data are accepted. 2328
2329
The communication parameter of SN 14 look as following: 2330
Index Sub-Index Data Description
1400h 1 12 SN 14 will map the data of a received TxSPDO from SADR 12 according to the mapping entries
Tab. 65 Mapping example table 6 2331
2332
2333
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 124/191
The mapping of the SN 14 looks as following: 2334
Index Sub-Index Data Description
1800h 0 3 three valid mapping entries
1 62 00 01 08 h Mapping entry 1: 8bits of the RxSPDO are mapped into the object at index 6200h sub-index 1
2 00 06 00 10 h Mapping entry 2: 16 bits of the RxSPDO are mapped into the object at index 0006h sub-index 0
3 62 00 02 08 h Mapping entry 3: 8bits of the RxSPDO are mapped into the object at index 6200h sub-index 2
Tab. 66 Mapping example table 7 2335
2336
As described above, SN 14 is only interested in input bytes 1 and 4 of SN 12. Input bytes 2 and 3 2337
(respectively byte 2 and 3 of the RxSPDO) are ignored by using dummy mapping. 2338
5.6.10 SPDO Error Handling 2339
Non-Map able Application Object 2340
The SN has to ensure that only mappable application objects will be accepted. If a non-mappable 2341
object is recognized, the SN may not store this mapping data into the SOD. As a result of this, the 2342
checksum of the SOD will be different from the expected checksum stored on the SCM and therefore 2343
the SN will not be switched to the operational state (see 5.7.13). 2344
Unexpected length of RxSPDO 2345
If an SPDO is received with a length that is not equal to the length of the mapped data, the SPDO has 2346
to be ignored. Additional diagnosis data may be provided via the SOD. 2347
2348
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 125/191
5.7 State - / Sequence Diagrams 2349
5.7.1 Safety Process Data Object (SPDO) 2350
5.7.1.1 Safety Process Data Object Producer (TxSPDO) 2351
Tx
IDLE
(delta-t expired) OR
((data(new) exists) AND (CT
increased))
data sent
2352
Fig. 42. State diagram “TxSPDO” 2353
2354
2355
Fig. 43. SPDO communication producer 2356
Item Description Min Value Max value SOD
data_new New data from safety related application or new TRes received
- - -
t Internal time [CT] 0 65535 -
t Refresh prescale [CT] 1 32767 Object Index 1C00h – 1FFEh
sub index 2h (see 5.6.4.17)
t1 Time difference of new data [CT] >0 t -
Tab. 67 SPDO communication producer item description 2357
Description: The producer starts sending its data cyclically or on state changes when switching to 2358
operational. The refresh time for sending the data can be adjusted within the SOD. 2359
State Description
Tx Sending data
IDLE Wait until refresh time elapsed or new data available
Producer
data & t
data & (t+t)
data_new & (t+t+t1)
t
Event Non safe communi-
cation layer
data_new
data & t
data & (t+t)
data_new & (t+t+t1)
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 126/191
Tab. 68 SPDO communication producer state description 2360
5.7.1.2 Safety Process Data Object Consumer (RxSPDO) 2361
2362
Fig. 44. State diagram “RxSPDO” 2363
2364
2365
Fig. 45. SPDO communication consumer 2366
2367
Consumer
data1 & t1
data1 & t1
data1 & t2
data2 & t2
data2(corrupted) & t2
data2(corrupted) & t3
data2(corrupted) & t3
data2(corrupted) & t3
data2 & t3
Non safe communi-cation layer
data1 & t1
data1 & t2
data2 & t2
data2 & t3
new data, new time, process data
old data, old time, ignore
old data, new time, process data
new data, old time, ignore
data corrupted, ignore
data corrupted, ignore
SCT elapsed, set RxSPDO data to safe state,
new data, new time, process data
IDLE
Process data
data received
SCT elapsed
Set RxSPDO data to safe
state
Write diagnose data
to SOD
Start SCT
Data
invalid
Data
valid
data received Time synchronization failure
Consumer
data1 & t1
data1 & t1
data1 & t2
data2 & t2
data2(corrupted) & t2
data2(corrupted) & t3
data2(corrupted) & t3
data2(corrupted) & t3
data2 & t3
Non safe communi-cation layer
data1 & t1
data1 & t2
data2 & t2
data2 & t3
new data, new time, process data
old data, old time, ignore
old data, new time, process data
new data, old time, ignore
data corrupted, ignore
data corrupted, ignore
SCT elapsed, set RxSPDO data to safe state,
new data, new time, process data
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 127/191
2368
Item Description Min Value Max value SOD
SCT Safety control time [CT] 1 UNSIGNED32-
Object 1400h – 17FEh sub index 2h (see 5.6.4.15)
Tab. 69 SPDO communication consumer item description 2369
2370
Description: This state diagram is performed for each RxSPDO. The consumer gets cyclic data 2371
from a producer. The data will be processed. Processing data includes time 2372
synchronization and time validation, see 5.7.1.2.1. If a consumer receives valid data 2373
from a producer, the SCT timer is restarted. If the SCT timer elapses, all data related 2374
to the RxSPDO will be set to a safe state. 2375
2376
State Description
IDLE Waiting for data.
Process data Performing timing validation and time synchronization. Process data according to SPDO mapping.
Start SCT Reset the SCT.
Write diagnose data to SOD The diagnose data has to be available for the user. This is made through the SOD.
Set RxSPDO data to safe state All data related to the producer will be set to zero.
Tab. 70 SPDO communication consumer state description 2377
2378
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 128/191
5.7.1.2.1 Process Data 2379
Validate
RxSPDO
frame
Process
TRes
Data with TRes received
Check
propagation
delay
deviation
Data without
TRes received
Validate
timestamp
CT valid or
no CT for validation available
CT is not valid
Data is ok
[propagation delay deviation is ok]
Map data
CT for validation available
/ store CT for next validation
Set RxSPDO
to safe state
no CT for
validation available
/ store CT for next validation
Time synchronization failure
[propagation delay too short]
/ delete CT for validation Data is invalid
[propagation delay too long]
2380
Fig. 46. State diagram “Process Data” 2381
Item Description Min Value Max value SOD
CT Consecutive time field 0 65535 -
TRes Time synchronization response, consists of TR (Time Request Distinctive Number Field) and TADR (Time Request Address) within the safety frame
- - -
Tab. 71 SPDO communication consumer telegram validation item description 2382
State Description
Validate timestamp If the timestamp (CT) is equal to or less than the timestamp of the previously valid telegram, the telegram will be ignored.
Validate RxSPDO frame Checks if the frame contains time synchronization data for this node.
Process TRes See 5.7.2.6
Check propagation delay deviation Checks if the timestamp is valid or not.
Set RxSPDO to safe state All cyclic data related to this RxSPDO is set to the safe state
Map data Writes the data into the SOD according to the RxSPDO mapping
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 129/191
Tab. 72 SPDO communication consumer telegram validation state description 2383
5.7.2 Time Synchronization and Validation 2384
To verify the performance of the non safe communication layer, openSAFETY uses a combined time 2385
synchronization and validation sequences. Because of tolerances of the hardware clocks within the 2386
safety nodes, this has to be done cyclically. The following figure shows the basic sequences how the 2387
time synchronization and validation are carried out. 2388
2389
2390
Fig. 47. Time Synchronization and Validation 2391
2392
Time Validation
Time Synchronization
Producer Consumer
T RefProducer T RefConsumer
T SPDOConsumer
T SPDOConsumer
T SPDOConsumer
T SPDOConsumer
T SPDOProducer
T SPDOProducer
T SPDOProducer
T SPDOProducer
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 130/191
5.7.2.1 Time Synchronization 2393
The consumer starts the sequence by sending a set of Time Requests (TReq) to the producer. This is 2394
done by using a TxSPDO. When receiving the first TReq, the producer creates a “new data event” 2395
(see 5.7.1.1) to reply to the request as soon as possible with the corresponding set of Time 2396
Responses (TRes). Then the first received TRes within the consumer is checked against the minimum 2397
and maximum allowed TSync propagation delay. If the delay is shorter then the minimum allowed 2398
delay, the consumer must enter the fail safe state, because in this case the best case TRes delay 2399
parameter has been set wrong. If the delay is longer then the maximum allowed delay, the time 2400
response is ignored. If delay is within the given limits, time synchronization was successful and the 2401
consumer memorizes the internal T RefProducer and T RefConsumer values. 2402
2403
The following figure shows in detail the Time Synchronization Sequence: 2404
2405
2406
Fig. 48. Time Synchronization Detail 2407
2408
Time Validation
Time Synchronization
Producer Consumer
Best case TRes delay
T RefProducer T RefConsumer Minimum allowed TSync propagation delay
Maximum allowed TSync propagation delay
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 131/191
2409
Item Description Min Value
Max value
SOD
T RefProducer value of CT field within the TRes service supplied by the producer
0 65535 -
best case TRes delay
user defined value to define the best case minimum time needed to transfer the time request from the consumer to the producer and to set up the time response within the producer. This value is used to calculate the SPDO propagation delay. If the user assumes a larger value as it is in reality, the time validation would not recognize impermissible delays in the SPDO propagation.
0 65535 Object index 1400h – 17FEh sub index Ah (see 5.6.4.15)
T RefConsumer Time Request start time [CT] + best case TRes delay [CT] this value is calculated within the consumer and gives a time reference within the consumers CT to T RefProducer.
> best case TRes delay
65535 -
Minimum allowed TSync
propagation delay
Minimum allowed propagation delay for time synchronization [CT]
1 65535 Object index 1400h – 17FEh
sub index 6h (see 5.6.4.15)
Maximum allowed TSync
propagation delay
Maximum allowed propagation delay for time synchronization [CT]
1 65535 Object index 1400h – 17FEh
sub index 7h (see 5.6.4.15)
Tab. 73 Time synchronization item description 2410
2411
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 132/191
5.7.2.2 Time Validation 2412
After successful time synchronization, the consumer is able to receive SPDOs and to calculate the 2413
Fig. 50. Time Validation, Propagation Delay Explanation Limits 2427
Item Description Min Value
Max value
SOD
T SPDOProducer value of CT field within the SPDO supplied by the producer
0 65535 -
T SPDOConsumer CT value within the consumer when receiving the SPDO
0 65535 -
SPDO propagation delay
calculated propagation delay using the time references of the previous time synchronization: (T SPDOConsumer - T RefConsumer) - (T SPDOProducer -T RefProducer)
0 65535 -
Minimum allowed SPDO
propagation delay
Minimum allowed propagation delay for SPDO [CT]
1 65535 Object index 1400h – 17FEh sub index 8h (see 5.6.4.15)
Maximum allowed SPDO
propagation delay
Maximum allowed propagation delay for SPDO[CT]
1 65535 Object index 1400h – 17FEh sub index 9h (see 5.6.4.15)
Tab. 74 Time validation item description 2428
2429
Time Validation
delay to short, enter FAIL Safe Sate
Time Synchronization
Producer Consumer
T RefConsumer
delay to large, SPDO is ignored
Maximum allowed SPDO propagation delay
Minimum allowed SPDO propagation delay
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 134/191
5.7.2.3 Time Synchronization Operation 2430
To increase the immunity of openSAFETY against data loss within the non safe communication layer, 2431
the TReq and TRes services are sent as bundle of single services. 2432
The consumer sends m time requests (TxSPDO) to the producer containing the TR (Time Request 2433
Distinctive Number). This number is incremented with each time request. The producer receives the 2434
time request from a specific node and starts answering the time request. The response to a time 2435
request is to fill the TADR (SADR of the requesting node) and the TR field in the cyclic TxSPDO 2436
telegram from the producer. The producer repeats the response for a received time request n times 2437
although new time requests were already received. This ensures that the consumer which initiates the 2438
time request receives the correct answer. During processing the Time Response, the producer ignores 2439
all other time requests corresponding to this TxSPDO regardless the time request comes from the 2440
same consumer or from another one. 2441
If the consumer did not receive the time response within td, the next set of time requests is sent. The 2442
number of time responses per time request, the number of requests per consecutive request set, td 2443
and the timer ts which re-initiates a time request are to be adjusted within the SOD. If the propagation 2444
delay is too long the TRes is ignored, if it is too short, the fail safe state must be entered (see 5.7.2.1). 2445
If a valid TRes was not received within the Time request cycle, a time synchronization failure occurs. 2446
The time synchronization for each producer starts when the consumer is operational and receives the 2447
first RxSPDO from the corresponding producer. 2448
Within a Consumer / Producer relationship, equal CT values are mandatory. 2449
2450
2451
Fig. 51. Time synchronization on a nonsafe network 2452
The above figure shows how a time request and response can look on the bus system. The consumer 2453
sends a time request to one of its producers. This request is repeated m times. The producer answers 2454
the first time request, and it receives and repeats the answer n times. If a producer receives a time 2455
request during the time it is already answering another time request on the corresponding TxSPDO, 2456
Producer Nonsafe communication
layer
Consumer Nonsafe network
TReq (TR=0)
TReq (TR=1)
TReq (TR=2)
m
TRes (TR=2)
n
TRes #1, TR=2
TRes #2, TR=2
Ignore TReq TR=3
TRes #3, TR=2
TRes #4, TR=2
TReq (TR=3)
Nonsafe communication
layer
Propagation delay of time
synchronization
Δt of the producer
Δt of the consumer
TReq received, new_data event
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 135/191
the new time request is ignored. The figure also shows that the “nonsafe network” may also loose or 2457
delay messages due to different network cycle times or other effects. 2458
2459
2460
Fig. 52. Explanation of time synchronization 2461
The consumer sends a set of m time requests (TReq) and then waits for the response. If the response 2462
time is shorter then the minimum allowed propagation delay, the fail safe state must be entered. If the 2463
response (TRes) is within the maximum and minimum allowed propagation delay, it is valid. If no 2464
response is received within the maximum allowed propagation delay, the consumer waits until td has 2465
elapsed and sends the next set of m TReq. 2466
2467
2468
Fig. 53. Time synchronization failure 2469
The above figure shows a time synchronization failure. The consumer sends time requests to the 2470
producer. If a valid time response is not received within the entire time synchronization cycle time, a 2471
synchronization failure occurs. This also ensures that the related outputs will enter the safe state. 2472
2473
Producer Consumer Maximum allowed propagation delay = 60 [CT]
td = 100 [CT]
Time request cycle = 800 [CT]
Time request cycle elapsed without successful TRes -> time
synchronization failure occurs
Time between two sets of TReq = Maximum allowed propagation delay
+ td = 160 [CT]
Time request cycle time
Producer Consumer
m TReq sent
Maximum allowed TSync propagation delay
td
Propagation delay must be smaller than the Maximum allowed TSync propagation delay
m TReq sent
Maximum allowed TSync propagation delay
Delayed TRes is ignored
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 136/191
Item Description Min Value
Max value SOD
n Number of TRes from Producer 1 255 Object index 1C00h – 1FFEh sub index 3h (see 5.6.4.17)
TR Time Request Distinctive Number
Consumer: To be incremented each TReq
0 63 -
m Number of consecutive TReq from consumer
1 63 Object index 1400h – 17FEh sub index 3h (see 5.6.4.15)
td Time delay between two TReq blocks [CT]
0 UNSIGNED32 Object index 1400h – 17FEh sub index 4h (see 5.6.4.15)
ts Time delay for new synchronization [CT]. The delay between successful time synchronization and the next TReq.
1 UNSIGNED32 Object index 1400h – 17FEh sub index 5h (see 5.6.4.15)
Time request cycle [CT] 1 UNSIGNED32 Object index 1400h – 17FEh sub index Bh (see 5.6.4.15)
Maximum allowed TSync propagation delay
1 65535 Object index 1400h – 17FEh sub index 7h (see 5.6.4.15)
Tab. 75 Extended Time synchronization item description 2474
2475
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 137/191
5.7.2.4 Time Synchronization Frequency 2476
The frequency of the Time Synchronization may be estimated as follows: 2477
Equation 1. Calculation of time Syncrhonization Frequency 2480
2481
Item Description Min Value
Max value SOD
Time request cycle [CT] 1 UNSIGNED32 Object index 1400h – 17FEh sub index Bh (see 5.6.4.15)
SCT Safety control time [CT] 1 UNSIGNED32 Object 1400h – 17FEh sub index 2h
(see 05.6.4.15)
Max. allowed SPDO propagation delay [CT]
1 65535 Object index 1400h – 17FEh sub index 9h (see 05.6.4.15)
TimeAccuracy: Overall Time Accuracy of Consumer and Producer, this term is mainly determined by the system, the quartz crystal, etc
- - -
Tab. 76 Time synchronization Frequency item description 2482
2483
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 138/191
5.7.2.5 Time Synchronization Producer 2484
2485
Fig. 54. State diagram “Time Synchronization Producer” 2486
2487
Item Description Min Value
Max value
SOD
n Number of TRes from Producer 1 255 Object index 1C00h – 1FFEh sub index 3h (see 05.6.4.17)
Tab. 77 Time synchronization producer item description 2488
State Description
IDLE The producer waits for a time request from any consumer.
Process Time Request After a time request from a consumer, the producer starts answering this request.
Attention: the response to a Time Request is not a separate telegram. It is just part of the normal TxSPDO.
Tab. 78 Time synchronization producer state description 2489
IDLE
Process Time Request
time request received n time responses sent
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 139/191
5.7.2.6 Time Synchronization Consumer 2490
2491
Fig. 55. State diagram “Time Synchronization Consumer” 2492
2493
IDLE
Send
Time Request
m TReq sent and maximum
propagation delay expired
TRes received and propagation delay
Ok
Δt or new data [not m Treq sent] / increase TR
TReq sent
Wait td
Sync Ok
/reset m, reset time request cycle time
td expired
Time request cycle time expired
Time request cycle time expired or number of not answered TR expired or (TRes received and Propagation delay is shorter then minimum allowed propagation delay)
Wait ts ts expired
Time synchronization failure occurred
(refer to Tab. 68)
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 140/191
2494
Item Description Min Value
Max Value
SOD
TReq Time synchronization request
- - -
m Number of consecutive TReq from consumer
1 63 Object index 1400h – 17FEh sub index 3h (see 05.6.4.15)
TR Time Request Distinctive Number Field
0 63 -
t TxSPDO refresh prescale [CT]
1 32767 Object index 1400h – 17FEh sub index 2h (see 05.6.4.15)
td Time delay between two TReq blocks [CT]
0 UNSIGNED32
Object index 1400h – 17FEh sub index 4h (see 5.6.4.15)
ts Time delay for new synchronization [CT]. The delay between successful time synchronization and the next TReq.
1 UNSIGNED32
Object index 1400h – 17FEh sub index 5h (see 5.6.4.15)
Minimum allowed propagation delay for time synchronization [CT]
1 65535 Object index 1400h – 17FEh sub index 6h (see 5.6.4.15)
Maximum allowed propagation delay for time synchronization [CT]
1 65535 Object index 1400h – 17FEh sub index 7h (see 5.6.4.15)
Time request cycle [CT] 1 UNSIGNED32
Object index 1400h – 17FEh sub index Bh (see 5.6.4.15)
Tab. 79 Time synchronization consumer item description 2495
State Description
Send Time Request Sending the time request to the corresponding producer.
IDLE Waiting for TRes.
Wait td Waiting until td expired. All received TRes are ignored.
Wait ts Waiting until ts expired. All received TRes are ignored.
Sync Ok Synchronization Ok. Reset m reset time request cycle time. Reset number of not answered TR.
Tab. 80 Time synchronization consumer state description 2496
2497
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 141/191
5.7.3 Safety Service Data Object (SSDO) 2498
5.7.3.1 SSDO Client 2499
2500
Fig. 56. State diagram “SSDO Client” 2501
Item Description Min Value
Max Value
SOD
n Max. count of retries 0 UNSIGNED8
Object index 1201h sub index 2h
(see 5.6.4.13)
Timeout of SSDO Response [CT]
1 UNSIGNED32
Object index 1201h sub index 1h
(see 5.6.4.13)
Tab. 81 SSDO client item description 2502
Description: 2503
The client sends an SSDO Request telegram to the server. If a response is received or a response is 2504
not required, the client can continue (more SSDO telegrams, etc) If the response is timed out, the 2505
client retries to send the telegram n times. The number of retries as well as the timeout time for an 2506
SSDO Response telegram is to be set within the SOD of the client. 2507
State Description
Send SSDO Request Sending the SSDO telegram to the server
Wait for SSDO Response Waiting for the response from the server
SSDO Request Error Handling If the maximum number of retries was not reached, the telegram will be sent again otherwise a communication error occurs.
Write diagnose data to SOD The diagnose data has to be available for the user. This is made through the SOD of the client.
Tab. 82 SSDO client state description 2508
Send SSDO
Request
Wait for SSDO Response
SSDO Request
Error Handling SSDO Response timeout
n retries not exceeded
SSDO Response
received
n retries exceeded
Write diagnose data to client SOD
[response required]
[no response required]
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 142/191
5.7.3.2 SSDO Server 2509
2510
Fig. 57. State diagram “SSDO Server” 2511
2512
Description: 2513
The server receives an SSDO request telegram from the client. The telegram is processed according 2514
to the ID field. During processing an SSDO Response is generated and sent back to the client. 2515
2516
State Description
IDLE Waiting for SSDO Access Request telegrams
Process SSDO Request Process the telegram according to the SSDO Access Command. Generate SSDO Response.
Tab. 83 SSDO server state description 2517
2518
IDLE
Process
SSDO Request
SSDO request received
[response required] /
send SSDO Response
[no response required]
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 143/191
5.7.4 SOD Access 2519
The SOD Access is based on the SSDO services. The SSDO service is used by the client to access 2520
the SOD (openSAFETY Object Dictionary) within the server. 2521
Write access to the SOD is permitted 2522
in Pre-Operational state for all parameters 2523
in Operational state for user parameters within 0x2800 – 0x2FFF index range. These 2524
parameters may not be part of the SOD CRC. For write access to these parameters it’s not 2525
SOD Access Request (SACmd(sequence), SANo+1, Data 1)
SOD Access Response (SACmd(OK), SANo+1,)
SOD Access Request (SACmd(sequence), SANo+2, Data 2)
SOD Access Response (SACmd(OK), SANo+2,)
.
.
.
.
.
.SOD Access Request (SACmd(sequence), SANo+n, Data n)
SOD Access Response (SACmd(OK), SANo+n,)
SOD Access Request (SACmd(end sequence), SANo+n+1, Data n+1)
SOD Access Response (SACmd(OK), SANo+n+1,)
SN
First SDO carries the size of the data to be downloaded
SCM
First data telegram must have the toggle bit set to zero
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 146/191
5.7.4.2.2 Server state diagram 2550
2551
Fig. 61. State diagram “Segmented SOD Download Access Server” 2552
2553
Item Description Min Value Max value SOD
toggle bit The toggle bit is used to identify new segments. 0 1 -
data size 4 byte value which identifies the size of data being downloaded with the segmented SOD Access.
1 UNSIGNED32
-
size Size of the received data 0 UNSIGNED32
-
SACmd Safety Access Command - - -
Tab. 87 Segmented SOD Access server item description 2554
2555
Check SACmd
Store data size
[initiate segmented
download received] / start
segmented download Check if
segmented download is in
progress
Append data to data-buffer
/ delete data-buffer, set internal
toggle bit
Create “Ok” Response
Check toggle bit
[segment received]
Yes
[toggle bit = internal toggle
bit] / invert internal toggle
bit
Append data to data-buffer
[end segmented download received]
Check if segmented
download is in
progress
Yes / end segmented
download
Check size of downloaded data
Create “Error” Response
[size != stored data size]
[toggle bit != internal toggle bit]
No No
[size = stored data size] / write stored data to SOD
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 147/191
Description: 2556
The server which receives the data via the segmented download has to verify the correctness of the 2557
telegrams. If a download is initiated, the server stores the data size which has to be received during 2558
the entire download. 2559
When the download is complete this data size is cross-checked with the size of the received data. If 2560
the received data is not equal to the expected data size, the server has to respond with an error 2561
telegram. If the server receives “segment” or “end segmented download” telegrams, it also needs to 2562
check if the download was initiated. Otherwise the data is to be ignored and an error response needs 2563
to be generated. 2564
During the segmented download, the toggle bit of the “segment” telegrams has to be inverted for each 2565
new telegram. If the server receives two or more consecutive telegrams with the same toggle bit, only 2566
the data of the first telegram is stored, all other telegrams are to be ignored. 2567
2568
State Description
Check SACmd Checks which type of telegram was received
Store data size Stores the expected data size for cross-check
Append data to data-buffer Writes the received data into a temporary buffer
Create “Ok” Response If the telegram was valid, the server sends a response to the client which indicates that the telegram was processed.
Check if segmented download is in progress
If a “segment” or “end segmented download” telegram was received, the server has to check if the segmented download was initialized.
Check toggle bit Each “segment” telegram carries a toggle bit which has to be inverted for each new telegram.
Check size of downloaded data
At the end of the segmented download, the server checks if the expected data size is equal to the received data size. If not, an error response is generated.
Create “Error” response Creates an error response which tells the client that the segmented download failed.
Tab. 88 Segmented SOD Access server state description 2569
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 148/191
5.7.4.3 SOD Block Download Access 2570
5.7.4.3.1 Client state diagram 2571
Initiate block
download
Error handlingSend block
segments
End block
download
Block download
successfully initialized
/ reset n, set toggle bit
Segment n sent
[remaining segments = 1]
/ invert toggle bit
Segment n sent
[remaining segments > 1]
/ invert toggle bit
Block download
initialization failed
Block download
not successfully
ended
Block download
successfully ended
/ report to
module application
2572
Fig. 62. State diagram “SOD Block Download Access client” 2573
SCM SN
SOD Access Request (SACmd(start sequence), SANo, Index, Subindex, Data Size, Data
Block SOD Access is used to download a large amount of data to the SN (e.g. the entire SOD during 2581
parameterization) without the need of a confirmation for each segment. It consists of the initialization 2582
telegram, the block download telegram and the end telegram. The initialization telegram carries the 2583
size of the data to be downloaded as payload. The segment download telegrams carry data only. The 2584
end telegram carries the last data segment as payload. If one telegram fails, the entire download 2585
needs to be repeated. 2586
2587
State Description
Initiate block download Starts the SOD Access with the initialization telegram.
Send block segments Starts the SOD Access with a block download telegram.
End block download Starts the SOD Access with the end download telegram.
Error handling Reports the communication error to the application.
Tab. 90 SOD Block Download Access client state description 2588
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 150/191
5.7.4.3.2 Server state diagram 2589
Check SACmd
Check if block
download is in
progress
[block segment received]
Check toggle bit
Yes
Store data size
Append data to
buffer
Check if block
download is in
progress
Append data to
buffer
Check size of
downloaded
data
Append data to
buffer
Create „OK“
response for
end telegram
Create „OK“
response for
initiate telegram
Create „Error“
response
[toggle bit !=
internal toggle bit]
[initiate block download received]
/ start block download
/delete data buffer,
set internal toggle bit
[end block download received]
Yes
[received size ==
stored size]
[received size !=
stored size]
[toggle bit == internal toggle bit]
/ invert internal toggle bit
No
No
2590
2591
Fig. 64. State diagram “SOD Block Download Access Server” 2592
2593
Item Description Min Value Max value SOD
toggle bit The toggle bit is used to identify new segments. 0 1 -
data size 4 byte value which identifies the size of data being downloaded with the segmented SOD Access.
1 UNSIGNED32
-
size Size of the received data 0 UNSIGNED32
-
SACmd Safety Access Command - - -
Tab. 91 SOD Block Download Access server item description 2594
2595
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 151/191
Description: 2596
The server which receives the data via the block download has to verify the correctness of the 2597
telegrams. If a download is initiated, the server stores the data size which has to be received during 2598
the entire download. 2599
When the download is complete this data size is cross-checked with the size of the received data. If 2600
the received data is not equal to the expected data size, the server has to respond with an error 2601
telegram. If the server receives “segment” or “end segmented download” telegrams, it also needs to 2602
check if the download was initiated. Otherwise the data is to be ignored and an error response needs 2603
to be generated. 2604
During the segmented download, the toggle bit of the “segment” telegrams has to be inverted for each 2605
new telegram. If the server receives two or more consecutive telegrams with the same toggle bit, only 2606
the data of the first telegram is stored, the other telegram is to be ignored. 2607
2608
State Description
Check SACmd Checks which type of telegram was received
Store data size Stores the expected data size for cross-check
Append data to data-buffer Writes the received data into a temporary buffer
Create “Ok” response for initiate telegram
If the telegram was valid, the server sends a response to the client which indicates that the telegram was processed.
Create “Ok” response for end telegram
If the telegram was valid, the server sends a response to the client which indicates that the telegram was processed.
Check if block download is in progress
If a “block” or “end block download” telegram was received, the server has to check if the block download was initialized.
Check toggle bit Each “block” telegram carries a toggle bit which has to be inverted for each new telegram.
Check size of downloaded data
At the end of the block download, the server checks if the expected data size is equal to the received data size. If not, an error response is generated.
Create “Error” response Creates an error response which tells the client that the block download failed.
Tab. 92 SOD Block Download Access server state description 2609
n Max. count of retries 0 UNSIGNED8 Object index 1202h sub index 2h
(see 5.6.4.14)
Timeout of SNMT Response [CT]
1 UNSIGNED32 Object index 1202h sub index 1h
(see 5.6.4.14)
Tab. 93 SNMT master item description 2615
Description: 2616
The master sends an SNMT Request telegram to the slave. If a response is received or a response is 2617
not required, the client can continue (more SNMT telegrams, etc). If the response is timed out, the 2618
client retries to send the telegram n times. The number of retries as well as the timeout time for an 2619
SNMT Response telegram is to be set within the SOD of the client. 2620
2621
State Description
Send SNMT Request Sending the SNMT telegram to the slave
Wait for SNMT Response Waiting for the response from the server
SNMT Request Error Handling If the maximum number of retries was not reached the telegram will be sent again otherwise a communication error occurs.
Write diagnose data to SOD The diagnose data has to be available for the user. This is made through the SOD of the master.
Tab. 94 SNMT master state description 2622
Send SNMT
Request
Wait for SNMT Response
SNMT Request
Error Handling SNMT Response timeout
n retries not exceeded
SNMT Response
received
n retries exceeded
Write diagnose data to SOD
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 153/191
5.7.5.2 SNMT Slave 2623
IDLE
Process SNMT
Request
[no response required][response required]
/ send SNMT response
SNMT Request
received
2624
Fig. 66. State diagram “SNMT Slave” 2625
Description: 2626
The slave receives an SNMT request telegram from the master. The telegram is processed according 2627
to the ID field. During processing, an SNMT Response may be generated and sent back to the master. 2628
2629
State Description
IDLE Wait for SNMT Request telegrams
Process SNMT Request Process the telegram according to the SNMT Request. Generate SNMT Response.
Tab. 95 SNMT slave state description 2630
2631
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 154/191
5.7.6 SN Power Up 2632
2633
Fig. 67. State diagram “SN Power Up” 2634
Description: 2635
At power up, the SN starts the self initialization. An SN can contain a flash memory where all data is 2636
stored. This data is loaded during the self initialization. After which, the SN enters the Pre-Operational 2637
state. In this state the SN can get parameters from the SCM. The SN also sends cyclic messages to 2638
the SCM to inform the SCM about its status. When the SN switches from Pre-Operational to 2639
OPERATIONAL, it stores all parameters within the flash memory (optional). 2640
2641
State Description
Initialization Loading parameters from flash (optional)
Pre-Operational
Receiving parameters from SCM. UDID verification, etc. In this state all application data are set to the safe state (default of the object, see chapter 5.6.2).
Operational Sending and receiving SPDOs, time requests, etc
To keep the SN in operational it needs to receive a cyclic signal from the SCM. If the signal is timed out (timeout to be set within the SOD) the SN switches to Pre-Operational.
Tab. 96 SN power up state description 2642
5.7.6.1 States and Communication Object Relation 2643
The following table shows the relation between operational states and communication objects. 2644
Services on the listed communication objects may only be executed if the device is in the appropriate 2645
operational state. 2646
Initialization Pre-Operational Operational
SPDO X
SSDO X X
SNMT X X
Tab. 97 State and communication object relation 2647
Initialization
Pre-Operational
/ store parameters to flash (optional)
Operational
Life guarding timeout OR SNMT_SN_set_to_PRE_OP received
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 155/191
5.7.6.2 Pre-Operational 2648
Pre-Operational
Wait for SADR
Check Parameter
Checksum and
Timestamp
[parameter checksum
and timestamp OK]
[parameter checksum and
timestamp not OK] / send
SNMT_SN_FAIL,
Error Group = Parameter,
Error Code = 0
Wait for
SNMT_SN_set_to_OP
Check other requirements
for operational state
[SNMT_Assign_SADR
received]
SNMT_SN_set_to_OP
received
[requirement not met] /
send SNMT_SN_FAIL,
Error Group = requirement
group,
Error Code = requirement
error code
[requirement met] / send
SNMT_SN_status_OP
Idle
[Main SADR
assigned] [Main SADR not
assigned]
[refresh time not
expired]
[(number of
Retries >=
max number
of retries) and
(max number
of retries !=
255)]
/number of retries = 0
[refresh time expired]
[(number of retries < max number of retries) or
(max number of retries == 255)]
/ send SNMT_SN_reset_guarding_SCM,
number of retries ++
Check Additional
Parameter
[parameter set not OK] / send
SNMT_SN_FAIL,
Error Group = Add. Parameter,
Error Code = Nr. Of Set & 0xF0
[add parameter OK]
2649
Fig. 68. State diagram “SN Pre-Operational” 2650
2651
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 156/191
Item Description Min Value Max value SOD
Refresh time
Refresh time of SNMT_SN_reset_guarding_SCM signal [μs]
1 UNSIGNED32 Object index 100Dh
(see 5.6.4.6)
Max number
of retries
Maximum number of retries for the SNMT_SN_reset_guarding_SCM service
- UNSIGNED 8 Object index 100Eh
(see 5.6.4.7)
Tab. 98 SN Pre-Operational state item description 2652
2653
Description: 2654
When the SN enters the pre-operational state, the SNMT and SOD Access Rx services are started. In 2655
this state all application data are set to the safe state. The SNMT services are required for e.g. 2656
receiving UDID request telegrams. With SOD Access Commands, the SN can get new parameters 2657
from the SCM. Before being able to switch to operational, the SN at least has to receive its “Main 2658
SADR” and the “UDID of the SCM”. 2659
2660
State Description
Idle Receiving parameters from SCM. UDID verification. Etc.
Wait for SADR The SN waits to get its Main SADR from the SCM
Wait for SNMT_SN_set_to_OP The SN waits to be switched to Operating from the SCM.
Check Parameter Checksum and Timestamp
Checks if the parameter checksum as well as the parameter timestamp match the local settings. In case the checksum calculation takes a long time, the SN may reply to the SCM using the service SNMT_SN_busy. The SCM then has to send the service SNMT_SN_set_to_OP again.
Check Additonal Parameters Checks if the SN is needing additional parameters. If this is the case, an SN will respond to the SCM with an SNMT_SN_Fail and a corresponding error code. In case the check takes a long time, the SN may reply to the SCM using the service SNMT_SN_busy. The SCM then has to send the service SNMT_SN_set_to_OP again.
Check other requirements for Operational state
There might be several reasons for not being able to switch to operational state. Within this state the module firmware is requested if switching to operational is allowed, if not the reason is reported to the SCM.
Tab. 99 SN Pre-Operational state description 2661
2662
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 157/191
5.7.6.3 Additional Parameters 2663
2664
During configuration, an SN is able to request additional parameter sets. Theses sets may then be 2665
transferred to the SN using a similar method thant the normal parameter download. 2666
2667
Check Additional Parameters
Parameters Are Verified
Are additional Parameters
needed?
[SNMT_SN_set_to_OP received]
Going operational
[No
Ad
ditio
na
l P
ara
me
ters
ne
ed
ed]
Check Timestamp & CRC
Send SN_FAIL
No
Request Header for
Parameter Set X
Request full parameter
set
[Full parameter set is valid]
[Timestamp & CRC are valid]
2668
Fig. 69. State diagram “Check Additional Parameters” 2669
Description: 2670
After the SCM and the SN have successfully verified the default parameter of the SN, the SCM will tell 2671
the SN to switch to operational using the signal SNMT_SN_set_to_OP. 2672
The SN is obligated to check, if he will need one or more additional parameter sets to allow switchitng 2673
to operational. If additional parameter sets are needed, the SN will respond to the command for going 2674
operational by sending an SN_FAIL with an error group regarding additional parameters, and the 2675
number of the expected parameter set as error code. The SCM will look up the corresponding set in 2676
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 158/191
the SOD entry 0xE4XX, where XX corresponds to the entry in 0xC4XX for the SN. If the SCM has no 2677
entry, it will again ask the SN to switch to operational. 2678
If the SN receives a switch to operational, after he has requested an additional parameter set, but 2679
before he actually received such a set as download on 0x101A,he assumes a configuration error on 2680
the side of the SCM and will not switch to operational. 2681
If the SCM can find a corresponding parameter set in its 0xE4XX object structure, he will send the set 2682
header, as it is described in 5.6.4.10.1, using the algorithms described in 5.6.4.10. The SN is 2683
responsible to check if the sent header is complete if the timestamp and CRC matches the stored 2684
timestamp and CRC on the device. The SCM’s sole responsibility lies in the correct transmission using 2685
0x101A. If the timestamp or CRC differs, the SN will again respond by sending an SN_FAIL, this time 2686
asking for the complete set, which the SCM shall provide. 2687
If further additional parameter sets are required by the SN, the process can be repeated as often as 2688
required up to a maximum of 16 parameter sets. 2689
2690
2691
State Description
Parameters are Verified Standard parameters stored on the device are verified and the checksum is calculated
Are additional Parameters needed?
If the device has received an indication or operates under the assumption, that additional parameters are needed, the information must be processed solely on the device itself.
Request Header for Parameter set x
Request the header information for the provided parameter set, as stated in the error code
Check timestamp and crc Check the timestamp and CRC. The CRC algorithm is not specified
Request full parameter set Request the full set, including again the set header
Tab. 100 Additional parameter download state description 2692
2693
5.7.6.4 Operational 2694
2695
Operational
/ reset guard time timer
IDLE
Life guard telegram received / reset guard time timer, send
SNMT_SN_status_OP
guard time timer elapsed
SNMT_SN_set_to_PRE_OP received
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 159/191
Fig. 70. State diagram “SN Operational” 2696
2697
Fig. 71. Life guarding telegram 2698
Item Description Min Value Max value SOD
guard time timer - - Object index 100Ch sub index 1h and 2h
(see 5.6.4.4)
Tab. 101 SN Operational state item description 2699
Description: 2700
When the SN enters the Operational state, Life Guarding is started. The SN needs to receive cyclic 2701
telegrams from the SCM to remain in Operational state. If this telegram is timed out, the SN falls back 2702
into Pre-Operational state. 2703
State Description
IDLE Wait for Life Guarding telegram
Tab. 102 SN Operational state description 2704
5.7.7 SN Power Down 2705
All safe outputs return to safe state ( 0V ). 2706
5.7.8 SN Recovery after Restart / Error 2707
If an error occurred or the SN was restarted, the SN enters the Pre-Operational state. In this state, the 2708
SN sends a cyclic message (with no response) to the SCM. The SCM now can check the SN again, 2709
verify all parameters, UDID, DVI and then set the SN to Operational again. 2710
Safety Node
life guarding
life guarding
life guarding
life guarding
Non safe communi-cation layer Life guard telegram received, reset timeout
Data corrupted, ignore
Life guard timer elapsed, enter Pre-Operational state
SN in Pre-Operational, ignore
Life guard telegram received, reset timeout
Life guard telegram
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 160/191
5.7.9 SCM Power Up 2711
2712
Fig. 72. State diagram “SCM Power Up” 2713
Description: 2714
After power-on, the SCM loads its parameters from a non-volatile memory. Then it switches to 2715
Operational. The Operational super-state is described later on. The SCM can be switched into the 2716
Stopped state using a SNMT service. In Stopped, the SCM does not manage any safety nodes. If 2717
safety nodes are being configured with an external tool, the SCM must be in state Stopped. 2718
State Description
Initialization The SCM loads its parameters from a non-volatile memory.
Operational In Operational state all safety nodes are configured and started.
Stopped The SCM waits for the signal to switch back to Operational.
Tab. 103 SCM power up state description 2719
5.7.9.1 States and Communication Object Relation 2720
The following table shows the relationship between operational states and communication objects. 2721
Services on the listed communication objects may only be executed if the device is in the appropriate 2722
operational state. 2723
2724
Initialization Stopped Operational
SSDO X X
Tab. 104 State and communication object relation 2725
Initialization
Operational Stopped
SNMT_SCM_set_to_STOP received
SNMT_SCM_set_to_OP received
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 161/191
5.7.9.2 Operational 2726
2727
Operational
Safety Address
Verification
[module status ==
valid]
[module status ==
wrong SADR] OR
[module status ==
missing]
OR
([module status ==
UDID mismatch] AND
[configuration mode ==
MCM])
[module status == UDID
mismatch] AND
[configuration mode == ACM]
Verify DVIWait for Operator
Acknowledge
Handle Single UDID
mismatch[timeout]
[timeout] [failed]
[success]
Verify Parameters
[timeout] [failed]
[success]
Activate SN
[failed]
[success]
[timeout] [success]
IDLE 2
Node guarding timeout
elapsed
IDLE
Wait for response
[node guarding
timeout not
elapsed]
[node guarding timeout
elapsed] / send
SNMT_SCM_guard_SN
[SNMT_SN_status_OP
received]
[timeout OR
SNMT_SN_status_PRE_OP
received]
IDLE 3
[SNMT_SN_reset_guarding_SCM
received] / remaining time until
next guarding = zero
[SNMT_SN_ACK
sent]
2728
Fig. 73. State diagram “SCM Operational” 2729
The above state chart is performed for each SN in parallel. 2730
Item Description Min Value Max value SOD
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 162/191
Guarding Timeout
1 UNSIGNED32 Object index 100Ch sub index 1h
(see 5.6.4.4)
Tab. 105 SCM operational state item description 2731
2732
Description: 2733
When the SCM switches to Operational, it starts the UDID/SADR verification of all configured nodes. If 2734
an UDID mismatch was detected this is handled separately. The parameters for all valid nodes will be 2735
verified against the list of CRCs and Timestamps within the SOD (Object 0xC400-0xC7FE). If a node 2736
is valid (correct UDID, SADR and DVI) and its parameters are also valid, it will be set to operational. 2737
Operational nodes get a cyclic message to keep them in Operational state. 2738
2739
State Description
Safety Address Verification The SCM verifies the UDID of the node. Also the correct SADR will be assigned to the node.
Verify DVI The DVI has to be checked to ensure that the new node meets the technical requirements.
Verify Parameters Parameter check and eventually re-parameterization of the SN.
Activate SN After successful parameterization, the SCM switches the SN to Operational.
IDLE Waits until next SNMT_SCM_guard _SN needs to be sent.
Wait for response Waits for the response of the SNMT_SCM_guard_SN service.
Wait for Operator Acknowledge
If an unknown UDID was detected during start-up or operation, an operator-acknowledge is needed to accept and verify the new node. This state is only entered in Automatic Configuration Mode (ACM).
Handle Single UDID Mismatch If a new SN was detected (replacement, commissioning, etc) it is verified and checked to see if it meets the requirements or not.
IDLE 2 If the node is not present, or does not meet the technical requirements (module was replaced with a wrong type), the node will not be handled for a node guarding interval. This ensures, that nodes, which are not present or nodes which were replaced with a different module type will get handled again, but do not produce too much bus activity.
IDLE 3 Sets the remaining time until the next node guarding to zero in case a SNMT_SN_reset_guarding_SCM telegram is received. After a power up of a module, the module sends this type of telegram to the SCM. This ensures, that the SCM recognizes (by the response to the guarding telegram) that the module is down and needs to be restarted.
Tab. 106 SCM operational state description 2740
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 163/191
5.7.10 Safety Address Verification 2741
SNMT_Assign_SADR
Wait for
SNMT_SADR_Assigned
/ set module status to
„missing“
Correct SADR
/ set module status to
„valid“
[SNMT_SADR_Assigned
OK]
Wrong SADR
[expected UDID and
wrong SADR]
SNMT_Request_UDID
[timeout]
Wait for
SNMT_Response_UDID
UDID Mismatch
SN Missing
[timeout]
[unexpected UDID
received]
[expected UDID
received]
/ set module status to
„UDID mismatch“
/ set module status to
„missing“
/ set module status to
„wrong SADR“
Assign UDID of SCM
[timeout or failed]
2742
Fig. 74. State diagram “SCM Safety Address Verification” 2743
2744
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 164/191
Item SOD
module status
Object index C400h – C7FEh sub index 5h
(see 5.6.4.20)
expected UDID Object index CC01h – CFFFh (corresponding to assigned SADR) -> sub index 1 – 254d
The Safety Address Verification is used to verify the correctness of the safety network. All module 2747
changes are detected due to the uniqueness of the UDID. The object indeces CC01h-CFFFh 2748
correspond to the possible safety addresses 1d – 1023d. 2749
This State Machine is independent from the chosen configuration mode (ACM or MCM). 2750
2751
State Description
SNMT_Assign_SADR Assigns the SADR to a configured node.
wait for SNMT_SADR_Assigned
The response contains the actual SADR. Some nodes might not be able to change the SADR because it is to be set using hardware switches.
SNMT_Request_UDID Requests the UDID of a configured node.
wait for SNMT_Response_UDID
The response from the node contains its UDID.
Correct SADR The SADR could be assigned. The node is valid.
Wrong SADR The UDID is known but the SADR could not be assigned. The node is invalid.
UDID Mismatch The node does not have the expected UDID. An operator-acknowledge is needed to accept and start the node.
SN missing The configured SN could not be reached. The node might be defective or not in the network. The node is missing.
Assign UDID of SCM Send UDID of SCM to sn via the corresponding service.
Tab. 108 Safety address verification state description 2752
5.7.11 Commissioning Mode 2753
There is no special commissioning mode. The first time the SCM is started, all nodes are handled as 2754
nodes with a UDID mismatch. 2755
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 165/191
5.7.12 Handle Single UDID Mismatch 2756
Handle Single UDID Mismatch
Write 0 to UDID List in SOD
SNMT_Assign_SADR
Verify DVI
Verify Parameters
Verify uniqueness of UDID
Store memorized UDID on
SCM
OK / memorize
returned UDID
OK
OK
OK
/ handle single
UDID
mismatch =
success
SN missing Wrong or defect SN
False / set
module status to
„wrong SADR“
False / set
module status to
„invalid“
False / set
module status to
„invalid“
False / set
module status to
„wrong
parameters“
timeout
timeout
timeout
/ handle single
UDID
mismatch =
failed
/ handle single UDID
mismatch = timeout,
set module status to
missing
2757
Fig. 75. State diagram “SCM Handle Single UDID Mismatch” 2758
Description: 2759
Handles all nodes which have UDID mismatch. If the new node meets the requirements (DVI, 2760
assignment of SADR, etc) no re-configuration of the SCM is needed when replacing nodes. 2761
2762
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 166/191
2763
State Description
Write 0 to UDID list in SOD
The SCM deletes the “old” stored UDID in the SOD (Object 0xCC01-0xCFFF). 0 is no valid UDID.
SNMT_Assign_SADR The SCM writes the configured SADR to the module.
Verify DVI The DVI has to be checked to ensure that the new node meets the technical requirements.
Verify Parameters The parameters which are stored on the node are cross checked with the parameters stored on the SCM. The node will get new parameters if necessary/possible.
Verify uniqueness of the UDID
The responded UDID is checked against the UDID list within the SOD (Object 0xC001-0xCFFF)
Store UDID on SCM The new UDID is stored on the SCM to be able to recognize the node at the next start-up.
SN missing The SN did not answer one or more telegrams from the SCM. Therefore the SN will be handled like a missing node.
Wrong or defect SN The node does not meet the technical requirements specified in the SCM.
possible reasons are:
The DVI does not meet the requirements
It is not possible to change the SADR of the device (this can happen if the SADR is to be set with hardware switches)
The parameters stored on the node are not equal to the parameters stored on the SCM but a download is not possible (this can happen if the SCM does not hold the parameters for a node and only knows the required checksum)
The UDID is not unique within the SDN (this normally should never happen because the UDID is designed to be globally unique)
Tab. 109 Handle UDID mismatch state description 2764
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 167/191
5.7.13 Verify Parameters 2765
Check Parameter Checksum
and Parameter Timestamp
Send
SNMT_SN_set_to_PRE_OP
[yes]
[timeout] / set module
status to „missing“Wait for
SNMT_SN_in_PRE_OP
Check if parameters are
available
[OK]
[ not OK]
[OK]
Download SOD
Module is invalid
/ set module status to
„wrong parameters“
[no]
Assign Additional SADR
[timeout] / set module
status to „missing“
[timeout] / set module
status to „missing“
[OK]
[OK]
[Failed]
[not OK]
2766
Fig. 76. State diagram “SCM Verify Parameters” 2767
2768
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 168/191
2769
Description: 2770
The parameters (SOD) stored on the SN are compared with the parameters stored on the SCM. 2771
Attention: It is not absolutely necessary to store all parameters for all nodes on the SCM. It is also 2772
possible to only store the required parameter checksum on the SCM. In this case, the SCM can verify 2773
the correctness of the parameters on the node. If the parameters are not correct the SCM will NOT be 2774
able to re-configure such nodes. 2775
State Description
Check Parameter Checksum and Parameter Timestamp
The SCM checks if the current parameters for the node are the same which are stored on the SCM.
Send SNMT_SN_set_to_PRE_OP
Resets the SN.
wait for SNMT_SN_in_PRE_OP
Waits for the reply of the reset service.
Check if parameters are available
If the checksum on the node is different from the checksum on the SCM, the SCM checks if parameters for re-configuration of the node are available.
Download SOD The SCM re-configures the node.
Module is invalid If the parameters on the node are not equal to the parameters stored on the SCM and re-configuration of the module is not possible, the module is invalid and may not be set to Operational.
Assign additional SADRs The SCM assigns the SADR for the optional TxSPDOs 2-1023 of the corresponding SN.
Tab. 110 Parameter verification state description 2776
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 169/191
5.7.14 Handle SN Version 2777
Ask for 0x1018 version entry
SCM operates with same
version
SCM will use own version
[Version received]
[Re
ce
ive
d S
SD
O A
bo
rt]
[OK]
Assume SN uses Version 1.3SCM marks SN as
„incompatible version“
[Not OK]
Module will not be set to
operational
2778
Fig. 77. State diagram “Handle SN version” 2779
Description: 2780
The version for each SN is stored in its device vendor information object 0x1018 (see 5.6.4.8). During 2781
power-up, the SCM will verify the version of the node. If the version responds with the correct version, 2782
or a version the SCM is compatible with, the SCM will use the provided version as the version of the 2783
SN. If the SCM is not compatible with such a version, he must stop the boot-up of the device, and 2784
recycle the boot-up sequence for this device. In any other case, the SCM will use version 1.3 as 2785
default and will disable any features introduced beyond that version. 2786
2787
If the version provided by the module is incompatible with the operating SCM, the SCM will set the 2788
module state to “incompatible version” and the SN will not be set to operational. 2789
2790
The SN must allways assume that the SCM will be using the version provided by the SN. 2791
2792
2793
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 170/191
2794
State Description
Ask for 0x1018 version entry
The SOD entry for the openSAFETY stack version is retrieved from the module
SCM operates with same version
SCM uses the same version as provided by the SN
Assume SN uses version 1.3
SCM will operate under the assumption, that the SN is using version 1.3
SCM marks SN as “incompatible version”
SCM will set the module state “incompatible version” and the SN will not be set to operational
SCM will use own version SCM will operate under the assumption, that his version is the same as the version of the SN.
Tab. 111 Version verification state description 2795
2796
2797
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 171/191
5.7.15 Activate SN 2798
Activate SN
Wait for response
[SNMT_status_OP
received] / „Activate
SN“ = success
[SNMT_SN_FAIL
received]
Report to application
timeout / „Activate SN“
= timeout
Insert Error Group and
Error Code Information into
SNMT_SN_ACK
Wait for application
Acknowledge
/ send SNMT_SN_ACK
Send
SNMT_SN_put_to_OP
[SNMT_SN_calc_CRC
received]
2799
2800
Fig. 78. State diagram “Activate SN“ 2801
Description : 2802
The SCM tries to set the SN to Operational. The SN ether ca switch to Operational or there is an error 2803
occurring during switching to Operational. This error is reported with the SNMT_SN_FAIL telegram. 2804
The SCM receives this telegram and reports it to the application. The vendor specific application has 2805
to decide how to cope with the situation. It can send an acknowledgement telegram SNMT_SN_ACK if 2806
the error can get acknowledged, or keep the SN in Pre-Operational if the problem cannot be solved. 2807
2808
State Description
Wait for response The SCM waits for the response from the SN
Report to application In case of an error the error is reported to the application
Wait for application Acknowledge
The application may set the error group and the error code information for the acknowledgement of the error.
Tab. 112 SN activation state description. 2809
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 172/191
5.7.16 Module Exchange 2810
Exchanged modules will send the SNMT_SN_in_PRE_OP message to the SCM. The SCM will handle 2811
those exchanged nodes as UDID-mismatch nodes. After operator acknowledge, they will be 2812
programmed and set to OPERATIONAL. 2813
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 173/191
6 Parameterization Interface of SOD 2814
The parameterization of any openSAFETY devices has to be done using a software tool which was 2815
developed and certified according to IEC 61508. Such a software tool always has to be part of a 2816
complete safety related automation system. 2817
2818
The software tool will transfer a valid SOD configuration to the openSAFETY device by defined 2819
openSAFETY services. Direct vendor specific access to the device is not supported. 2820
6.1 Configuration of an SD 2821
A single openSAFETY safety domain is configured by defining the SOD for an SCM. A software tool 2822
will create a valid SOD configuration for such an SCM, containing every parameter and setting for 2823
each participant of this SD. This configuration must be provided to the SCM in a secure way and prior 2824
to the power-up of the network. 2825
2826
During the power-up, the SCM will query each individual SN within the SD and guarantees, that the 2827
correct and valid configuration is being stored on each individual device. 2828
2829
The SCM will hold a parameter set for each SN within the SD. The parameter set contains 2830
2831
Communication and timing parameters 2832
SPDO communication parameters 2833
SPDO mapping information 2834
Device specific parameters 2835
Channel mapping configuration 2836
2837
Additionally the timestamp and the checksum of the parameter configuration will be transmitted during 2838
power-up, enabling each device individually to verify, if the transmitted parameter set is valid. 2839
2840
If the device supports additional parameter sets, these have to be stored on the SCM before power-up 2841
as well, and will be transported using openSAFETY services, as they are needed by the SN. 2842
2843
Only if all parameters are verified, and every device within a SD has verified, that it’s configuration is 2844
valid and transferred successfully, the SD is fully configured and may enter the operational phase. 2845
2846
Parameters which where left at their default state, can be omitted from the configuration send to the 2847
SN, and the SN must assume the default value is used for such entries. 2848
6.2 Parameter check mechanism 2849
The parameters within the SOD are secured by calculcating a CRC checksum for the SOD entries. 2850
For each 4k bit block of SOD data, a 32bit checksum will be calculated and is stored in the DVI object 2851
entry of the SOD, see 5.6.4.8. 2852
2853
An SCM may either upload only the parameter timestamp from an SN or the timestamp together with 2854
the stored CRCs, and depending on this information decide, if a reconfiguration of the SN is necessary 2855
or not. 2856
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 174/191
7 openSAFETY Conformance 2857
The Conformance test is one part of the safety life cycle model for an openSAFETY device. Each 2858
node which is within an interoperable openSAFETY communication network has to provide 2859
compatibility according to this document. Only the compatibility of devices guarantees the availability 2860
and safety of openSAFETY networks. 2861
7.1 openSAFETY Change Management 2862
2863
Working group
openSAFETY
Specification
Notified Body
Approval
Lock on
Specification by
EPSG
Task group for
modification
Development of
Assessment
specification
Lock on
Specification by
EPSG
Task group for
modification
Notified Body
Approval
changes if necssary
2864
Fig. 79. Change Management Flow of Specification 2865
Change management is a very important point in the openSAFETY life cycle model. Each change 2866
within the specification must be validated and verified by a notified body (e.g. TUV). The EPSG must 2867
manage all further steps for certification. If the content of openSAFETY specification is modified, it 2868
must be checked to see what kind of modification is necessary for the test specification. In each case, 2869
the test specification is a derived from the openSAFETY Specification. Test specification and the test-2870
tools must also be approved by a notified body. 2871
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 175/191
7.2 Certification flow for openSAFETY devices 2872
Conformance test flow for EPLsafety devices
Certfification for
underlying Fieldbus
openSAFETY
Conformance test
openSAFETY
Conformance
Approval
Approval of Functional
Safety by Notified
Body
2873
Fig. 80. Certification flow of openSAFETY devices – e.g. on POWERLINK 2874
Network protocol Certification 2875
For openSAFETY certification, the underlying communication layer for all non safe communications is 2876
required. For successful interactions between different safety nodes, all mandatory network services 2877
must be implemented conforming to the relevant standard. 2878
2879
openSAFETY Conformance test 2880
The openSAFETY Conformance-test must ensure that an openSAFETY device conforms to all safety 2881
services and measurements according to the openSAFETY Profile Specification. The test should be 2882
done by an independent body or by a certified test tool. The result must be a certificate and a detailed 2883
test report which is needed for obtaining the Functional Safety Certification of a notified body. 2884
2885
Approval of Functional Safety by Notified Body 2886
If machinery needs official approval (e.g. for IEC 61508 or other safety related standards), all 2887
openSAFETY devices being used need this approval too. According to the Standards, Functional 2888
Safety has to be certified by a notified body. 2889
2890
After all three certifications, the devices can be marked with the openSAFETY Logo. 2891
2892
Fig. 81. openSAFETY Logo 2893
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 176/191
8 Safety Requirement Specification 2894
8.1 CRC error detection capabilities 2895
openSAFETY uses the following CRC polynomials as additional measure to protect information 2896
against data corruption. According [3] respectively [6] all these CRC polynomials are well known and 2897
guarantee the following error detection capabilities: 2898
2899
CRC Polynomial
Koopmann notation
error detection capabilities
number of bits (CRC not included)
Properness Used for
12Fhex 0x97 [3]
HD 4 up to 119 bits Yes up to 119 bits [7]
Frames up to 8 byte payload data (up to 104 bits data area)
15935hex 0xAC9A [3]
HD 5 up to 241 bits HD 2 up to 2048 bits
- Frames for SLIM SSDO Services only, from 9 up to 240 byte payload data (up to 1960 bits data area)
1755Bhex 0xBAAD [3]
HD 4 up to 2048 bits Yes up to 2048 bits [7]
Frames except SLIM SSDO Services, from 9 up to 240 byte payload data (up to 1960 bits data area)
11EDC6F41hex 0x8F6E37A0 [6]
HD 8 up to 128 bits HD 6 up to 4K bits HD 4 up to 64K bits
- Parameter data up to 4K bits per block
Tab. 113 CRC Polynomials and characteristic 2900
8.2 Failure detection for parameterization services 2901
The safety layer provides a block CRC to detect systematic and stochastic corruption of parameter 2902
and configuration data. All principles are according to international standards [2]. The chosen measure 2903
(CRC 11EDC6F41hex) guaranties an error detection capability for parameter and configuration data of 2904
at least HD 6 and is therefore a proper measure against stochastic errors during transmission of data. 2905
2906
To detect systematic failures, parameter and configuration data are secured with a timestamp and will 2907
be checked against predefined values by the SCM. 2908
8.3 Failure detection for data transfer services 2909
The safety layer contains measures for detection of systematic and stochastic errors. All principles are 2910
according to international standards [1], [2]. The mathematical background for the calculation of the 2911
stochastic residual error probability is shown in detail in the following chapters. 2912
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 177/191
8.3.1 Systematic failures 2913
The safety related data frame contains a 2-byte-information of the real time (time stamp). In addition to 2914
the address-information and the use of a watchdog, which detects any missing frames that occur 2915
during the reaction time, all systematic failures will be detected: 2916
By the combined use of the timing information (time stamp) and the internal watchdog, a loss and an 2917
insertion of data will be also detected because only one message will be accepted within a certain 2918
time frame. If no valid information appears during a time frame, a loss of data is assumed. 2919
2920
The following table gives an overview for the failures and the measures used: 2921
Consecutive
Num
ber
Tim
e M
ark
Tim
e E
xpecta
tio
n
Echo
Identifier
Data
Pro
tection
Redu
nda
ncy w
ith
Cro
ss C
heck
Diffe
rent
measure
s
for
sta
nd
ard
and
safe
fra
mes
Repetition X
Loss X
Insertion X
Incorrect Sequence X
Delay X X
Incorrect Data X X
Coupling of standard and safe frames X
Tab. 114 openSAFETY failure measures 2922
The table shows the measures which have been chosen by openSAFETY. The specific function of the 2923
time stamp combined with a watchdog also allows detecting a loss and an insertion of data. 2924
8.3.2 Stochastic errors 2925
To verify the correctness of data and to enable the receiving device to identify any stochastic error, the 2926
following principles will be used: 2927
2928
CRC-calculation 2929
Comparison of data-information of both sub frames 2930
Checking of time stamp 2931
Checking of received address (comparison with internal address or address in look-up-table) 2932
2933
The checking of time stamp has already been described. 2934
2935
The safety frame consists of 2 sub frames. Each sub frame contains a CRC, which will detect all 2936
possible errors up to the given Hamming Distance. The payload data and the address information 2937
from sub frame 1 are repeated in sub frame 2. The signatures of CRC1 and CRC2 are different even if 2938
the polynomials for determining CRC1 and CRC2 are identical, because the residual is calculated with 2939
a different number of bytes from both sub frames. The polynomial guarantees a Hamming Distance of 2940
at least 4 for both sub frames. 2941
2942
The following figure and table shows the structure of the entire safety frame and gives an overview of 2943
the Frame elements and the applied measures against stochastic errors 2944
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 178/191
2945
Fig. 82. Structure of POWERLINK safety frame 2946
2947
Field Length [bit]
Checked
by
CR
C
Duplic
ate
d
Expectation
Comment
ADR 10 yes yes
ID 2 yes yes Corruption of identifier but the resulting identifier is still an SPDO identifier, these errors are not detected
ID 4 yes yes yes Corruption of identifier but the resulting identifier is no longer an SPDO identifier, these errors are detected
LE 8 yes yes Corruption of the Length Field will cause the consumer to interpret wrong data as a CRC, the start address of the second sub frame will be wrong, …
CT(L) 8 yes
CT(M) 8 yes yes Corruption of the major counter will cause the consumer to detect a time synchronization problem
TADR 10 yes yes Corruption of the Time Address will cause the consumer to detect a time synchronization problem
TR 6 yes yes Corruption of the Time Identifier will cause the consumer to detect a time synchronization problem
CRC 8 / 16
DB (0 – 240) * 8 yes yes
DB + 16 Sum of duplicated bits
12 Sum of bits with data expectation within sub frame 1
28 Sum of bits with data expectation within sub frame 2
Tab. 115 Overview of Frame elements and applied measures against stochastic errors 2948
8.3.2.1 Calculation of residual error probability 2949
For the calculation of the residual error probability of openSAFETY, the following symbols are used: 2950
2951
symbol Description
BER bit error rate of the communication channel
Nx Length of sub frame N1 … length of sub frame 1 N2 … length of sub frame 2
D Number of duplicated bits
R Length of the used CRC-polynomial
C number of bits of the payload data
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 179/191
Mx Number of bits with expectation
M1 … number of bits within sub frame 1 M2 … number of bits within sub frame 2
d Hamming distance
Tab. 116 Residual error probability calculation, symbols and terms 2952
2953
The calculation of the residual error probability of openSAFETY is now shown step by step: 2954
2955
(a) According [1], the probability of “e” corrupted bits within a sub frame is: 2956
)1()1(1
)(1 eNe BERBERe
NeR
)2()1(2
)(2 eNe BERBERe
NeR
2957
e number of corrupted bits 2958
Equation 2. Binomial distribution, probability for “e” corrupted bits within a sub frame 2959
2960
(b) According [7], the probability of “e” corrupted bits with “i” corruptions within the duplicated bits is 2961
given by the hyper-geometric distribution: 2962
e
N
ie
DN
i
D
ieBa1
1
),(1
e
N
ie
DN
i
D
ieBa2
2
),(2
2963
e number of corrupted bits 2964 i number of corrupted bits within duplicated bits 2965
Equation 3. Hyper-geometric distribution 2966
2967
(c) According [7], the probability of identical corrupted bits within sub frame 1 and sub frame 2 is: 2968
1
)(
i
DiBb
2969
i number of corrupted bits within duplicated bits 2970
Equation 4. Reduction of residual error probability by duplication of data 2971
2972
(d) According [7], all used CRC polynomials are known as proper polynomials. Since them, an 2973
additional reduction of the residual error probability is defined as: 2974
)1(2)( ReBc for Koopman 0x97 if e is even 2975
0)( eBc for Koopman 0x97 if e is odd 2976
ReBc 2)( for Koopman 0xBAAD 2977
e number of corrupted bits 2978
Equation 5. Reduction of residual error probability by proper polynomials 2979
2980
(e) According [7], the reduction of the residual error probability by the data expectation is: 2981
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 180/191
e
MN
e
R
e
N
e
MN
eBd11
11
11
)(1
e
MN
e
R
e
N
e
MN
eBd22
12
22
)(2
2982
e number of corrupted bits 2983
Equation 6. Reduction of residual error probability by data expectation 2984
2985
According [7], finally the residual error probability of the whole frame is calculated by: 2986
)()2(2)2(),2(2)2(2)1(1)1(),1(1)1(16
),max(2
6
1
6
),max(1
iBbeBdeBcieBaeReBdeBcieBaeRRsd
die
d
i
d
die
2987
2988
i number of corrupted bits within duplicated bits 2989 e1 number of corrupted bits in sub frame 1 2990 e2 number of corrupted bits in sub frame 2 2991
Equation 7. Final residual error probability of openSAFETY 2992
2993
The maximum rate [mr] of safety related messages per second within a safety application is limited by 2994
the limit of the residual error probability for SIL 3 of 10-9
per hour [1]. 2995
3600
10]/1[
9
sRsmr
2996
Equation 8. Maximum message Rate per second to claim SIL 3 2997
8.3.2.2 Assumed bit error rate 2998
In accordance to [1], a bit error rate of 0.01 must be assumed if no further information about the quality 2999
of the transport layer is known. 3000
3001
For Ethernet based transport layer it is known, that a data paket has a minimum size of 64 Bytes (512 3002
Bits). A bit error rate of 0.01 means that every 1 Bit out of 100 Bits is corrupted. In case of an Ethernet 3003
based transport layer every paket is corrupted. So a base communication setup with this bit error rate 3004
wouldn’t be possible or in other words, a working Ethenernet based transport layer garants a bit error 3005
rate of 0.001 or higher. 3006
3007
For openSAFETY it is also known, that a stable communication within an industrial application 3008
requires a bit error rate, which allows statistically at least one error-free frame per connection. If the bit 3009
error rate is higher, statistically every frame within a connection is corrupted and no useful 3010
communication can be established. 3011
3012
Finally the assumed bit error rate for an communication layer running openSAFETY is 3013
Transport layer specific if the quality of the transport layer is known 3014
OR 3015
0.001 if a cable based Ethernet communication layer is used 3016
OR 3017
1/Framelength in all other cases 3018
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 181/191
8.3.2.3 Residual error probability 3019
The following table show the residual error probability for openSAFETY and the maximum message 3020
rate per second to claim SIL 3. 3021
3022
Payload [Bytes] BER = 1/Framelength BER=0.001
Rs mrSIL3[1/s] Rs mrSIL3[1/s]
1 8,32E-15 33 2,61E-22 1,06E+09
2 7,49E-15 37 7,34E-22 3,79E+08
3 5,89E-15 47 1,56E-21 1,78E+08
4 4,37E-15 63 2,78E-21 9,97E+07
5 3,17E-15 87 4,45E-21 6,24E+07
6 2,29E-15 121 6,57E-21 4,23E+07
7 1,65E-15 167 9,14E-21 3,04E+07
8 1,21E-15 230 1,22E-20 2,28E+07
9 9,34E-21 2,97E+07 2,65E-25 1,05E+12
10 6,96E-21 3,99E+07 3,21E-25 8,65E+11
11 5,24E-21 5,30E+07 3,83E-25 7,26E+11
12 3,98E-21 6,97E+07 4,48E-25 6,19E+11
13 3,06E-21 9,07E+07 5,19E-25 5,36E+11
14 2,37E-21 1,17E+08 5,92E-25 4,69E+11
15 1,86E-21 1,49E+08 6,70E-25 4,14E+11
16 1,47E-21 1,89E+08 7,52E-25 3,70E+11
17 1,17E-21 2,38E+08 8,36E-25 3,32E+11
18 9,39E-22 2,96E+08 9,24E-25 3,01E+11
19 7,59E-22 3,66E+08 1,02E-24 2,74E+11
20 6,18E-22 4,49E+08 1,11E-24 2,50E+11
21 5,07E-22 5,48E+08 1,21E-24 2,30E+11
22 4,18E-22 6,65E+08 1,30E-24 2,13E+11
23 3,47E-22 8,01E+08 1,41E-24 1,97E+11
24 2,89E-22 9,60E+08 1,51E-24 1,84E+11
25 2,43E-22 1,14E+09 1,62E-24 1,72E+11
26 2,05E-22 1,36E+09 1,73E-24 1,61E+11
27 1,74E-22 1,60E+09 1,84E-24 1,51E+11
28 1,48E-22 1,88E+09 1,95E-24 1,43E+11
29 1,26E-22 2,20E+09 2,06E-24 1,35E+11
30 1,08E-22 2,56E+09 2,18E-24 1,27E+11
31 9,34E-23 2,97E+09 2,30E-24 1,21E+11
32 8,08E-23 3,44E+09 2,42E-24 1,15E+11
40 2,85E-23 9,75E+09 3,42E-24 8,12E+10
44 1,80E-23 1,54E+10 3,95E-24 7,04E+10
48 1,18E-23 2,34E+10 4,48E-24 6,20E+10
52 8,01E-24 3,47E+10 5,02E-24 5,53E+10
56 5,57E-24 4,99E+10 5,57E-24 4,99E+10
60 3,96E-24 7,02E+10 6,11E-24 4,55E+10
64 2,87E-24 9,67E+10 6,65E-24 4,18E+10
96 3,78E-25 7,35E+11 1,06E-23 2,63E+10
128 8,94E-26 3,11E+12 1,33E-23 2,10E+10
160 2,94E-26 9,44E+12 1,45E-23 1,92E+10
192 1,20E-26 2,32E+13 1,45E-23 1,92E+10
240 4,02E-27 6,91E+13 1,28E-23 2,17E+10
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 182/191
Tab. 117 residual error probability and the maximum message rate per second to claim SIL 3 3023
8.4 Summary 3024
The described structure of the openSAFETY frame contains all necessary algorithms in order to detect 3025
systematic failures. The chosen architecture of CRC-checks and repetition of the data area provide an 3026
excellent tool to detect any stochastic errors. 3027
The calculation for all data lengths has shown that the requirements for SIL 3 will be fulfilled. 3028
8.5 Safety requirements 3029
8.5.1 Data Transfer with SPDO, SSDO services 3030
In order to avoid systematic and stochastic errors the following requirements have to be fulfilled during 3031
development and implementation: 3032
All described functions for safety must be implemented using software on the internal controller from 3033
the provider (If hardware will be used, the hardware should be testable): 3034
Generation of time stamp 3035
Generation of CRC1 and CRC2 3036
Data duplication 3037
The consumer has to check the received data (made by software of the controllers): 3038
Notice: Any new message must contain a new time stamp. 3039
Check sub frame 1 with CRC1 3040
Check sub frame 2 with CRC2 3041
Compare the entire data area bit-for-bit 3042
Check the received address 3043
Reset the internal watchdog (counter) if a new valid message has been received 3044
If the watchdog (counter elapsed) has an overrun (not been reset within the maximum time), 3045
the device has to enter a safe state 3046
If a frame appears that has the same time stamp as the last one or an older one, ignore this 3047
frame 3048
8.5.2 Data Transfer using SLIM SSDO Services 3049
In order to transfer data between safety related devices by the use of SLIM SSDO Servcies, the 3050
following requirements for the transfer-sequence must be matched: 3051
A total transfer frame has to be divided into parts, which have a maximum data length of 4096 Bits 3052
Each part of a transfer block has to be checked with a CRC-32 (HD=6) 3053
By the use of these measures the total failure rate fits to the requirements of SIL 3 3054
8.6 Safety architecture 3055
The safety frame format and the safety related services of openSAFETY fit to the requirements of SIL 3056
3 (IEC 61508). Nevertheless openSAFETY can also be used for data transfer for all other SIL (SIL 1 to 3057
SIL 3). The hardware architecture for achieving the requirements of IEC 61508 can vary from a simple 3058
1-channel-structure (1oo1) to a complex 2- or 3-channel structure (1oo2, 2oo3). The most common 3059
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 183/191
hardware structure, which fulfills the requirements for SIL 3 is a 2-channel-structure, which uses 2 3060
microcontrollers (1oo2). 3061
3062
The principle of this structure is shown by the following figure: 3063
3064
Producer Consumer
Sensor: 1-
or 2-
channel
µC1µC2
interfacedata
data, addr,
crcbuffer
Shared buffer
ETH
interface
Total frame
second ETH
interface
µC1 µC2
interface interface interfacedata
data, addr,
crc
Shared buffer
buffer
Total frame
second ETH
interface
ETH
interface
option
actuator
option
EPL 3065
Fig. 83. System architecture for SIL 3 application (principle structure) 3066
In order to understand the figure quite well, the following example will be made: 3067
3068
A producer is used to interface a sensor. The data from the sensor will be transferred via the transport 3069
protocol to a producer and the consumer interfaces to an actuator. 3070
3071
If this very simple application has to accord to SIL 3, producer and consumer are built up with a 2-3072
channel-structure. On the producer’s side, the sensor can be a temperature-sensor or an encoder 3073
(only examples). It depends on the internal function of the data acquisition sensor, whether a 3074
redundant interface has to be used. In any case both microcontrollers (µC1 and µC2) will receive their 3075
data from the sensor independently. Between both controllers a cross-communication exists, which 3076
guarantees a comparison of input data and timing information. 3077
3078
If the comparison will agree to identical values from the sensor, both controllers produce their data 3079
frame (blue color). Then both controllers add an address- and a CRC-information, and attach these to 3080
the existing data frame (blue and green color). So two sub frames with identical pay load data have 3081
been produced. 3082
3083
The final total frame, consist of the 2 (identical) sub frames and the time stamp. In order to produce 3084
this total frames different methods exist: 3085
One microcontroller sends its sub frame to the other microcontroller. An internal buffer (orange color) 3086
connects both frames together and produces the final frame for transmission. 3087
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 184/191
Both microcontrollers transfer their sub frames to a “shared buffer” which is a part of the 3088
system’s firmware (orange color, dotted line). The shared buffer connects both sub frames 3089
and produces the total frame. 3090
There are 2 independent ETH interfaces which directly transfer the sub frames to the 3091
connected network (grey color). 3092
3093
The last solution is not recommended, because Ethernet will add a lot of overhead data to each frame. 3094
So the total frame length will increase in comparison to the first and second method. In addition to the 3095
shown principles of connecting both sub frames a lot of principles will exist. All these principles have 3096
the same feature: A redundant frame will be produced, which contains a lot of principles in order to 3097
detect systematic and stochastic failures. Even if the total frame will be cut into peaces or destroyed 3098
by some unknown mechanisms, most failures, which can happen, will be detected immediately. 3099
3100
The shown structure for producing a safety related total frame only reaches the requirement for safety 3101
in accordance to SIL 3, if on the other hand the consumer will receive the frame and checks whether 3102
both sub frames contain identical information and will not be destroyed or changed. 3103
3104
The consumer also uses two microcontrollers, which are supplied by different network-interfaces, a 3105
shared buffer or a buffer, which is located in one of the two controllers. The whole frame will be cut 3106
into two peaces and both controllers will get their specific sub frame. In order to check the right 3107
contents following procedures have to be done: 3108
3109
Both controllers have to calculate the CRC and compare the residual from this calculation with 3110
the CRC of the received sub frame. 3111
Each controller has to check the address field in order to clarify whether the source address is 3112
well known and the consumer really will get this information. 3113
The internal data has to be evaluated in order to identify a valid information (e.g. integer value, 3114
0.0.5 WDP 14.03.2005 F.Kaufleitner B&R Homework done by B&R inserted
EPLsafetyProfile-V-0-0-5.doc
0.0.6 WDP 15.03.2005 F.Kaufleitner B&R Due to some problems with MS Word, the document has been split in several files EPLsafetyProfile-V-0-0-6.doc
0.0.7 WDP 7.04.2005 F.Kaufleitner B&R Review of split document done, merged version, base document for Workgroup Review on 20.4.2005 in Lemgo
EPLsafetyProfile-V-0-0-7.doc
0.8 WDP 20.04.2005 F.Kaufleitner B&R Review due to EPLsafety Meeting on 20.4.2005 in Lemgo EPLsafetyProfile-V-0.8.doc
0.9 WDP 2.5.2005 F.Kaufleitner B&R Reviewed documents from Working group members merged, base document for Workgroup Review on 6.5.2005 in Hamburg EPLsafetyProfile-V-0.9.doc
1.0 WDP 6.5.2005 F.Kaufleitner B&R Base Document for TUV Concept approval
EPLsafetyProfile-V-1.0.doc
1.01 WDP 7.9.2005 F.Kaufleitner B&R Changes due to EPLsafety Meeting on 7.9.2005 LOP of TUV Rheinland and IXXAT EPLsafetyProfile-V1.01.doc
1.02 FWDP 29.9.2005 F.Kaufleitner B&R Reviewed documents from Working group members merged, Base Document for EPSG Board approval and TUV Rheinland approval
EPLsafetyProfile-V1.02.doc
1.03 FWDP 19.10.2005 F.Kaufleitner B&R Changes due to TÜV meeting,
Version Released by TÜV EPLsafetyProfile-V1.03.doc
D.Geßler IXXAT IXXAT Changes due to EPLsafety Meeting on 20.12.2005 - Changes due to EPLSafety-DSP-1-04-Feedback.doc
5.3, 5.4.3.5, 5.8
H.Pill LARsys Changes due to B&R Feedback
5.4.3, 5.8.6.2, 5.8.9.2, 5.8.12, 5.8.13
Extended services missing to handle failures during switching to Operational.
5.6.4.5 Pre-Operational signal now is the service SNMT_SN_reset_guarding_SCM
5.6.4.13, 5.6.4.15 SPDO could not be deactivated
5.6.4.14, 5.6.4.16 SPDO could not have no mapping entry
5.8.9.2 DVI Check for known UDIDs was missing
P.Wratil innotec Changes due to EPLsafety Meeting on 20.12.2005
7.1.2.1 Scope of Data for CRC calculation specified
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 190/191
DSP 16.12.2005 V.Sasse KW-Software
Technical Working Group released EPLsafety as a Draft Standard Proposal (DSP). The EPLsafety specification will be proofed fort two month by the EPSG members
EPLsafetyProfile-V1.04.doc
1.05 DSP 24.4.2006 F.Kaufleitner B&R Changes due to EPLsafety Meeting on 24.4.2006 according the Feedback List of the Review Phase. EPLsafetyProfile-V1.05a.doc
25.4.2006 F.Kaufleitner B&R B&R Changes due to EPLsafety Meeting on 24.4.2006 EPLsafetyProfile-V1.05b.doc
2.1
13.07.2006 P.Wratil innotec Innotec Changes due to EPLsafety Meeting on 24.4.2006 resulting in using the same CRC polynomial for subframe one and subframe two.
EPLsafetyProfile-V1.05c.doc
7.1.2.1
23.10.2006 H.Pill LARsys Several changes due to EPLsafety Stack Implementation EPLsafetyProfile-V1.05d.doc
24.10.2006 F.Kaufleitner B&R Using the same CRC polynomial for subframe one and subframe two. EPLsafetyProfile-V1.05e.doc
5.1.1.8
3.11.2006 F.Kaufleitner B&R Changes due to EPLsafety Meeting on 03.11.2006 at IXXAT / Weingarten Object 1200h, Subindex 3, datatype changed from INTEGER8 to UNSIGNED8
Object 100Dh renamed to SNMT_ResetGuarding_U32
Service SMNT_SN_calc_CRC renamed to SNMT_SN_busy
Technical Working Group released EPLsafety as a new Draft Standard Proposal (DSP
5.6.4.6
5.4.3.2
EPLsafetyProfile-V1.05.doc
1.06 DSP 21.05.2007 F.Kaufleitner B&R Coding the UDID of the SCM to sub frame one
PowerlinkSafetyProfile-V1.06a.doc
2.3.2.2 openSAFETY Domain Separation - No mandatory firewalls
5.1.1 Structure of openSAFETY Frame - xor of UDID of SCM on sub frame two of SPDO / SSDO
5.1.1.11 UDID of SCM coding (UDID of SCM) - new chapter
5.4.3 SNMT Extended Services - Additional SNMT service
5.4.3.8 UDID of SCM assignment – new chapter
5.6.4.9 Object 1019h: Unique Device ID - UDID changed to 6 Bytes
5.6.4.12 Object 1200h: Common Communication Parameter - New Object for UDIDofSCM
5.6.4.22 Object CC01h – CFFFh: SADR-UDID List - UDID changed to 6 Bytes
5.7.6.2 Pre-Operational - Receiving new SNMT
5.7.10 Safety Address Verification - Sending new SNMT
25.05.2007 F.Kaufleitner B&R UDID “00-00-00-00-00-00” for error indication
PowerlinkSafetyProfile-V1.06b.doc
openSAFETY
Safety Profile Specification
EPSG Working Draft Proposal 304 V1.4.0
EPSG WDP 304 V-1-4-0.docx 191/191
5.4.2.1 UDID Request5.4.2.2SADR assignment
5.4.2.2 SADR assignment
5.4.3.8 UDID of SCM assignment
5.6.4.9 Object 1019h: Unique Device ID - UDID changed to 6 Bytes
Major changes within version 1.06 against version 1.03 (last version released by TÜV Rheinland)
Using the same CRC polynomial for subframe one and subframe two
XOR of UDID of SCM on sub frame two of SPDO / SSDO, as a result of this measure, the openSAFETY Domain Separation isn’t safety critical anymore
1.07 DSP 08.08.2007 F.Kaufleitner B&R Feedback of Working Group implemented
PowerlinkSafetyProfile-V1.07.doc
B&R:
0 History spitted in Major Changes in III and detailed Information in App.2
1.07a DSP 08.08.2007 F.Kaufleitner B&R Feedback of Working Group implemented
PowerlinkSafetyProfile-V1.07a.doc
IXXAT – correction due to fina Review:
5.4.2.1 LE in response changed to 6
5.4.2.2 LE changed to 6
5.4.3.8 LE changed to 7
5.6.4.12 Data type changed form USINT8 to INTEGER8
1.08 WDP 30.6.2009 F.Kaufleitner B&R Working Draft Proposal
EPSG WDP 304 V-1-0-8.doc
Formal Changes Corrections according saving parametes on SN
document converted due to new template filename adapted to new naming convetion errors in Fig 76 (State diagram “Activate SN”) and Fig 72 (State diagram “SCM Operational”) corrected