CiA Draft Standard 304 © CAN in Automation (CiA) e. V. - datamicro.ru

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiAHistoryDate Version Changes2001-01-01 1.0 Release as Draft Standard Proposal2005-01-01 1.0.1 Publication as Draft Standard• Editorial corrections• Inclusion of errata• Harmonization of terminologyGeneral information on licensing and patentsCAN 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-01All 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 26DE - 91058 Erlangen, GermanyTel.: +49-9131-69086-0Fax: +49-9131-69086-79Url: www.can-cia.orgEmail: headquarters@can-cia.orgii© CiA 2005 – All rights reserved

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA1 ScopeThe 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).© CiA 2005 – All rights reserved 5

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA2 References2.1 Normative references/CiA301//EN954-1//IEC61508/CiA DS 301, CANopen application layer and communication profileEN 954-1, Safety related parts of control systems - Part 1: General principlesof designIEC 61508, Functional safety of electrical/electronic/programmable electronicsafety-related systems/DIN801/DIN V VDE 0801, Grundsätze für Rechner in Systemen mit Sicherheitsaufgaben2.2 Informative references/CHAR//FAET/Charzinsiki:1991, Bewertung der Fehlersicherungsverfahren im CAN-Protokoll, Universität StuttgartGrundsatz für die Prüfung und Zertifizierung von “Bussystemen für die Übertragungsicherheitsrelevanter Nachrichten”, Fachausschuss Elektrotechnik,Köln, Ausgabe 05.02, GS-ET-266 © CiA 2005 – All rights reserved

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA3 Abbreviations and definitions3.1 AbbreviationsAK Anforderungsklassen - requirement classesBIA Berufsgenossenschaftliches Institut für Arbeitssicherheit - Institute for occupationalsafety of accident insurance institutionsCAN Controller area networkCAN-ID CAN identifierCOB Communication objectCOB-ID COB identifierGFC Global failsafe commandNMT Network managementPLC Programmable logic controllerRTR Remote transmission requestSCT Safeguard cycle timeSIL Safety integrity levelSRDO Safety-relevant data objectSRVT Safety-relevant object validation timeTÜV Technischer Überwachungsverein - German association for technical inspection3.2 DefinitionsThe definitions given in /CiA301/ apply for this framework, too.Safety controllerdevice that consumes safety-relevant data© CiA 2005 – All rights reserved 7

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA4 Operating principle4.1 Theory of safe operationIt 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 occurs,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 availabilityof 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, emergencystop buttons) and consumers of such information (e.g. relay, valve or drive controlling a possiblydangerous 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 outputdevice shall to survey all corresponding sources of safety-relevant data.4.2 Standard CANopen functionsIt is intended, that the additional safe communication is not affecting the normal operation and serviceson a CANopen network. Safe communication is not related to a special class of devices, so nospecial device profile is required.PLCCANSafety PowerSwitchS1 N1 S2 N2 N3 D1S3EmergencyPush ButtonSLMSx Safety Node (S3: Saftey controller)Nx Normal NodeDx Drive ControllMDriveControllFigure 1: Example of a CANopen network with safety-relevant devices8 © CiA 2005 – All rights reserved

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiAA 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.SRDOSRDO SRDO SRDO?SRVTSRVTSRVTSRVTSRVTexpiredtFigure 3: Example for SRVT timing10 © CiA 2005 – All rights reserved

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA5 SRDO definition5.1 SRDO services5.1.1 GeneralSRDO 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 > 05.1.2 Write SRDOFor 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 SRDOParameterArgumentSRDO numberDataRequest / IndicationMandatoryMandatoryMandatory5.1.3 Read SRDOThe read SRDO service shall be not allowed.5.2 SRDO protocol5.2.1 Write SRDO protocolThe 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.© CiA 2005 – All rights reserved 11

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiASRDOproducerRequest0Write SRDOL (0 ≤ L ≤ 8)Process dataSRDOconsumer(s)Bit-wise inverted process dataSRVTIndication(s)re-fresh-Request0 L (0 ≤ L ≤ 8)Process dataSRVTBit-wise inverted process dataSCTIndication(s)Indication(s)SRVT eventIndication(s)SCT eventFigure 4: Write SRDO protocolProcess-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 8210 h shall be produced if Emergency is supported.An SRDO shall not be requested by RTR.12 © CiA 2005 – All rights reserved

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA6 Global fail-safe command6.1 GFC usageIn 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 service6.2.1 Write GFCThe 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: nil6.3 GFC protocol6.3.1 Write GFCGFCproducerRequestWrite GFCCAN-ID = 1L = 0GFCconsumer(s)Indication(s)0 L (0 ≤ L ≤ 8)RequestProcess data0 L (0 ≤ L ≤ 8)Bit-wise inverted process dataIndication(s)SRVTIndication(s)SRVT EventFigure 5: Write GFC protocol© CiA 2005 – All rights reserved 13

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA7 Network initialisation and system boot-up7.1 Initialisation procedure for safety networksThe network initialisation process is controlled by the NMT master application or configuration application.Configuration of all device parameters,including communication parameters(via default SDO)A(Optional)Start transmission of SYNC, wait forsynchronisation of all devicesB(Optional)Start of node guarding or heartbeatCVerify safetyconfiguration parametersDSetting of all devices tothe NMT state operationalEFigure 6: Flow chart of the network initialisation process for safety networksIn 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 parameterstake 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 network.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 preoperational.In step C node guarding may be activated (if supported) using the guarding parameters configured instep A.14 © CiA 2005 – All rights reserved

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiAIn 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 parameterThe 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 devices7.2.1 GeneralThe "safe state" of a device is not a CANopen communication state and falls not in the scope of thisframework.7.2.2 Pre-operationalIn 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 OperationalIn 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 StoppedBy 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 COBsTable 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 objectsINITIALISING PRE-OPERATIONAL OPERATIONAL STOPPEDPDO AllowedSDO Allowed Allowed 1SRDO AllowedSynchronization object Allowed AllowedTime stamp object Allowed AllowedEmergency object Allowed AllowedBoot-up object AllowedNMT object Allowed Allowed Allowed1 Writing to a safety object in the NMT state operational shall lead to an abort message (abortcode: 0800 0022 h ). Reading of a safety entry in the NMT state operational is allowed.© CiA 2005 – All rights reserved 15

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA8 Pre-defined connection setIn 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 predefinedCAN-ID assigned for SRDOs.Table 3: Broadcast objects of the pre-defined connection setObject Function code Resulting CAN-IDsGFC 0000 b 1 (001 h )ObjectTable 4: Peer-to-peer objects of the pre-defined connection setFunction Resulting CAN-IDscode Normal data Complement dataCommunicationparameters at indexChanneldirectionSRDO(node-ID 1 to 32)SRDO(node-ID 33 to 64)(1)0010 b257 d to 319 d(1)(101 h to 13F h )0010 b321 d to 383 d(1)(141 h to 17F h )Every second CAN-ID is used.258 d to 320 d(1)(102 h to 140 h )322 d to 384 d(1)(142 h to 180 h )1301 h to 1340 h tx1301 h to 1340 h rx16 © CiA 2005 – All rights reserved

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA9 Object dictionary9.1 Complex data type9.1.1 SRDO communication parameter recordIndex Sub-Index Description Data type0026 h 00 h Highest sub-index supported UNSIGNED801 h Information direction UNSIGNED802 h Refresh-time/SCT UNSIGNED1603 h SRVT UNSIGNED804 h Transmission type UNSIGNED805 h COB-ID 1 UNSIGNED3206 h COB-ID 2 UNSIGNED329.2 Object dictionary specifications9.2.1 Object 1300 h : Global fail-safe command parameterVALUE DEFINITION00 h : GFC is not valid01 h : GFC is valid02 h to FF h : reservedOBJECT DESCRIPTIONINDEXNameObject codeData typeCategory1300 hGlobal failsafe command parameterVARUNSIGNED8OptionalENTRY DESCRIPTIONAccessPDO mappingValue rangeDefault valuerwNoSee value definition00 h9.2.2 Object 1301 h to 1340 h : SRDO communication parameterThese objects shall contain the communication parameters for the SRDOs the device is able to receiveor to transmit. The type of the SRDO communication parameter (26 h ) is described in 9.1.1.The sub-index 00 h shall contain the number of highest entry within the communication record.At sub-index 01 h 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-© CiA 2005 – All rights reserved 17

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiASub-indexDescriptionEntry categoryAccessPDO mappingValue rangeDefault value03 hnot used (if information direction is tx)SVT (if information direction is rx)Conditional (if information direction is rx)rw (only in NMT state pre-operational)NoUNSIGNED1620 dSub-indexDescriptionEntry categoryAccessPDO mappingValue rangeDefault value04 hTransmission typeMandatoryroNo254 d254 dSub-index05 hDescription COB-ID 1Entry category MandatoryAccessrw (only in NMT state pre-operational)PDO mapping NoValue rangeOdd values only: 257 d to 383 dDefault value 1301 h : 0000 00FF h + (2 x node-ID)1302 h to 1340 h : manufacturer-specificSub-index06 hDescription COB-ID 2Entry category MandatoryAccessrw (only in NMT state pre-operational)PDO mapping NoValue rangeEven values only: 258 d to 384 dDefault value 1301 h : 0000 0100 h + (2 x node-ID)1302 h to 1340 h : manufacturer-specific20 © CiA 2005 – All rights reserved

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA9.2.3 Object 1381 h to 13C0 h : SRDO mapping parameterThese 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-index00 h 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 correspondingSRDO. The sub-indices from 01 h 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 DEFINITIONSub-index 00 h :00 h : mapping not valid02 h , 04 h to 80 h (only even values): mapping valid01 h , 03 h to 7F h (only odd values): reservedSub-index 01 h to 80 h :See PDO mapping parameters in /CiA301/.OBJECT DESCRIPTIONINDEXNameObject codeData typeCategory1381 h to 13C0 hSRDO mapping parameterARRAYUNSIGNED32Mandatory for each supported SRDOENTRY DESCRIPTIONSub-indexDescriptionEntry categoryAccessPDO mappingValue rangeDefault value00 hHighest sub-index supportedMandatoryro or rw (only in NMT state preoperational,and if variable mapping issupported)NoSee value definition(Device profile dependent)© CiA 2005 – All rights reserved 21

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiASub-indexDescriptionEntry categoryAccessPDO mappingValue rangeDefault value01 h , 03 h , 05 h to 7F h (only odd indices)SRDO mapping for the n-th applicationobject to be mapped (data not inverted)Conditional; depends on number of objectsto be mappedrwNoUNSIGNED32(Device profile dependent)Sub-indexDescriptionEntry categoryAccessPDO mappingValue rangeDefault value02 h , 04 h , 06 h to 80 h (only even indices)SRDO mapping for the n-th applicationobject to be mapped (data inverted)Conditional; depends on number of objectsto be mappedrwNoUNSIGNED32(Device profile dependent)9.2.4 Object 13FE h : Configuration validThis 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 (00 h ). Ifthe configuration is finished, the user writes the “valid” value to this object.VALUE DEFINITIONA5 h : Configuration validAll other values shall indicate an invalid configuration.OBJECT DESCRIPTIONINDEXNameObject codeData typeCategory13FE hConfiguration validVARUNSIGNED8Mandatory22 © CiA 2005 – All rights reserved

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiAENTRY DESCRIPTIONAccessPDO mappingValue rangeDefault valuerw (only in NMT state pre-operational)NoSee value definition00 h9.2.5 Object 13FF h : Safety configuration checksumVALUE DEFINITIONThis array shall provide the CRC for each SRDO individually.The generator polynomial shall be: G(x) = X 16 +x 12 +x 5 +1The order for data, which are checked by the CRC, shall be as follows:SRDO communication parametera) Information direction 1 byte = a 7 ...a 0b) Refresh time or SCT 2 byte = b 15 ...b 0c) SRVT 1 byte = c 7 ...c 0d) COB-ID 1 4 byte = d 31 ...d 0e) COB-ID 2 4 byte = e 31 ...e 0SRDO mapping parameterf) Sub-index 00 h 1 byte (Number of mapped application objects in SRDO) = f 7 ...f 0g 1 ) Sub-index 1 byte (SRDO mapping for the n th application object to be mapped) = g 1 7...g 1 0h 1 ) Mapping data 4 byte (2 byte index, 1 byte sub-index, 1 byte data length) = h 1 31...h 1 0tog 128 ) Sub-index 1 byte (SRDO mapping for the n th application object to be mapped) = g 128 7...g 128 0h 128 ) Mapping data 4 byte (2 byte index, 1 byte Sub-index, 1 byte data length) = h 128 31...h 128 0D(x) = x n + ...........+x 0D(x) = a 7 +...+a 0 +b 7 +...+b 0 +b 15 +...+b 8 +c 7 +...+c 0 +d 7 +...+d 0 +d 15 +...+d 8 +d 23 +...+d 16 +d 31 +...+d 24 +… etc.The CRC shall start with the value 0000 h .OBJECT DESCRIPTIONINDEXNameObject codeData typeCategory13FF hSafety configuration checksumARRAYUNSIGNED16Mandatory© CiA 2005 – All rights reserved 23

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA10 Annex A (informative)10.1 Hardware architectureIn 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 redundantobject dictionaries.32231CAN132231: CAN transceiver 2: CAN controller 3: Micro-controllerFigure 7: C-model for safety-relevant communication networks compliant to SIL 2 andSIL 3 /IEC61508/ or AK 4 and AK 6 /DIN80110.2 Configuration mechanismconfiguration toolsafety devicewrite all safety-relevant parameter incl.checksummsread back all safety-relevant parameterincl. checksumsconfiguration acknowledgedFigure 8: Principle of a safe configurationAll 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/.© CiA 2005 – All rights reserved 25

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA10.3 Mathematical analysis of CANopen safetyThe worst case residual error probability of the CAN protocol isP st−Re= 710 ⋅ ≈110⋅9 −8 /CHAR/For model C /FAET/ sending the same data twice the result isThe residual error rate per hour is2P = P RestΛ≡3600 ⋅P⋅ν⋅( m−1)⋅100ν: safety relevant messages per secondm: number of safety relevant devices = max. 64P: residual error probabilityThe 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

DS 304 V1.0.1 CANopen framework for safety-relevant communication CiA11 Annex B (informative)11.1 Overview on objects for safety communicationTable 5: Safety communication objectsIndex Object Name Type Acc. 1 M/O1300 h VAR GFC parameter UNSIGNED8 rw OSRDO communication parameter1301 h RECORD 1 st SRDO parameter SRDO parameter (26 h ) rw M1302 h RECORD 2 nd SRDO parameter SRDO parameter (26 h ) rw M/O*::::: ::::: ::::: ::::: ::::: :::::1340 h RECORD 64 th SRDO parameter SRDO parameter (26 h ) rw M/O*1341 h reserved::::: :::::1380 h reservedSRDO mapping parameter1381 h ARRAY 1 st SRDO mapping UNSIGNED32 rw M1382 h ARRAY 2 nd SRDO mapping UNSIGNED32 rw M/O*::::: ::::: ::::: ::::: ::::: :::::13C0 h ARRAY 64 th SRDO mapping UNSIGNED32 rw M/O*13C1 hreserved::::: :::::13FD hreserved13FE h VAR Configuration valid UNSIGNED 8 rw M13FF h ARRAY Safety configuration checksum UNSIGNED16 ro M1 Access 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.© CiA 2005 – All rights reserved 27