CANopen Safety
CANopen Safety – originally defined in CiA 304 – has been published as European standard (EN 50325-5).
It specifies a communication, which complies with the requirements of SIL-3 applications, on a CAN network.
This safety relevant communication can be realized in parallel to existing CANopen communications.
Principles
In addition to normal CANopen services such as SDO and PDO there is a special SRDO service (Safety Related Data Object) to meet the requirements of a safe communication. Its configuration and handling is similar to a PDO, but a set of additional properties are defined: These are:
- cyclic data transfer with time out monitoring
- double transfer of data, 2nd data are inverted
- check if both messages (normal + inverted) are close together
- protection of configuration by a CRC
SCT means Safety Cycle Time and it is the cycle time of an SRDO transmission. If the SCT is exceeded it is detected by the consumers and they enter a safe state. SRVT means safety-related validation time and it is the maximum time that may pass between the 2 CAN messages of one SRDO. A violation of the SRVT is a safety event as well.
Additionally the COB-IDs in the range 0x100 up to 0x180 are used, the that the transmission does not interfere with any other CANopen service and to ensure that the priority of the CAN messages is higher than the one of PDOs.
Configuration Objects
The configuration objects of the service are:
- 0x1301 – 0x1340 … SRDO communication
- 0x1381 – 0x13C0 … SRDO mapping
- 0x13FE … Configuration valid flag
- 0x13FF … Safety configuration CRCs
The ‘Configuration valid flag’ is a flag that indicates that the complete configuration is valid and the ‘Safety configuration CRC’ objects include the CRC for a single SRDO configuration.
SRDO Communication Parameter Objects
The SRDO Communication Parameter have the following structure:
| Sub index | Description | Data type |
| 1 | Information Direction | UNSIGNED8 |
| 2 | Refresh-time/SCT | UNSIGNED16 |
| 3 | SRVT | UNSIGNED8 |
| 4 | Transmission Type | UNSIGNED8 |
| 5 | COB-ID 1 (normal) | UNSIGNED32 |
| 6 | COB-ID 2 (inverted data) | UNSIGNED32 |
SRDO Mapping Object
The structure of the SRDO mapping objects is similar to the PDO mapping objects:
| Sub index | Description | Data type |
| 0 | Highest sub-index supported | UNSIGNED8 |
| 1 | mapping entry for data object 1 (plain data) | UNSIGNED32 |
| 3 | mapping entry for data object 2 (plain data) | UNSIGNED32 |
| … | … | … |
Theoretically up to 64 application objects may be mapped into a SRDO. These objects must exist in the object dictionary both “normal” and inverted. Normally single bits are not mapped but bytes or words, so mostly the maximum number of objects in an SRDO is 8.
Implementation Variants
Besides the CANopen safety chip (CSC02) by CAN in Automation e.V. some CANopen stack vendor offer CANopen stacks with SRDO support. Anyway, in addition to the protocol stack the developer of the device needs to fulfill the requirements for a SIL-3 development.
Tools for Analysis and Configuration
As the configuration of each SRDO is protected with a check sume, it is difficult to handle it with a simple CANopen tools that only provides SDO access to objects. Thus it is better to use a specialized tool like the CANopen DeviceExplorer as shown below.
The tool provides a mask to configure single SRDOs and an sophisticated CANopen interpretation including a interpretation of the SRDO messages. EDS or DCF files of all nodes in the network may be imported and the SRDOs will be interpreted as configured.