CiA Draft Standard 304
CANopenFramework for safety-relevant communication
Version 1.0.1
01 January 2005
© CAN in Automation (CiA) e. V.
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
ii © CiA 2005 – All rights reserved
History
Date Version Changes
2001-01-01 1.0 Release as Draft Standard Proposal
2005-01-01 1.0.1 Publication as Draft Standard
• Editorial corrections
• Inclusion of errata
• Harmonization of terminology
General information on licensing and patents
CAN in AUTOMATION (CiA) calls attention to the possibility that some of the elements of this CiAspecification may be subject of patent rights. CiA shall not be responsible for identifying any or all suchpatent rights.
© CiA 2005-01-01
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by anymeans, electronic or mechanical, including photocopying and microfilm, without permission in writing from CiA at the addressbelow.
CAN in Automation e. V.
Am Weichselgarten 26
DE - 91058 Erlangen, Germany
Tel.: +49-9131-69086-0
Fax: +49-9131-69086-79
Url: www.can-cia.org
Email: [email protected]
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved iii
Contents
1 Scope...................................................................................................................................................... 5
2 References............................................................................................................................................. 6
2.1 Normative references...................................................................................................................... 6
2.2 Informative references .................................................................................................................... 6
3 Abbreviations and definitions ............................................................................................................ 7
3.1 Abbreviations................................................................................................................................... 7
3.2 Definitions........................................................................................................................................ 7
4 Operating principle............................................................................................................................... 8
4.1 Theory of safe operation................................................................................................................. 8
4.2 Standard CANopen functions......................................................................................................... 8
4.3 Safety-relevant communication ...................................................................................................... 9
4.3.1 Introduction .............................................................................................................................. 9
4.3.2 Timing requirements................................................................................................................ 9
5 SRDO definition .................................................................................................................................. 11
5.1 SRDO services.............................................................................................................................. 11
5.1.1 General .................................................................................................................................. 11
5.1.2 Write SRDO ........................................................................................................................... 11
5.1.3 Read SRDO........................................................................................................................... 11
5.2 SRDO protocol .............................................................................................................................. 11
5.2.1 Write SRDO protocol............................................................................................................. 11
6 Global fail-safe command ................................................................................................................. 13
6.1 GFC usage .................................................................................................................................... 13
6.2 GFC service .................................................................................................................................. 13
6.2.1 Write GFC.............................................................................................................................. 13
6.3 GFC protocol ................................................................................................................................. 13
6.3.1 Write GFC.............................................................................................................................. 13
7 Network initialisation and system boot-up..................................................................................... 14
7.1 Initialisation procedure for safety networks.................................................................................. 14
7.2 NMT states for safety devices ...................................................................................................... 15
7.2.1 General .................................................................................................................................. 15
7.2.2 Pre-operational ...................................................................................................................... 15
7.2.3 Operational ............................................................................................................................ 15
7.2.4 Stopped.................................................................................................................................. 15
7.2.5 Relation of NMT states and COBs ....................................................................................... 15
8 Pre-defined connection set ............................................................................................................... 16
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
iv © CiA 2005 – All rights reserved
9 Object dictionary ................................................................................................................................ 17
9.1 Complex data type ........................................................................................................................ 17
9.1.1 SRDO communication parameter record ............................................................................. 17
9.2 Object dictionary specifications .................................................................................................... 17
9.2.1 Object 1300h: Global fail-safe command parameter............................................................ 17
9.2.2 Object 1301h to 1340h: SRDO communication parameter .................................................. 17
9.2.3 Object 1381h to 13C0h: SRDO mapping parameter............................................................. 21
9.2.4 Object 13FEh: Configuration valid......................................................................................... 22
9.2.5 Object 13FFh: Safety configuration checksum..................................................................... 23
10 Annex A (informative) .................................................................................................................... 25
10.1 Hardware architecture............................................................................................................... 25
10.2 Configuration mechanism ......................................................................................................... 25
10.3 Mathematical analysis of CANopen safety .............................................................................. 26
10.4 Limits and recommendations.................................................................................................... 26
10.5 Rules of implementation ........................................................................................................... 26
11 Annex B (informative) .................................................................................................................... 27
11.1 Overview on objects for safety communication ....................................................................... 27
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved 5
1 Scope
The services and protocols defined in this document are intended to be an add-on to the CANopenapplication layer and communication profile.
Safety-relevant communication is an additional property of such devices. The manufacturer and thesystem integrator shall take care, that the safety requirements are allocated to safe communicationobjects, that the hardware and software of the device support the safety function and that the device isoperated within its safe limits.
This specification describes only the data transport mechanism on a CANopen network, that allowsthe exchange of safety-relevant data.
Due to CANopen compatibility communication is limited to 64 safe communication objects, so up to 64suppliers of safety-relevant objects can operate in a CANopen network. The number of consumers ofthe safety-relevant objects is not defined (at least one receiver is necessary).
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
6 © CiA 2005 – All rights reserved
2 References
2.1 Normative references
/CiA301/ CiA DS 301, CANopen application layer and communication profile
/EN954-1/ EN 954-1, Safety related parts of control systems - Part 1: General principlesof design
/IEC61508/ IEC 61508, Functional safety of electrical/electronic/programmable electronicsafety-related systems
/DIN801/ DIN V VDE 0801, Grundsätze für Rechner in Systemen mit Sicherheitsauf-gaben
2.2 Informative references
/CHAR/ Charzinsiki:1991, Bewertung der Fehlersicherungsverfahren im CAN-Protokoll, Universität Stuttgart
/FAET/ Grundsatz für die Prüfung und Zertifizierung von “Bussystemen für die Über-tragung sicherheitsrelevanter Nachrichten”, Fachausschuss Elektrotechnik,Köln, Ausgabe 05.02, GS-ET-26
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved 7
3 Abbreviations and definitions
3.1 Abbreviations
AK Anforderungsklassen - requirement classes
BIA Berufsgenossenschaftliches Institut für Arbeitssicherheit - Institute for occupa-tional safety of accident insurance institutions
CAN Controller area network
CAN-ID CAN identifier
COB Communication object
COB-ID COB identifier
GFC Global failsafe command
NMT Network management
PLC Programmable logic controller
RTR Remote transmission request
SCT Safeguard cycle time
SIL Safety integrity level
SRDO Safety-relevant data object
SRVT Safety-relevant object validation time
TÜV Technischer Überwachungsverein - German association for technical inspection
3.2 Definitions
The definitions given in /CiA301/ apply for this framework, too.
Safety controller
device that consumes safety-relevant data
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
8 © CiA 2005 – All rights reserved
4 Operating principle
4.1 Theory of safe operation
It is absolutely essential for a safe system, that there is a safe state. A reaction to an emergencycommand, an alarm or an error, the safe-state is entered.
It is also important, that the functionality of the safeguard measures is regularly checked. A singledefect in a safety-relevant communication shall not override the safety circuitry! If such an error oc-curs, it shall be detected within a short period of time in which a second error is unlikely to happen.
All the systems, especially the safety-relevant circuitry shall have a high reliability in order to extendthe time-span between the safety-tests and minimize the down-time of the whole system (e.g. if one ofredundant components fails, the system shall be shut-off). So the need for safety decreases the avail-ability of a system.
The idea of safety in CAN communication is not to ensure, that there are absolutely no errors andfaults. This would be rather hard to proof - anyway. The goal is to detect all possible errors and reactin a predictable (safe) way.
In a safe CAN system there are sources of safe information (e.g. safety switches, light barriers, emer-gency stop buttons) and consumers of such information (e.g. relay, valve or drive controlling a possi-bly dangerous movement, safety PLC). As the "consumers" control the possible dangerous situation itis responsible for entering the safe-state after any safety-relevant interference. It also shall check thedata integrity of the safety-relevant communication.
As the sources (safety inputs) are the origin of safe communication objects (SRDOs), their number islimited to 64. The number of safety controllers is not limited in theory, as CAN allows many consumersto listen to the same SRDO(s), i.e. many actuator devices use the same information.
As the safety controllers are responsible for the data integrity and actuality, every safety-relevant out-put device shall to survey all corresponding sources of safety-relevant data.
4.2 Standard CANopen functions
It is intended, that the additional safe communication is not affecting the normal operation and serv-ices on a CANopen network. Safe communication is not related to a special class of devices, so nospecial device profile is required.
PLC
S1 N1 S2 N2 N3 D1
MEmergencyPush Button
SLM
DriveControll
CAN Safety PowerSwitch
S3
Sx Safety Node (S3: Saftey controller)Nx Normal NodeDx Drive Controll
Figure 1: Example of a CANopen network with safety-relevant devices
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved 9
To ensure compatibility, the usage of identifiers and pre-defined objects shall be coordinated with theCANopen standard and existing device profiles. As there is no use of data bits in the safe communica-tion method, it is compatible with existing device profiles.
In a CANopen network the data interface to the application program within a certain node is only viathe CANopen object dictionary. The application itself shall transfer data correct, in time and in se-quence to the CANopen kernel. In case of SRDO reception, the application shall collect and checkSRDO data so frequently, that the time expectation is fulfilled.
4.3 Safety-relevant communication
4.3.1 Introduction
The safety-relevant data transfer is performed by means of SRDO.
An SRDO shall consist of two CAN data frames with identifiers, which shall be different in at least twobit positions. The user data in both transmissions is redundant, i.e. the meaning of the data is thesame, but the data on the 2nd transmission is inverted bitwise.
SRDOs shall be transmitted periodically. If required, SRDOs may also be transmitted event-driven,e.g. to ensure fast reaction after a safety critical change on the input. RTR shall not be possible;SRDOs shall be only allowed in the NMT state operational.
An SRDO shall be only valid, if both CAN frames are received properly (without failure and in time).The redundant transmission is sent after the first transmission to the CAN controller with minimumdelay.
There are two kinds of use for SRDOs. The first is data transmission and the second data reception. Itis distinguished by the information direction. Devices where the information direction is set to trans-mit (tx) are SRDO producer and devices where the information direction is set to receive (rx) are calledSRDO consumer. SRDOs are described by the SRDO communication parameter (26h) and the SRDOmapping parameter. The structure of this data type is explained in chapter 9.1.1. The SRDO commu-nication parameter describes the communication capabilities of the SRDO. The SRDO mapping pa-rameter contains information about the content of the SRDOs (variables). The indices of the corre-sponding object dictionary entries are computed by the following formulas:
SRDO communication parameter index = 1300h + SRDO-number
SRDO mapping parameter index = 1380h + SRDO-number
For each SRDO the pair of communication and mapping parameter is mandatory. These parameterobjects are described in chapter 9.2.2 and 9.2.3.
4.3.2 Timing requirements
In order to test the correct function of the periodical SRDO transmission on the CAN network, thesafety controller shall be assigned with the SCT. If the SCT expires, the safety controller shall transit tothe safe state.
SRDO
refreshtime
SRDO
refreshtime
SRDO
refreshtime
SCTSCT
SCT
! SCT expired!!!
t
Figure 2: Example for SCT timing
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
10 © CiA 2005 – All rights reserved
A second test determines, if there is sufficient network capacity for a safety system. Both CAN framesthat make an SRDO shall be received correctly within the given SRVT. Normally both CAN frames aretransmitted with minimum delay. If the 2nd CAN frame is not being received within SRVT, the networkmay have reduced transmission capabilities. The reaction time on a safety-relevant event is enlarged.If the SRVT expires, the safety controller shall transit to the safe state.
SRDO
t
SRDO SRDO SRDO?
SRVT SRVT SRVT SRVT
SRVTexpired
Figure 3: Example for SRVT timing
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved 11
5 SRDO definition
5.1 SRDO services
5.1.1 General
SRDO transmission follows the producer/consumer relationship in /CiA301/ and consists of two CANdata frames.
Attributes:
• SRDO number: SRDO number [1..64] for every user type on the local device• user type: one of the values {consumer, producer}• data type: according to the SRDO mapping• refresh-time: n*1 ms, n > 0• validation-time: n*1 ms, n > 0
5.1.2 Write SRDO
For the write SRDO service the push model shall be used. There shall be one or more consumers ofan SRDO. An SRDO shall have exactly one producer.
Through this service the producer of an SRDO shall send the data of the mapped application object tothe consumer(s).
Table 1: Write SRDO
Parameter Request / Indication
ArgumentSRDO numberData
MandatoryMandatoryMandatory
5.1.3 Read SRDO
The read SRDO service shall be not allowed.
5.2 SRDO protocol
5.2.1 Write SRDO protocol
The service for an SRDO write request shall be unconfirmed. The SRDO producer shall send theprocess data within an SRDO to the network. There may be 1 to an SRDO consumers. At the SRDOconsumer(s) the reception of a valid SRDO shall be indicated.
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
12 © CiA 2005 – All rights reserved
Figure 4: Write SRDO protocol
Process-data: up to L bytes of application data according to the SRDO mapping.
If L exceeds the number 'n' defined by the actual SRDO mapping length, only the first 'n' bytes shall beused by the consumer. If L is less than 'n' the data of the received SRDO shall be not processed andan Emergency message with error code 8210h shall be produced if Emergency is supported.
An SRDO shall not be requested by RTR.
Process data
Bit-wise inverted process data
Process data
Bit-wise inverted process data
SRDOproducer
SRDOconsumer(s)
Write SRDO
re-fresh-
SCT
SRVT
SRVT
Request
Indication(s)
Request
Indication(s)
0 L (0 ≤ L ≤ 8)
0 L (0 ≤ L ≤ 8)
Indication(s)
Indication(s)
SRVT event
SCT event
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved 13
6 Global fail-safe command
6.1 GFC usage
In order to speed up the system reaction time, the GFC may be used.
If one transmission at least have been received, the GFC shall be already valid. It allows only onereaction in a CAN network. For that reason, the usage of the GFC is optional. It is event-driven onlyand not safe (no periodic time expectation).
Example: After a safety-relevant change at a device input, the GFC may be transmitted first (optional),then the corresponding SRDO shall follow to maintain safety.
6.2 GFC service
6.2.1 Write GFC
The GFC transmission shall follow the producer/consumer push model as described in /CiA301/. Theservice shall be unconfirmed; the corresponding SRDO shall follow.
Attributes:
• user type: one of the values {consumer, producer}• data type: nil
6.3 GFC protocol
6.3.1 Write GFC
Figure 5: Write GFC protocol
Process data
GFCproducer
GFCconsumer(s)
Write GFC
RequestIndication(s)
Request
L = 0
0 L (0 ≤ L ≤ 8)
CAN-ID = 1
Bit-wise inverted process dataIndication(s)
0 L (0 ≤ L ≤ 8)
Indication(s)SRVT
SRVT Event
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
14 © CiA 2005 – All rights reserved
7 Network initialisation and system boot-up
7.1 Initialisation procedure for safety networks
The network initialisation process is controlled by the NMT master application or configuration applica-tion.
Figure 6: Flow chart of the network initialisation process for safety networks
In step A the devices shall be in the NMT state pre-operational, which is entered automatically afterpower-on. In this state, the devices are accessible via their default SDO using CAN-IDs that are beenassigned according to the pre-defined connection set. In this step, the configuration of device pa-rameters take place on all devices, which support parameter configuration. Some configuration dataare safety-relevant. So additional measures shall be taken, to ensure the safety function in the net-work.
This is done from a configuration application or tool, which resides on the device that is the client forthe default SDOs. For devices that support these features the selection and/or configuration of PDOs,the mapping of application objects (PDO mapping), the selection and/or configuration of SRDOs, themapping of application objects (SRDO mapping), the configuration of additional SDOs and optionallythe setting of COB-IDs may be performed via the default SDO objects.
In many cases, a configuration is not necessary as default values are defined for all application andcommunication parameters.
If the application requires the synchronisation of all or some nodes in the network, the appropriatemechanisms may be initiated in the optional step B. It may be used to ensure that all devices exceptsafety nodes are synchronised by the SYNC object before entering the NMT state operational in stepE. The first transmission of SYNC object starts within 1 sync cycle after entering the NMT state pre-operational.
In step C node guarding may be activated (if supported) using the guarding parameters configured instep A.
Configuration of all device parameters,including communication parameters
(via default SDO)
(Optional)Start transmission of SYNC, wait for
synchronisation of all devices
(Optional)Start of node guarding or heartbeat
Verify safetyconfiguration parameters
Setting of all devices tothe NMT state operational
A
B
C
D
E
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved 15
In step D there shall be a method performed for the check of the authenticity of the configuration data.It covers the following safety relevant configuration objects:
• SRDO numbers(s) used
• Time expectation (refresh time, SCT, and the SRVT)
• Information direction
• Mapping parameter
The checksum of the respective configuration entries shall be defined, that the safe application maycheck if a safety configuration tool has been used and that the content of the configuration entries hasnot been changed in state operational In case of mismatch, the safety node shall not transmit SRDOs;the safety controller shall enter (or shall stay in) the safe state.
7.2 NMT states for safety devices
7.2.1 General
The "safe state" of a device is not a CANopen communication state and falls not in the scope of thisframework.
7.2.2 Pre-operational
In the NMT state pre-operational, communication via SDOs is possible, however SRDO and PDOcommunication shall be not allowed. Configuration of SRDOs, PDOs, device parameters and also theallocation of application objects (PDO mapping) may be performed by a configuration application. Thedevice may be switched into the NMT state operational directly by sending a Start_Remote_Noderequest. In the NMT state pre-operational the application is in the safe-state.
7.2.3 Operational
In the NMT state pre-operational, SRDO and PDO communication are active, however SDO writeaccess shall be is not possible. For the safe application this is the only working state (e.g. motor on).Safety communication is only supported in this state.
7.2.4 Stopped
By switching a safety device in the NMT state stopped limits the communication to NMT messages.The application shall be in the safe state.
7.2.5 Relation of NMT states and COBs
Table 2 shows the relation between NMT states and COBs. Services on the listed COBs shall only beexecuted if the device is in one of the appropriate NMT states.
Table 2: States and communication objects
INITIALISING PRE-OPERATIONAL OPERATIONAL STOPPED
PDO Allowed
SDO Allowed Allowed1
SRDO Allowed
Synchronization object Allowed Allowed
Time stamp object Allowed Allowed
Emergency object Allowed Allowed
Boot-up object Allowed
NMT object Allowed Allowed Allowed1 Writing to a safety object in the NMT state operational shall lead to an abort message (abortcode: 0800 0022h). Reading of a safety entry in the NMT state operational is allowed.
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
16 © CiA 2005 – All rights reserved
8 Pre-defined connection set
In order to reduce configuration effort for simple networks, a mandatory default identifier allocationscheme is defined in /CiA301/.
This pre-defined connection set is extended to support one SRDOs for every safety device with anode-ID between 1 and 64. Devices with a node-ID, which is higher than 64, shall not have pre-defined CAN-ID assigned for SRDOs.
Table 3: Broadcast objects of the pre-defined connection set
Object Function code Resulting CAN-IDs
GFC 0000b 1 (001h)
Table 4: Peer-to-peer objects of the pre-defined connection set
Resulting CAN-IDsObject Function
code Normal data Complement data
Communicationparameters at index
Channeldirection
SRDO(node-ID 1 to 32)
0010b257d to 319d
(1)
(101h to 13Fh)258d to 320d
(1)
(102h to 140h)1301h to 1340h tx
SRDO(node-ID 33 to 64)
0010b321d to 383d
(1)
(141h to 17Fh)322d to 384d
(1)
(142h to 180h)1301h to 1340h rx
(1) Every second CAN-ID is used.
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved 17
9 Object dictionary
9.1 Complex data type
9.1.1 SRDO communication parameter record
Index Sub-Index Description Data type
00h Highest sub-index supported UNSIGNED8
01h Information direction UNSIGNED8
02h Refresh-time/SCT UNSIGNED16
03h SRVT UNSIGNED8
04h Transmission type UNSIGNED8
05h COB-ID 1 UNSIGNED32
0026h
06h COB-ID 2 UNSIGNED32
9.2 Object dictionary specifications
9.2.1 Object 1300h: Global fail-safe command parameter
VALUE DEFINITION
00h: GFC is not valid
01h: GFC is valid
02h to FFh: reserved
OBJECT DESCRIPTION
INDEX 1300h
Name Global failsafe command parameter
Object code VAR
Data type UNSIGNED8
Category Optional
ENTRY DESCRIPTION
Access rw
PDO mapping No
Value range See value definition
Default value 00h
9.2.2 Object 1301h to 1340h: SRDO communication parameter
These objects shall contain the communication parameters for the SRDOs the device is able to re-ceive or to transmit. The type of the SRDO communication parameter (26h) is described in 9.1.1.
The sub-index 00h shall contain the number of highest entry within the communication record.
At sub-index 01h shall reside the information direction of the SRDO. The SRDO information directionallows to select if it is used as a receive SRDO or as a transmit SRDO in the operational state. Theremay be SRDOs fully configured (e.g. by default) but not used, and therefore set to "not valid" (de-
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
18 © CiA 2005 – All rights reserved
leted). The feature is necessary for devices supporting more than one SRDO, because each devicewith a node-ID in the range from 1 to 64 has only default identifiers for the first SRDO. It is not allowedto change the COB-ID 1 or COB-ID 2 while the SRDO exists (value unequal to 0).
Sub-index 02h shall contain the refresh-time or the SCT depending on the information direction (see4.3.2).
Sub-index 03h shall contain the SRDO validation time, if it is an SRDO with rx direction (see 4.3.2).
The transmission type (sub-index 4h) defines the transmission
reception character of the SRDO. It is defined as type 254 /CiA301/ describes the usage of this entry.On an attempt to change the value of the transmission type an abort message (abort code: 06090030h) is generated.
At sub-index 05h and sub-index 06h shall reside the two COB-IDs of the SRDO. These entries weredefined as UNSIGNED32 for compatibility reasons to the COB-ID definitions in /CiA301/. The CAN-IDsmay only be changed in the range from 101h to 180h. Every SRDO uses two following CAN-IDs fromthis range, where the first CAN-ID is odd and the second CAN-ID is even.
VALUE DEFINITION
Sub-index 01h:
Value Description
00h Does not exist / is not valid
01h Exists / is valid for transmit (ts)
02h Exists / is valid for receive (rx)
03h to FFh Reserved
Sub-index 02h:
The refresh-time and SCT shall be given in ms. Value 0 shall be not used.
Sub-index 03h:
The SVT shall be given in ms. Value 0 shall be not used.
Sub-index 04h:
See PDO communication parameters (transmission type) in /CiA301/.
Sub-index 05h and 06h:
31 11 10 0
reserved (0) CAN-ID
MSB LSB
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved 19
OBJECT DESCRIPTION
INDEX 1301h to 1340h
Name SRDO communication parameter
Object code RECORD
Data type SRDO parameter
Category Mandatory for each supported SRDO
ENTRY DESCRIPTION
Sub-index 00h
Description Highest sub-index supported
Entry category Mandatory
Access ro
PDO mapping No
Value range 06h
Default value 06h
Sub-index 01h
Description Information direction
Entry category Mandatory
Access rw (only in NMT state pre-operational)
PDO mapping No
Value range see value definition
Default value1301h: manufacturer-specific
1302h to 1340h: 00h
Sub-index 02h
Description tx: refresh-time
rx: SCT
Entry category Mandatory
Access rw (only in NMT state pre-operational)
PDO mapping No
Value range UNSIGNED16
Default value 25d (if information direction is tx)
50d (if information direction is rx)
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
20 © CiA 2005 – All rights reserved
Sub-index 03h
Description not used (if information direction is tx)
SVT (if information direction is rx)
Entry category Conditional (if information direction is rx)
Access rw (only in NMT state pre-operational)
PDO mapping No
Value range UNSIGNED16
Default value 20d
Sub-index 04h
Description Transmission type
Entry category Mandatory
Access ro
PDO mapping No
Value range 254d
Default value 254d
Sub-index 05h
Description COB-ID 1
Entry category Mandatory
Access rw (only in NMT state pre-operational)
PDO mapping No
Value range Odd values only: 257d to 383d
Default value 1301h: 0000 00FFh + (2 x node-ID)
1302h to 1340h: manufacturer-specific
Sub-index 06h
Description COB-ID 2
Entry category Mandatory
Access rw (only in NMT state pre-operational)
PDO mapping No
Value range Even values only: 258d to 384d
Default value 1301h: 0000 0100h + (2 x node-ID)
1302h to 1340h: manufacturer-specific
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved 21
9.2.3 Object 1381h to 13C0h: SRDO mapping parameter
These objects shall contain the mapping parameters for the SRDOs the device is able to receive ortransmit. The type of the SRDO mapping parameter is an array of type UNSIGNED32. The sub-index00h contains the number of valid entries within the mapping array. This half of the number of entries isalso the number of the application variables, which shall be received/transmitted with the correspond-ing SRDO. The sub-indices from 01h to number of entries contain the information about the mappedapplication variables. The structure and the procedure for the mapping is described in /CiA301/. Forchanging the SRDO mapping first the SRDO shall be deleted.
VALUE DEFINITION
Sub-index 00h:
00h: mapping not valid
02h, 04h to 80h (only even values): mapping valid
01h, 03h to 7Fh (only odd values): reserved
Sub-index 01h to 80h:
See PDO mapping parameters in /CiA301/.
OBJECT DESCRIPTION
INDEX 1381h to 13C0h
Name SRDO mapping parameter
Object code ARRAY
Data type UNSIGNED32
Category Mandatory for each supported SRDO
ENTRY DESCRIPTION
Sub-index 00h
Description Highest sub-index supported
Entry category Mandatory
Access ro or rw (only in NMT state pre-operational, and if variable mapping issupported)
PDO mapping No
Value range See value definition
Default value (Device profile dependent)
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
22 © CiA 2005 – All rights reserved
Sub-index 01h, 03h, 05h to 7Fh (only odd indices)
Description SRDO mapping for the n-th applicationobject to be mapped (data not inverted)
Entry category Conditional; depends on number of ob-jects to be mapped
Access rw
PDO mapping No
Value range UNSIGNED32
Default value (Device profile dependent)
Sub-index 02h, 04h, 06h to 80h (only even indices)
Description SRDO mapping for the n-th applicationobject to be mapped (data inverted)
Entry category Conditional; depends on number of ob-jects to be mapped
Access rw
PDO mapping No
Value range UNSIGNED32
Default value (Device profile dependent)
9.2.4 Object 13FEh: Configuration valid
This object shall contain an acknowledgement flag for a valid configuration. After write access to anyof the safety-relevant parameter, this object shall be automatically set to invalid configuration (00h). Ifthe configuration is finished, the user writes the “valid” value to this object.
VALUE DEFINITION
A5h: Configuration valid
All other values shall indicate an invalid configuration.
OBJECT DESCRIPTION
INDEX 13FEh
Name Configuration valid
Object code VAR
Data type UNSIGNED8
Category Mandatory
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved 23
ENTRY DESCRIPTION
Access rw (only in NMT state pre-operational)
PDO mapping No
Value range See value definition
Default value 00h
9.2.5 Object 13FFh: Safety configuration checksum
VALUE DEFINITION
This array shall provide the CRC for each SRDO individually.
The generator polynomial shall be: G(x) = X16+x12+x5+1
The order for data, which are checked by the CRC, shall be as follows:
SRDO communication parameter
a) Information direction 1 byte = a7...a0
b) Refresh time or SCT 2 byte = b15...b0
c) SRVT 1 byte = c7...c0
d) COB-ID 1 4 byte = d31...d0
e) COB-ID 2 4 byte = e31...e0
SRDO mapping parameter
f) Sub-index 00h 1 byte (Number of mapped application objects in SRDO) = f7...f0
g1) Sub-index 1 byte (SRDO mapping for the nth application object to be mapped) = g17...g
10
h1) Mapping data 4 byte (2 byte index, 1 byte sub-index, 1 byte data length) = h131...h
10
to
g128) Sub-index 1 byte (SRDO mapping for the nth application object to be mapped) = g1287...g
1280
h128) Mapping data 4 byte (2 byte index, 1 byte Sub-index, 1 byte data length) = h12831...h
1280
D(x) = xn+ ...........+x0
D(x) = a7+...+a0+b7+...+b0+b15+...+b8+c7+...+c0+d7+...+d0+d15+...+d8+d23+...+d16+d31+...+d24+… etc.
The CRC shall start with the value 0000h.
OBJECT DESCRIPTION
INDEX 13FFh
Name Safety configuration checksum
Object code ARRAY
Data type UNSIGNED16
Category Mandatory
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
24 © CiA 2005 – All rights reserved
ENTRY DESCRIPTION
Sub-index 00h
Description Highest sub-index supported
Entry category Mandatory
Access rw (only in NMT state pre-operational)
PDO mapping No
Value range 00h to 40h
Default value 01h
Sub-index 01h
Description Checksum-1
Entry category Mandatory
Access rw (only in NMT state pre-operational)
PDO mapping No
Value range UNSIGNED16
Default value 0000h
Sub-index 02h
Description Checksum-2
Entry category Mandatory for each additional supportedSRDO
Access rw (only in NMT state pre-operational)
PDO mapping No
Value range UNSIGNED16
Default value 0000h
to
Sub-index 40h
Description Checksum-64
Entry category Conditional;
Mandatory for each additional supportedSRDO
Access rw (only in NMT state pre-operational)
PDO mapping No
Value range UNSIGNED16
Default value 0000h
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved 25
10 Annex A (informative)
10.1 Hardware architecture
In a safe system the hardware and the software are interdependent on each other. Depending on thelevel of safety required various structures are useful. For this specification the implementation modelshown in Figure 7 is considered, it requires one CAN transceiver, two CAN controllers partly, and re-dundant object dictionaries.
1: CAN transceiver 2: CAN controller 3: Micro-controller
Figure 7: C-model for safety-relevant communication networks compliant to SIL 2 andSIL 3 /IEC61508/ or AK 4 and AK 6 /DIN801
10.2 Configuration mechanism
configuration tool safety device
Figure 8: Principle of a safe configuration
All safety parameter are downloaded to the safety device. After that, the parameters are uploaded tothe configuration tool. The data is compared and if it is without failure it is acknowledged.
The first configuration (including bit-rate and node-ID) shall be enforced accordingly the category of/EN954-1/.
CAN
2
2
1
3
3
2
2
1
3
3
write all safety-relevant parameter incl.checksumms
read back all safety-relevant parameterincl. checksums
configuration acknowledged
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
26 © CiA 2005 – All rights reserved
10.3 Mathematical analysis of CANopen safety
The worst case residual error probability of the CAN protocol is
P stRe = ⋅ ≈ ⋅− −7 10 1 109 8 /CHAR/
For model C /FAET/ sending the same data twice the result is
2Re stPP =
The residual error rate per hour is
Λ ≡ ⋅ ⋅ ⋅ −( ) ⋅3600 1 100P mν
ν: safety relevant messages per second
m: number of safety relevant devices = max. 64
P: residual error probability
The error rate per hour for SIL 3 shall be < 10-7, for SIL 2 it shall be < 10-6 and for SIL 1 it shall be <10-5 (/IEC61508/). For SIL 3 is the SRDO transfer limited to 44 SRDO per second. This results in arefresh time of 23 ms with 64 safety devices.
10.4 Limits and recommendations
• In general the use of remote frames in a safety relevant CANopen network is not recommended.(RTR to SRDOs is not possible anyway).
The use of "node guarding" in a safety-relevant CANopen network is restricted. If required, use insteadthe optional "heartbeat" (SRDOs have an implicit guarding mechanism).
In a network with safety-relevant devices it is not allowed for non safety-relevant devices to use theCAN-IDs defined in this specification.
The implementation of the CANopen safety protocols is allowed only in safety-relevant devices.
10.5 Rules of implementation
• The first cyclic transmit of an SRDO shall be delayed for 0.5 ms * node-ID.
• A transmitted SRDO shall be built by two different ways from the application.
• A received SRDO shall be compared bit by bit (modulo 2) in the application (data and identifier).
• It shall be guaranteed that the message buffers of the CAN controller are dynamically tested.
• The application shall check that the two CAN telegrams of an SRDO are received in chronologicalorder (high priority identifier first). It is important to mark an old received SRDO as invalid.
• The application shall check the parameter in the transition from pre-operational to operational. TheCRC-entry in the object dictionary shall be equal to the CRC calculation of the safety device andthe “configuration-valid” – flag shall be valid.
Important:
• The rules for implementation of hard-, soft- and firmware in a safety device are defined in /DIN801/or /IEC61508/!
DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA
© CiA 2005 – All rights reserved 27
11 Annex B (informative)
11.1 Overview on objects for safety communication
Table 5: Safety communication objects
Index Object Name Type Acc.1 M/O
1300h VAR GFC parameter UNSIGNED8 rw O
SRDO communication parameter
1301h RECORD 1st SRDO parameter SRDO parameter (26h) rw M
1302h RECORD 2nd SRDO parameter SRDO parameter (26h) rw M/O*
::::: ::::: ::::: ::::: ::::: :::::
1340h RECORD 64th SRDO parameter SRDO parameter (26h) rw M/O*
1341h reserved
::::: :::::
1380h reserved
SRDO mapping parameter
1381h ARRAY 1st SRDO mapping UNSIGNED32 rw M
1382h ARRAY 2nd SRDO mapping UNSIGNED32 rw M/O*
::::: ::::: ::::: ::::: ::::: :::::
13C0h ARRAY 64th SRDO mapping UNSIGNED32 rw M/O*
13C1h reserved
::::: :::::
13FDh reserved
13FEh VAR Configuration valid UNSIGNED 8 rw M
13FFh ARRAY Safety configuration checksum UNSIGNED16 ro M1Access type listed here may vary for certain sub-indices. See detailed object specification.
* If a device supports SRDOs, the according SRDO communication parameter and SRDO mappingentries in the object dictionary are mandatory. These objects may be read only.