CANopen Safety – A beginner’s guide

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
CANopen Safety Timing
CANopen Safety Timing

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.
CANopen Safety Configuration
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.