canopen - datamicro · /cia301/ cia ds 301, canopen application layer and communication profile...

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]


© 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


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


© 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).


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



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



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



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



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



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.



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



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



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



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.



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.



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-



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



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


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



PDO mapping No

Value range UNSIGNED16

Default value 25d (if information direction is tx)

50d (if information direction is rx)



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)


PDO mapping No


Default value 20d

Sub-index 04h

Description Transmission type


Access ro

PDO mapping No

Value range 254d

Default value 254d

Sub-index 05h

Description COB-ID 1



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



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



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



Access ro or rw (only in NMT state pre-operational, and if variable mapping issupported)

PDO mapping No


Default value (Device profile dependent)



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



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



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



ENTRY DESCRIPTION


PDO mapping No


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



ENTRY DESCRIPTION

Sub-index 00h




PDO mapping No

Value range 00h to 40h

Default value 01h

Sub-index 01h

Description Checksum-1



PDO mapping No


Default value 0000h

Sub-index 02h


Entry category Mandatory for each additional supportedSRDO


PDO mapping No


Default value 0000h

to

Sub-index 40h


Entry category Conditional;

Mandatory for each additional supportedSRDO


PDO mapping No


Default value 0000h



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



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/!



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.

canopen - datamicro · /cia301/ cia ds 301, canopen application layer and communication profile...

Documents