iCC 2008 CAN in Automation

CAN/CANopen to EtherCAT Gateways:

Requirements and Solutions
Martin Rostan, Beckhoff Automation GmbH
Mirko Tischer, Vector Informatik GmbH

CAN is the dominating network technology in automotive applications. Enhanced by

the higher layer protocol CANopen it is a well established Fieldbus technology, im-
plemented in a large variety of devices and systems. EtherCAT is an Industrial
Ethernet technology which provides high end communication performance, flexible
topology options and low system costs. In many applications, the distinct advantages
of both networks have to be combined. With CAN/CANopen to EtherCAT gateways,
this can be done efficiently, if certain design rules are followed.

This paper discusses the requirements on such gateways from the application and
from the device vendor point of view. Besides CANopen gateways, the special re-
quirements of generic CAN to EtherCAT gateways as used e.g. in automotive test bed
applications are considered. It is shown that CANopen protocols can be used to con-
figure the gateway also from the EtherCAT side. Example implementations and their
representation in software tools are shown as well as application examples. It is also
shown that such gateways enable a smooth migration path from CANopen devices
towards Industrial Ethernet.

EtherCAT Overview EtherCAT communication cycle times are

0.1 – 1ms, the network extension, number
EtherCAT was originally developed by of nodes and the topology options are al-
Beckhoff and introduced in 2003. Mean- most unlimited. A more detailed introduc-
while the technology is an IEC standard tion into EtherCAT and its usage of
[2-4], and supported by the EtherCAT CANopen protocols can be found in [1].
Technology Group [7], an international
user and vendor organization with over
650 member companies from 37 countries EtherCAT masters do neither require any
(as of Dec 2007). EtherCAT utilizes special hardware nor a dedicated commu-
CANopen [6] communication protocols nication processor and can be imple-
such as SDO and PDO and also supports mented in software on any control hard-
CANopen device profiles. In IEC 61800-7- ware that provides an Ethernet port. Eth-
301 [5] the mapping of the CANopen servo erCAT Slave Controller chips are available
drive profile CiA402 onto EtherCAT is from several manufacturers.
standardized. EtherCAT employs the func-
tional principle of “processing on the fly”: Gateways
unlike other Industrial Ethernet technolo-
gies, the Ethernet frame or packet is no CAN / Ethernet gateways have been dis-
longer received, then interpreted and cussed for quite some time (e.g. in [8, 9,
process data then copied at every device. 10, 11]). The system architecture behind
The EtherCAT slave devices read the data these approaches is hierarchical (figure 1):
addressed to them while the frame passes field devices networked locally with CAN
through the node. Similarly, input data is or CANopen fieldbus systems are con-
inserted while the telegram passes nected with the Ethernet based control or
through. This leads to superior bandwidth management level via gateways. This ini-
utilization and thus to short cycle times – tial approach avoids complex timing re-
EtherCAT is considered to be the fastest quirements both for Ethernet and the
Industrial Ethernet technology – while al- gateway, since all real time control loops
lowing for flexible topology options and low are closed locally within the CAN environ-
implementation and system costs. Typical ment. The Ethernet connection is used for

02-1
iCC 2008 CAN in Automation

non real time tasks such as data acquisi- CANopen to EtherCAT gateway
tion, remote configuration and diagnosis.
CANopen networks are used in a very
broad range of application fields such as
machine control, medical devices, off-road
and rail vehicles, maritime electronics,
building automation as well as power gen-
eration. When considering CANopen to
EtherCAT gateways, the following
CANopen device classification may help to
sort the applications:
Fieldbus devices such as I/O-blocks,
drives, sensors, actuators, valves etc.
which typically are also available with
other common fieldbus interfaces. Here
the CANopen to EtherCAT gateway pre-
Figure 1: Hierarchical Control Architecture
dominantly serves the purpose of integrat-
The system architecture and thus the re- ing such CANopen devices which are not
quirements for gateways change with the yet available with EtherCAT interface.
arrival of real time Ethernet technologies Embedded devices such as small em-
such as EtherCAT (see figure 2). Now the bedded controllers, custom made sensor
Ethernet based system does not only interfaces, specialized hardware compo-
reach the real time characteristics (such nents for machine control used in conjunc-
as reaction and cycle time) of the CAN tion with general purpose fieldbus devices.
based network, but exceeds these per- For special purpose control subsystems –
formance parameters substantially. At the often they include the machine builders
same time EtherCAT overcomes one of dedicated process know how – CANopen
the main constraints of CAN: limited net- so far has been the network of choice,
work extension particular at high baud since the CAN hardware is simple to inte-
rates. grate and CANopen provides the interop-
And since EtherCAT interfaces can also erability. While EtherCAT has similar fea-
be implemented at low costs, the applica- tures and will thus further expand in this
tion range of the Ethernet technology is environment, gateways here are very use-
enhanced towards and beyond the field- ful since one tries to avoid the re-design of
bus level, reaching the embedded system such special hardware if possible even if
level. CANopen is replaced by EtherCAT as
main control network.
Deeply embedded devices in vehicles,
medical devices etc, where no standard
“off the shelf” devices can be used. In con-
junction with such systems gateways are
typically used to enable the classical hier-
archical architecture: local, widely inde-
pendent networks have to be connected to
supervisory or management levels
equipped with EtherCAT. However, Eth-
Figure 2: Flat Control Architecture erCAT is already used as backplane bus
systems and hence in deeply embedded
The real time domain is no longer con- applications. And since EtherCAT slave
cluded in the CAN network, but spans controllers are also available with ex-
across the network technologies. The re- tended temperature ranges, this network is
quirements on the gateways change ac- also beginning to even enter deeply em-
cordingly, since CAN networks are now bedded systems with rigid environmental
used as local extensions of the real time requirements such as mobile machines.
EtherCAT system.

02-2
iCC 2008 CAN in Automation

The gateway timing requirements in field-

bus and embedded device scenarios typi-
cally are more demanding than in applica-
tions where deeply embedded systems
have to be connected. Whenever the long
term goal is to move from CANopen to
EtherCAT, gateways provide a smooth
migration path.

CAN to EtherCAT gateway

Most in-vehicle applications do not use

Picture 2: BMW Research + Innovation Center
CANopen, but proprietary protocols on top (FIZ) in Munich, Germany (Photo: BMW AG).
of the CAN physical and data link layer.
Generic, non-standardized CAN protocols Gateway design considerations
are also used in many deeply embedded
applications. Unlike with CANopen, higher When designing such a gateway the spe-
layer protocol information may also be cific requirements of coupling EtherCAT
encoded in the data length code or identi- and CAN have to be taken into account, in
fier field of the CAN frame, so forwarding order to maximize performance, achieve
the CAN payload data through the gate- the best possible synchronization and thus
way may not be sufficient. In addition, the prepare the gateway for the widest range
CAN network timing itself may contain of applications.
valuable information (such as occurrence
of certain signals), so that additional timing Data throughput
information may have to be provided, too.
The data throughput of EtherCAT and
CAN is different by orders of magnitude.
While CAN transports up to 8 bytes per
frame at a maximum of 1 MBit/s (60
Kbytes/s), EtherCAT transmits up to 1486
bytes per frame at 100 MBit/s (10.000
Kbytes/s with the possibility of a future
extension to Gbit Ethernet). EtherCAT can
transport the bus traffic of several CAN
networks without generating an overload
situation, if several CAN frames per Eth-
erCAT frame are transmitted.

Picture 1: Engine Test Bed (Photo: BMW AG)

Cyclic vs. Event driven communication
CAN to EtherCAT gateways are used in
automotive test bed applications, e.g. at Another big difference between the sys-
the BMW Research and Innovation Center tems is how the transmission of the mes-
in Munich, Germany (see picture 1+2). sages is triggered. With EtherCAT the
EtherCAT was chosen as automation net- frame is always sent by the master. The
work for the new engine test center that EtherCAT master typically operates cycli-
starts operations later this year, and some cally and therefore the communication
testing equipment is connected via Gate- typically is directly linked with this cycle.
ways. The ability to integrate remote CAN On the CAN side communication is often
interfaces without jeopardizing the per- event driven. Whenever data has to be
formance on either side was a crucial cri- transmitted, the device initiates the send-
terion for the network selection in this ap- ing of a frame. The differences in data
plication. Connecting in-vehicle CAN net- throughput and in message triggering be-
works used for engine control via Gate- tween the systems in any case require
ways is also possible. buffer mechanisms in the gateway.
02-3
iCC 2008 CAN in Automation

EtherCAT master
EtherCAT/CAN gateway

evaluate TX
input message
data buffer

CAN
message CAN
handler
EtherCAT frame
create RX ECU 1 ECU n
output message
data buffer

Figure 3: Gateway System Structure

The throughput of a gateway concept Table 1: Relation between EtherCAT-Cycle and
based on figure 3 is determined by the buffer size for CAN Frame Reception
following parameters:
• Size of the message buffer in the EtherCAT Minimal required Buffer
Cycle (µs) Size (CAN-messages)
gateway
• Amount of CAN-Data transmitted 1000 18
within one EtherCAT frame 2000 36
• Cycle time of the EtherCAT Com- 4000 72
munication

The gateway has to be designed, inte- While transmitting the data of the received
grated and configured in such a way that CAN frames over EtherCAT the reception
no CAN frames are lost. For the reception time of the CAN frame is lost. If this timing
of the CAN frames this means that the information is valuable – in the general
message buffer inside the gateway has to case it is – the Gateway has to provide a
be large enough to store all CAN frames reception time stamp for each received
received within one EtherCAT cycle. CAN frame.
For timing considerations we assume the The send throughput of course also de-
following boundary conditions. The CAN pends of the chosen buffer size. The CAN
bus is operated at 1 Mbit/s. The transmis- data first has to be extracted from the Eth-
sion of a CAN message with one byte erCAT frame. The associated CAN frame
takes about 55µs. If one assumes an Eth- can only be sent once the CAN bus is
erCAT cycle time of 1000µs, in worst case available (bus idle). Therefore a send
18 CAN frames can be received within this buffer is also required. For emptying this
period of time. So the receive buffer at buffer (the CAN send process) the gate-
least has to be able to handle this number way has to provide means to avoid mes-
of CAN frames. sage bursts and thus high bus loads. This
is in particular important at higher CAN bit
Furthermore, within one EtherCAT Frame
rates, since the message burst may ex-
the content of at least of 18 CAN frames
ceed the frame handling capabilities (inter-
has to be transmitted to the EtherCAT
rupt load) of the connected CAN devices.
master, since otherwise a
buffer overflow may occur if
the CAN busload is close to
100% over several cycles.
Accordingly, Table 1 shows
the buffer size requirements
for CAN with 1 Mbit/s and messages with
Figure 4: cyclic CAN frame burst
one data byte.
A burst as shown in figure 4 would occur
in each EtherCAT cycle if the EtherCAT

02-4
iCC 2008 CAN in Automation

frame transports the data of more than mented inside the gateway. The gateway
one CAN frame. Since with longer Ether- then translates the signals into CAN
CAT cycles this behavior is more likely to frames respective interprets received CAN
become problematic, the gateway should frames based on this configuration. Fur-
be able to insert gaps in between the CAN thermore, for data consistency reasons all
frames that it sends. data received within one CAN frame has
to be transported within one EtherCAT
frame, which can be difficult to ensure with
this methodology if the CAN higher layer
protocol is unknown. So while this ap-
proach is simple from the application point
of view, it only works if the CAN protocol
stack is well defined and implemented
inside the Gateway.
Figure 5: Gaps inserted in the send frame se-
quence Therefore the message based approach is
preferable for generic CAN / EtherCAT
In case such gaps are inserted in between gateways while the process data or signal
the Send- Frames it may happen that not oriented approach suits the requirements
all CAN frames can be sent within one in CANopen to EtherCAT gateways better.
EtherCAT cycle. This may also occur if the
CAN bus is busy with higher priority
frames so that the gateways does not get
sufficient bus access with CAN frames of
lower priority. Therefore in send direction
there has to be a flow control mechanism
in order to ensure that there is no buffer
overflow with associated send frame loss.

Figure 7: Message Gateway Approach

Process Data-Gateway vs. Message-Gateway
Other than with the process data-gateway
When implementing such a gateway there entire CAN frames are transported within
are two main approaches: a process data- one EtherCAT frame (see figure 7). Inside
gateway only transmits the payload (proc- the EtherCAT frame there is a data con-
ess data or signals) of the CAN frame via tainer in which the CAN frames and the
EtherCAT. associated management data (such as
number of frames within the container,
status info, flow control data etc.) is lo-
cated.
Since each EtherCAT frame may contain
different CAN messages, the data cannot
be made available directly as process im-
age. Instead the master has to interpret
the data first in order to copy it into the
process image. While the gateway be-
Figure 6: Signal Gateway Approach comes much simpler, the effort is moved
into the EtherCAT master or in the applica-
The advantage of this approach is, that the tion layer of the master.
EtherCAT master can directly provide the
The message gateway approach is much
signals in form of a process image (see
more flexible: without modifying the gate-
figure 6). The disadvantage is that the
way, any CAN based protocol can be
process data description has to be config-
used.
ured in the gateway itself. In case of
CANopen, where the process data alloca-
tion and configuration is part of the stan-
dard (PDO mapping) this can be imple-

02-5
iCC 2008 CAN in Automation

Configuration: Modular Device Profile Implementation Example

The gateway either provides the CAN Both gateway approaches (CAN and
frame queues towards EtherCAT CANopen to EtherCAT) have been
(message gateway, object dictionary implemented e.g. in the Beckhoff
layout see table 2) or represents a number EtherCAT Gateway terminal EL 6751 (see
of CANopen devices (process data picture 3). Its CANopen functionality
gateway, see table 3). It is typically corresponds to the Beckhoff PCI master
configured from the EtherCAT side using card FC5101. It is either available as
the CoE (CANopen over EtherCAT) CANopen master or slave device. The
protocol with the modular device profile master version also supports generic CAN
approach. This versatile profiling model together with message timestamping,
was developed by the EtherCAT flexible bit timing, extended message
Technology Group. It allows one to queues and filter functionality.
configure devices which have a dynamic
parameter set (object dictionary) by writing
the expected module configuration at boot-
up. Alternatively it can be generated
automatically after power-on.
Furthermore, the modular device profile
gives transparent process data and
parameter access to underlying modules
such as the devices connected via
gateway. Details regarding the modular
device profile can be found in [12].
Table 2: Object Dictionary Layout for CAN to
EtherCAT Gateway (message gateway)

Index (hex) Object Dictionary Area

0x0000-x0FFF Data Type Area
0x1000-x1FFF Communication Area
Input Area (CAN RX message Picture 3: CAN/CANopen to EtherCAT Gate-
0x6000-x6FFF
queue) way Terminal with I/O EtherCAT Terminals.
Output Area (CAN TX message Performance Considerations
0x7000-x7FFF
queue)
Configuration Area (configuration of A CAN/CANopen to EtherCAT gateway
0x8000-x8FFF
the CAN Interface)
can be considered to be a PCI
0xF000-xFFFF Device Area CAN/CANopen card which was removed
from the PCI bus and placed remotely
outside of the PC chassis. Due to
Table 3: Object Dictionary Layout for CANopen EtherCATs performance the update rates
to EtherCAT Gateway (process data gateway) and bandwidth of both variants is
comparable, typically the EtherCAT
Index (hex) Object Dictionary Area update rate is even better. Therefore the
0x0000-x0FFF Data Type Area gateway connection does not provide a
0x1000-x1FFF Communication Area bottleneck any more, EtherCAT allows one
Input Area (TxPDOs of the to connect to a CAN/CANopen network
0x6000-x6FFF without performance restictions.
CANopen slaves)
Output Area (RxPDOs of the
0x7000-x7FFF
CANopen slaves)
Summary
Configuration Area (Expected con-
0x8000-x8FFF
figuration of the CANopen slaves) In a growing number of applications CAN
0x9000-x9FFF
Information Area (Detected con- and CANopen networks have to be
figuration of the CANopen slaves) interfaced to Industrial Ethernet networks
0xF000-xFFFF Device Area such as EtherCAT. The required gateways
02-6
iCC 2008 CAN in Automation

face challenges regarding transparency, [8] H. Ekiz, A. Kutlu, M.D. Baba, E.T. Powner:
performance, simple configuration, costs “Design and Implementation of a
and of course standardized uniform CAN/Ethernet Bridge”, Proceedings of the 3rd
software interfaces. It makes sense to International CAN Conference, pp. 11/17-
11/26, 1-2 October 1996, Paris, France
distinguish between the CAN and
CANopen gateway requirements, since [9] H. Ekiz, A. Kutlu, M.D. Baba, E.T. Powner,
"Performance Analysis of a CAN / Ethernet
they lead to different architectural
Bridge", IEEE SICON, 97 Conference, pp. 71-
approaches. A generic CAN gateway, for
85, 14-17 April 1997, Singapore
which the CAN higher layer protocol is a
[10] CiA309 draft standard series: “Interfacing
priori unknown, a message based
CANopen with TCP/IP”, CAN in Automation
approach fits best. For a CANopen e.V.
gateway, one can implement the protocol
[11] H. Zeltwanger: “Embedded and deeply em-
stack in the gateway and provide a
bedded networks for machine internal con-
process image interface on EtherCAT. trols”, Proceedings of the SPS/IPC/Drives
Equipped with EtherCAT such gateways Congress, pp. 443-449, 2003, Nuremberg.
are no bottleneck but provide a full [12] ETG.5001: “Modular Device Profile Specifi-
performance connection to CAN or cation”, EtherCAT Technology Group
CANopen networks. Hence they also build
a smooth migration path from CANopen to
EtherCAT.
Martin Rostan
Beckhoff Automation GmbH
References
Ostendstr. 196, D- 90482 Nürnberg
[1] M. Rostan: “CANopen over EtherCAT – tak- Phone +49 (911) 54056-11
ing a CAN technology to the next level”, Pro- Fax +49 (911) 54056-29
ceedings of the 11th International CAN Con- [email protected]
ference, pp. 12/1-12/8, 8-9 March 2005, www.beckhoff.com
Rome, Italy
[2] IEC 61158-2 (Ed.4.0), Industrial communica-
tion networks - Fieldbus specifications - Part
Mirko Tischer
2: Physical layer specification and service Vector Informatik GmbH
definition Ingersheimer Str. 24, D-70499 Stuttgart
[3] IEC 61158-3/4/5/6-12 (Ed.1.0), Industrial Phone +49 (711) 80670-0
communication networks - Fieldbus specifica- Fax +49 (711) 80670-111
tions - Part 3-12: Data-link layer service defi- [email protected]
nition - Part 4-12: Data-link layer protocol www.vector-informatik.com
specification - Part 5-12: Application layer
service definition - Part 6-12: Application
layer protocol specification -Type 12 elements
(EtherCAT)
[4] IEC 61784-2 (Ed.1.0), Industrial communica-
tion networks - Profiles - Part 2: Additional
fieldbus profiles for real-time networks based
on ISO/IEC 8802-3 I
[5] IEC 61800-7-301/304 (Ed.1.0), Adjustable
speed electrical power drive systems - Part 7-
301: Generic interface and use of profiles for
power drive systems - Mapping of profile type
1 to network technologies - Part 7-304: Ge-
neric interface and use of profiles for power
drive systems - Mapping of profile type 4 to
network technologies
[6] EN 50325-4: Industrial communications sub-
system based on ISO 11898 (CAN) for con-
troller-device interfaces. Part 4: CANopen.
[7] EtherCAT Technology Group website,
http://www.ethercat.org

02-7