ESA – UNCLASIFIED – For official use Introduction to CANopen

ESA – UNCLASIFIED – For official use CANopen Introduction The CANBUS defines only the layers 1 and 2 (ISO11898); in practice these are completely handled by the CAN hardware However, a high level protocol is necessary in order to define how the CAN message frame's 11-bit identifier and 8 data bytes are used. Interoperability and interchangeability of devices of different manufactures requires a standardized application layer and ‘profiles’. –The application layer provides a set of services and protocols useful to every device on the network –The communication profile provides the means to configure devices and communication data and defines how data is communicated between devices –Device profiles add device-specific behaviour for (classes of) devices (e.g. digital I/O, analog I/O, motion controllers, encoders, etc.).

ESA – UNCLASIFIED – For official use CANopen Protocol Layer Interactions The protocol layer interactions describe the communication on the different layers. On the CANopen application layer the devices exchanges communication and application objects. All these objects are accessible via a 16-bit index and ´8-bit sub-index. These communication objects (COB) are mapped to one or more CAN frames with pre-defined or configured Identifiers. The CAN physical layer specifies the bit level including the bit-timing.

ESA – UNCLASIFIED – For official use CANopen Device Model A CANopen device can be divided into three parts: –communication interface and protocol software –object dictionary –process interface and application program The communication interface and protocol software provide services to transmit and to receive communication objects over the bus. The object dictionary describes all data types, communication objects and application objects used in this device. It is the interface to the application software. Communication Interface Object Dictionary Application Process Server SDOs Client SDOs Tx PDOs Rx PDOs NMT, SYNC, EMCY, Time stamp CAN bus Logical addressing Scheme for Accessing of communication and device parameters, data and functions Device functions I/O signals Process

ESA – UNCLASIFIED – For official use CANopen Communication Models Client/server Producer/consumer Master/slave

ESA – UNCLASIFIED – For official use CANopen Communication Protocols CANopen communication objects transmitted via the CAN network are described by the services and protocols. They are classified as follows: –The real-time data transfer is performed by the Process Data Objects (PDOs) protocol. –With Service Data Objects (SDOs) protocols the read and write access to entries of a device object dictionary is provided. –Special Function Object protocols provide application-specific network synchronization, time stamping and emergency message transmissions. –The Network Management (NMT) protocols provide services for network initialization, error control and device status control.

ESA – UNCLASIFIED – For official use Process data object (PDO) Process data objects are used for fast transmission of process data. A PDO can carry a payload of 8 bytes, which is the maximum payload of a CAN frame. The transmission of a PDO uses the consumer producer model of CAN extended by synchronous transfers. The synchronous transfer of PDOs relies on the transfer of SYNC messages on the CAN bus. A PDO is sent in cyclical mode after a configurable number (1 to 240) of received SYNC messages. It is also possible to wait for the availability of data from the application process and send a PDO after the next received SYNC message. This is called acyclical synchronous transfer.

ESA – UNCLASIFIED – For official use Service data object (SDO) Service data objects are intended for transmission of parameters. SDOs provide access to the object dictionary of remote devices. An SDO has no length restriction. If the payload does not fit into the CAN frame, it will be split over several CAN frames. Each SDO is acknowledged. SDO communication uses a peer-to-peer communication with one peer acting as server and the other acting a client.

ESA – UNCLASIFIED – For official use Network management objects (NMT) The network management objects (NMT) change the state, or monitor the status, of a CANopen device. A NMT message is a message with CAN identifier 0. This gives the NMT messages the highest possible priority. The NMT message always consists of two bytes payload in the CAN frame. The second byte contains the node ID of the addressed node. It is possible to address all devices with one NMT message with the reserved node ID 0. The first byte encodes the NMT command. A CANopen device starts in the Initialization state after switching the power on. Then`the device performs its initialization. When the device has completed its initialization it issues a boot-up NMT object to notify the master. The heartbeat protocol for monitoring the device status is implemented with NMT objects.

ESA – UNCLASIFIED – For official use Special function objects (SYNC, EMCY, TIME) CANopen may have a SYNC producer to synchronize the actions of the CANopen nodes. A SYNC producer issues (periodically) the SYNC object. The SYNC object has the CAN identifier 128. This may introduce some jitter due to the priority of this message. A device internal error may trigger an emergency (EMCY) object. The reaction of the EMCY consumers depends on the application. The CANopen standard defines several emergency codes. The EMCY object is transmitted in a single CAN frame with eight bytes. A CAN frame with the CAN ID 256 with six bytes payload can be used to transmit the time of day to several CANopen nodes. This time stamp (TIME) object contains the daytime value in the Time-Of-Day data type. CANopen supports two methods of monitoring the status of devices (watchdog mechanisms). –A network manager may poll each device regularly in configurable time intervals. This is called node guarding. Node guarding is, however, bandwidth consuming. –Another mechanism is that each device regularly sends a heartbeat message. This saves bandwidth compared to the node guarding protocol.

ESA – UNCLASIFIED – For official use CANopen Profiles Device Profiles specify supported application objects, additional error codes, and default PDO mappings. There are mandatory objects, optional objects and manufacturer-specific objects. Device Profiles standardized by CiA use the Object Dictionary entries from 6000h to 9FFFh. CANopen Application Profiles describe a specific application including all devices and optionally some additional specifications of the physical layer. CANopen device and application profiles. Available profiles –CiA 401 I/O modules –CiA 402 Electric drives –CiA 404 Transducer –CiA 405 Programmable logic controllers –CiA 406 Encoders –CiA 408 Proportional valves and hydraulic transmission –CiA 410 Inclinometers –CiA 412 X-ray collimators –CiA 413 Truck gateways –CiA 414 Yarn-feeding units –CiA 415 Road construction machinery –CiA 416 Door control –CiA 417 Lift control systems –CiA 418 Battery modules –CiA 419 Battery chargers –CiA 420 Extruder downstream devices –CiA 422 Municipal vehicles –CiA 425 Medical diagnostic add-on modules

ESA – UNCLASIFIED – For official use CANopen Electronic Data Sheet (EDS)

ESA – UNCLASIFIED – For official use Internal Device Structure CANopen devices are logically structure in three parts –CAN interface –Device’s application –Object Dictionary Parameter list Provides access to the device configuration and process data It is accessed using the CANopen protocol stack

ESA – UNCLASIFIED – For official use Internal Device Structure CANopen devices are logically structure in three parts –CAN interface –Device’s application –Object Dictionary Parameter list Provides access to the device configuration and process data It is accessed using the CANopen protocol stack

ESA – UNCLASIFIED – For official use Internal Device Structure CANopen devices are logically structure in three parts –CAN interface –Device’s application –Object Dictionary Parameter list Provides access to the device configuration and process data It is accessed using the CANopen protocol stack

ESA – UNCLASIFIED – For official use CANopen Object Dictionary Heart of every CANopen device –It is present in every device It represents a grouping of objects accessible via the network in an ordered and pre-defined fashion –Each object is addressed using a 16-bit index and 8-bit subindex Object Dictionary is structured in several index range –1000h to 1FFFh → communication behaviour –2000h to 5FFFh → application behaviour (manufacturer specific) –6000h to 9FFFh → application behaviour (standardized profiles) it is possible to provide up to eight device/application profile implementations within one CANopen device –A000h to BFFFh → network variables and system variables

ESA – UNCLASIFIED – For official use CANopen Object Dictionary

ESA – UNCLASIFIED – For official use CANopen Object Dictionary Each node not only implements its object dictionary but also a server that handles read/write operations to its OD The way to access OD entries is using SDO transfers (client/server peer-to-peer communication)

ESA – UNCLASIFIED – For official use CANopen Object Dictionary Each node not only implements its object dictionary but also a server that handles read/write operations to its OD The way to access OD entries is using SDO transfers (client/server peer-to-peer communication)

ESA – UNCLASIFIED – For official use CANopen Object Dictionary Each node not only implements its object dictionary but also a server that handles read/write operations to its OD The way to access OD entries is using SDO transfers (client/server peer-to-peer communication)

ESA – UNCLASIFIED – For official use Electronic Data Sheet In the object dictionary the device designer indicates the supported device functionality by implementing the related objects The communication behaviour is adjusted in the appropriate objects in the index range 1xxxh Parameters and results required or generated by manufacturer specific device functions, can be indicated in the index range 2000h to 5FFFh In addition manufacturer specific status information and process data can be represented to the network in that index range. EDS is a “human readable” representation of the CANopen object dictionary –ASCII –XML

ESA – UNCLASIFIED – For official use EDS “architecture” EDS Profile(s) EDS Vendor Specific Device EDS Device Config. File (DCF) Stores configuration parameters of a specific node Defines the format of an Object Dictionary that may apply to multiple nodes of that type Specifies the process data variables a node knows and the default configuration and communication settings

ESA – UNCLASIFIED – For official use EDS Entries A 16-bit index is used to address all entries within the object dictionary. –In case of a simple variable this references the value of this variable directly. –In case of records and arrays however, the index addresses the whole data structure –For complex object dictionary entries such as arrays or records with multiple data fields the sub-index references fields within a data-structure pointed to by the main index Example: manufacture specific RS-232 interface –Defines an entry in index 6092h to define communication parameters for that module

ESA – UNCLASIFIED – For official use CANopen EDS Profiles Device Profiles specify supported application objects, additional error codes, and default PDO mappings. Device Profiles standardized by CiA use the Object Dictionary entries from 6000h to 9FFFh. Devices of different manufacturers can be accessed via the bus in exactly the same manner. In this way, a very high degree of vendor independence is achieved as the devices are interoperable and exchangeable. Therefore, CANopen is on one hand standardized, but on the other hand it is still open to a nearly unlimited field of applications. Available profiles –CiA 401 I/O modules –CiA 402 Electric drives –CiA 404 Transducer –CiA 405 Programmable logic controllers –CiA 406 Encoders –CiA 408 Proportional valves and hydraulic transmission –CiA 410 Inclinometers –CiA 412 X-ray collimators –CiA 413 Truck gateways –CiA 414 Yarn-feeding units –CiA 415 Road construction machinery –CiA 416 Door control –CiA 417 Lift control systems –CiA 418 Battery modules –CiA 419 Battery chargers –CiA 420 Extruder downstream devices –CiA 422 Municipal vehicles –CiA 425 Medical diagnostic add-on modules

ESA – UNCLASIFIED – For official use CANopen EDS Profiles (e.g. Transducer profile) DS404 defines transducers and close-loop controllers –Interfaces to sensors, actuators and PID-controllers Sensor data that are available after the A/D conversion are saved to object dictionary of the device –Parameters are configurable via SDO –Process data are written to the OD after scaling –Analog input values are storable in different formats (specific area in the OD) Floating integer (field value (FV): 6100h, process value (PV) 6130h) 16-bit integer (FV: 7100h, PV: 7130h) 24-bit integer (FV: 8100h, PV: 8130h) 32-bit integer (FV: 9100h, PV: 9130h) Up to 199 analog input channels –Process data of each channel sent using PDOs The profile also defines output channels –Allows close-loop controller

ESA – UNCLASIFIED – For official use CANopen EDS Profiles (e.g. Transducer profile)

ESA – UNCLASIFIED – For official use EDS Pressure Transducer Example JUMO CANtrans p Ceramic Pressure transmitter with CANopen output ( ) The pressure measurement is digitized and made available for further processing via the CANopen serial bus protocol (CAN slave). Several useful extra functions have been implemented through the DS 404 (Transducer profile) device profile. J_P_0101.eds

ESA – UNCLASIFIED – For official use SOIS EDS Discussion Since CANbus/CANopen will become an ECSS standard, ESA needs to ensure that the SOIS work is compatible One advantage of using CANopen is that it will force the use of EDS and thus suppliers/integrators will be obliged to provide them The CANopen EDS approach seems to cover both the communication and functional interface how can we fit this within SOIS and the use of other EDS definitions? So far we have assumed the use of xTEDS for functional interfaces and TEDS for the communication interface definitions – do we arrive at a SOIS definition that can serve everything? Alternatively, what will be ask the device manufactures to comply with? 1451 TEDS CAN EDS SPA X-TEDS SpaceWire Milbus CANBus others Functional DVS Comms DAS Existing 1451 device