Image Processing Reference
In-Depth Information
15.6 CANopen
In order to reduce the efforts involved in designing and implementing automation and networked
embedded systems, a number of higher-level application protocols have been defined in the past few
years, which rely on the CAN data-link layer to carry out actual message transfers among the nodes (it
is worth remembering that almost all functions of the CAN data-link layer are implemented directly
in hardware in the current CAN controllers, and this provides a very good degree of efficiency and
reliability for data exchanges). he main aim of such protocols is to provide a usable and well-defined
set of service primitives, which can be used to interact with embedded devices in a standardized way.
Reduced design and development costs are easily achieved thanks to standardization.
At present, several solutions are available, such as, for instance, CANopen [EN] for embedded
control systems, DeviceNet [EN] for factory automation, J [J] for trucks and other vehicles
and so on. Many of them define an abstract model to describe the behavior of devices. his enables
interoperability and interchangeability among devices coming from different manufacturers: in fact,
aslongasadeviceconformstoagivenproile,itcanbeusedinplaceofanyotherdevice(evenofa
different brand) that complies to the same profile.
In the following, the CANopen protocol will be described, highlighting in particular its use in
networked embedded system.
15.6.1 CANopen Basics
CANopen is a CAN-based application layer protocol with highly flexible configuration capabili-
ties that was developed explicitly for embedded systems. It unburdens the developer from dealing
with CAN-specific details, such as bit-timing and implementation-specific functions. Moreover, it
provides standardized communication objects (COBs) for real-time and configuration data as well
as network management (NMT).
CANopen was initially conceived to rely on communication services provided by the CAL
[DSX]. However, current specifications [DS] no longer refer explicitly to CAL; instead, the rel-
evant services have been included directly in the CANopen documents. CANopen is also known as
the international standard EN - [EN]. he set of CANopen specifications includes the appli-
cation layer, the communication profile as well as several application, device, and interface profiles.
These documents are developed and maintained by the CiA member group.
At present, CANopen networks are used in a very broad range of application fields, such as, for
example, off-road and rail vehicles, maritime electronics, machine control, medical devices, building
automation as well as power generation.
In CANopen, information is exchanged by means of COBs. A number of different COBs are
foreseen, which are aimed at different functions:
•
Process data objects
(PDOs), used for real-time exchanges such as, for example, measure-
ments read from sensors and commanded values sent to actuators for controlling the
physical system
•
Service data objects
(SDOs), used for nonreal-time communications, e.g., device param-
eterization and diagnostics
•
Emergency
(EMCY)
objects
, used by devices to notify the occurrence of error conditions
•
Synchronization
(SYNC)
objects
, used to achieve synchronized and coordinate operations
inthesystem,andsoon
Even though, in principle, every CAN node is a master (at least from the point of view of the MAC
mechanism) CANopen defines a master/slave scheme in order to simplify NMT. In particular, each
device is identified by means of a unique -bit address, which lies in the range from to . So as to
