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
I/O signals
CAN bus
Server SDOs
Client SDOs
Tx PDOs
Rx PDOs
NMT, SYNC,
EMCY, Time
stamp
ESA – UNCLASIFIED – For official use
Logical
addressing
Scheme for
Accessing of
communication
and device
parameters,
data and
functions
Device
functions
Process
CANopen Communication Models
Producer/consumer
Client/server
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
Vendor
Specific
EDS
Profile(s)
Specifies the process
data variables a node
knows and the default
configuration and
communication settings
Stores
configuration
parameters of a
specific node
ESA – UNCLASIFIED – For official use
Device
EDS
Device
Config.
File
(DCF)
Defines the format of
an Object Dictionary
that may apply to
multiple nodes of that
type
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
(40.2055)
• 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
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?
Functional
DVS
Comms
DAS
Existing
1451 device
ESA – UNCLASIFIED – For official use
SPA
X-TEDS
1451
TEDS
SpaceWire
CAN
EDS
SOIS
EDS
Milbus
CANBus
others