CAN in Automation

Holger Zeltwanger spills the details on linking CANopen networks with gateways and bridges.

Most of the more complex control systems implement more than one network. Some of these systems are hierarchically organised, meaning that one of the networks is the top-level network and the others are sub-level networks. In other applications, the networks are non-hierarchically structured. Sometimes, the control systems use intermeshed networks; some parts are hierarchical and others are non-hierarchical. In all these kinds of network architectures, it is possible to use one single network technology (homogenous networks) or different network technologies (heterogeneous networks).

Bridges (homogenous network link) or gateways (heterogeneous network link) realise the connection between networks; these devices provide at least two network interfaces, some feature more than that.

In the past, several companies developed bridge and gateway devices for CAN-based networks. CAN-to-CAN devices, as well as gateways connecting Ethernet-based networks to CAN, are available from several manufacturers. However, they all use proprietary CANopen profiles. They are not standardised and therefore they could not be exchanged and substituted by devices from another manufacturer.

Modular control systems are able to provide bridge and gateway functionality. However, it is not possible for all applications to have a central unit that collects all the data and information. Additionally, some system designers require standalone bridge and gateway devices in order to extend the system without reprogramming the application master. These standalone bridges and gateways are price-sensitive. For many years, several companies have offered so-called dongle devices connecting CAN to USB, to printer interfaces (Centronics), and to serial links (RS-232, RS-485, etc). Besides the single CAN-to-USB gateways offered by several manufacturers, Sys Tec ( has launched a multi-channel USB/CAN gateway. Up to 16 independent CAN interfaces are implemented. One of the most implemented gateways is the RS-232-to-CAN connection. Most of them are generic, but there are also some specific ones. Embedded Systems Solutions ( has developed the CANgine FMS, a gateway that supports the FMS (Fleet Management System) on the CAN interface. The European truck manufacturers have standardised FMS. The specification is based on J1939 protocols and defines 13 CAN messages containing about 30 parameters.

Several companies have introduced gateways to Bluetooth and wireless local area network (WLAN). Wireless communication is becoming increasingly popular especially in vehicle diagnostics. Most of the passenger car manufacturers are going to introduce WLAN-based diagnostic interfaces substituting the currently used CAN-based diagnostic interfaces standardised within ISO. Of course, the diagnostic information (error codes, etc) will be adopted. Those CAN-to-Bluetooth and CAN-to-WLAN devices as offered for example by RM Michaelidis ( and others are used already in special vehicles. The CANbox by Sorcus ( provides two CAN interfaces and WLAN or Bluetooth connectivity as well as an Ethernet interface. It is designed for vehicle applications. All CAN messages are time-stamped and the configurable filter selects the forwarding of CAN messages to the other interfaces.

In industrial applications, Profibus is one of the market-leading networks. Several companies provide CAN-to-Profibus gateways. Besides Axel (, Deutschmann (, Esd (, Hilscher (, and RM Michaelidis, Helmholz recently launched the 700-650-CAN01 Profibus-DP/CANopen gateway. Up to 15 CANopen devices can be integrated logically into the Profibus-DP network. The CANopen interface of the gateway provides NMT master functionality, Sync producer capability, and uses Node guarding to supervise the CANopen devices. The Profibus-DP network is always the higher hierarchical network, meaning it is not possible to run the Profibus-DP network as a sub-network of the CANopen network.

The CANopen application profiles specify an entire application. Each device compliant to the profile uses the same object dictionary definitions. However, the network topology is not specified. Thus, it is possible to segment the communication system into several physical CANopen networks. Transparent bridges do the interconnection between the CANopen segments. An example for this approach is the CANopen lift profile (CiA 417 series). Transparent bridges are transparent with regards to the process data (application objects) and the PDOs. Process data with read-only access are on the other side of the transparent bridge objects with write-only or read/write access. The RPDO (receive process data object) on the one side is a TPDO (transmit process data object) on the other side and vice versa. SDOs and emergency messages are not transparent.

CiA 400 describes the standardised CANopen-to-CANopen bridge. The bridge supports up to 32 CANopen interfaces and can be used in hierarchical and non-hierarchical network architectures. The CiA 400 specification defines the remote SDO services as well as the forwarding of remote emergency messages. The remote request of NMT and heartbeat services is implemented by SDO services to objects defined in CiA 302 (additional application layer functions). First implementations are under development.

CiA and ModbusIDA jointly started the standardisation of ModbusTCP-to-CANopen gateways. The result was the CiA 309 series of specifications that covers all Ethernet-based networks. Besides the ModbusTCP-specific protocols (CiA 309-2), the standard describes the communication services of the Ethernet-side of the gateway (CiA 309-1), and a generic ASCII command interface (CiA 309-3). First ModbusTCP products are available from Schneider Electric ( Port ( announced the first generic Ethernet-to-CANopen gateway compliant to CiA 309-3. CiA is involved in the standardisation of ProfinetIO gateways initiated by the PNO Profibus User Organisation. The standardisation of the ProfinetIO-to-CANopen gateway is not yet finalised, the work is still at a very early stage. The first work draft proposal for a standardised CANopen-to-AS-i gateway is distributed CiA-internally and is under review. It should be released CiA-internally by the end of this year. The CiA 413 series describes standardised CANopen gateways to J1939-based networks. The CiA 413-2 and CiA 413-3 documents define the gateway to the truck/trailer interface (ISO 11992). Part 5 and 6 of CiA 413 specify the specific and generic gateways to J1939-71 networks. First products are under development. Iveco ( plans to equip its truck with J1939-to-CANopen gateways. Ifm electronic ( has developed a generic CANopen gateway device to be connected to J1939-based networks such as SAE J1939-71, ISO 11992, or ISI 11783 (also known as Isobus). RM Michaelidis ( also a CANopen-to-J1939 gateway.