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