CANopen Gateways in the Internet of Things
The CANopen/Ethernet Gateway specification 309 „Interfacing CANopen with TCP/IP“ becomes more and more important in the Internet of things. As its name suggests CiA-309 defines functionalities to access CANopen networks and devices from Ethernet networks. The first version which has been already defined in 2004 was only used in niche applications but starting from 2012 when the specification was updated, CiA-309-gateways have been in use in a broad range of applications and several products are now available as hardware or software. Especially with the internet of things more applications are opened up for the CANopen gateways CiA-309 now.
An overview on CiA-309
The CiA-309 specification consists of 3 parts. The 1st part CiA-309-1 describes general services and principles and defines 3 gateway classes.
NMT Slave + SDO Client
Class 1+ SDO requesting device
Besides these classes additional CANopen services like PDO, heartbeat consumer, node guarding master, LSS master and more are defined in CiA-309-1 but are optional.
The part CiA-309-2 defines a mapping of these services to a ModBus/TCP-CANopen gateway. The ModBus/TCP side of the gateway is a ModBus/TCP slave and the CANopen side can either be a simple SDO client or a sophisticated CANopen manager depending on the implemented gateway class. Nevertheless, the ModBus/TCP-CANopen gateway has to work within the limitations of existing Modbus networks, which means that the length of requests and responses is limited to 253 bytes and that asynchronous data transfers (e.g. PDOs) are not allowed. ModBus messages to Modbus/CANopen gateways are transmitted using the ModBus Encapsulated Interface Transport (MEI) with the function code 43 and the MEI type 13. The 2 bytes are followed by CiA-309-2 commands as binary data.
CiA-309-3 defines an ASCII mapping of the CANopen services and all CANopen services can be transmitted as ASCII strings via TCP/IP. Nevertheless, the protocol definition does not limit the use of TCP/IP as transport layer, so also implementation that use UDP/IP or a serial point-to-point protocol are possible and in use.
The specification covers basically 4 service primitives. These are:
request: communication service required
confirmation: answer to a service request
indication: an event has occurred in the network
response: answer to an event
Based on these the ASCII protocol for CANopen defines commands that are composed of tokens that are separated by white-spaces and closed by CRLF characters. All commands that are sent to the gateway are confirmed and preceded with a sequence number that is enclosed in square brackets [ ]. The sequence number is an UNSIGNED32 number and this number is sent back from the gateway with the answer, but it is not used with event-triggered messages from the gateway. After the sequence number the command starts with an optional net-ID and the node-ID which is addressed and followed by the specific command. All commands are defined in CiA-303-3 Backus–Naur Form (BNF). The definition for a SDO request is e.g.:
“[“”]” [[net] node] r[ead]
and an example for such an request is:
 1 43 r 0x1000 0 u32
which means that the value of the object 0x1000 subindex 0 shall be read from node 43 in net 1. If a CANopen only supports a single CANopen network, the net number can be omitted.
During the latest meeting of the CiA 309 working group it has been decided to open the specification for more complex commands. Although nothing has been defined yet, it paths the way to more sophisticated use cases which might be necessary for the Internet of things.
ModBus/TCP and ASCII gateways
emtas provides both a CiA-309-2 gateway to connect ModBus/TCP to CANopen networks and a CiA-309-3 gateway as well for TCP/IP connection using ASCII commands.
The CANopen component of the gateways is based on the proven CANopen master stack from emtas. The CiA-309 gateways are available as Linux applications and can be used with an (embedded) Linux device, that supports a can4linux or SocketCAN CAN interface. Also a source code edition is offered that can be ported to all targets that support a CAN interface and a TCP/IP stack. Full featured TCP/IP stacks with BSD sockets facilitate the use, but also light-weight TCP/IP stacks without BSD socket support can be used. Thus the source code edition is suitable for the integration into small embedded devices. Additionally, using the source code it is possible to add functions and services that exceed the scope of the CiA-309 specification.
Current use cases of CiA-309
One of the first use cases of CiA-309 have been CANopen service and diagnostic tools that can operate via Ethernet or Internet connections. The first product that implemented CiA-309, especially CiA-309-3, in hardware was the EtherCAN developed and manufactured by the company EMS Wünsche from Germany. Besides CANopen tools the CANopen specification 443 for sub sea instruments specifies the use of CAN-309-3 for their transparent maintenance link to configure or updates the devices. More applications as backbones and configuration links to handle parametrization and firmware updates exists, but they haven’t been specified in CANopen application profiles yet.
Use cases of Internet of Things(Iot)
According to Wikipedia the Internet of Things (IoT) refers to the interconnection of uniquely identifiable embedded computing-like devices within the existing Internet infrastructure. Typically, IoT is expected to offer advanced connectivity of devices, systems, and services that goes beyond machine-to-machine communications (M2M) and covers a variety of protocols, domains, and applications.
Transferred to our CANopen domain it means to have Internet access down to a CANopen network or a single CANopen device.
CAN in Automation e.V. has recently established a working group that deals with the Internet of Things and employees of emtas participate in this group. Unfortunately, the experts have just started to work on the topic and consequently no results are available yet. During the 1st meetings the uses case have been defined: Diagnostic of devices and Functional Addressing. Functional addressing means that a CANopen device is no longer address by its CANopen node-ID but instead by a functionally, e.g. “Temperature sensor 4” or an unique function code that represents the functionality. This will not be limited to the scope of nodes but will also cover parameters and data that are normally addressed by index and sub index.
Additionally, it has been discussed that there will be different types of CANopen device with different IoT capabilities:
1) CANopen devices with full Ethernet capabilities that can handle HTTP requests or similar and may able to be a web server itself
2) CANopen devices with limited Ethernet capabilities that can only respond to a restricted set of requests via Ethernet
3) CANopen devices without IoT support – classic CANopen devices which has to be address via a gateway.
Up to now the preferred method to retrieved data via Ethernet network is to use dedicated HTTP Requests. For all use cases and applications, LAN and WAN access shall be enabled and security considerations have to be taken into account as well.
CiA 309 and EnergyBus
The topic Internet of Things is also discussed withing EnergyBus e.V., which has developed the CiA 454 application profile for use in light-electric vehicles and other energy management networks. Without ready solutions from the CiA group “CANopen and Internet of Things” own discussions have been started that led to a first proposal. A current idea is to extend CiA-309 for the use cases of EnergyBus. As discussed within the SIG “CANopen and Internet of Things” there is a need to add a functional addressing scheme to the geographical addressing the CANopen provides today. Mapped to CiA 309 it means:
Usage of device or function names instead of node-IDs
e.g. BATTERY_2 instead of Node-ID 31
Usage of Parameter names instead of index/sub-index addressing
Registration on data instead of PDOs
The usage of device names instead of node-IDs is especially imported in CiA-454 networks because node-IDs are usually assigned dynamically using the Layer Setting Services (LSS).
Additionally, it is proposed that a CiA-309 gateway only transmits PDO data via TCP/IP if the values have been changed. Taken this into account additionally an update timer is necessary to ensure that even clients that are connected later have the possibility to get informed about current, but slowly-changing values. Instead of this a “Request PDO Values” service could be added to the CiA-309 gateways
Mapped to CiA-309-3 these new commands look like these:
Value Read Request similar to SDO read request
“[“”]” r[ead] example:
> BATTERY_2 r rated_voltage
Value Write Request similar to SDO write request
> MCU w assistance_level 2
“[“”]” register value example:
> BATTERY_2 register value current_voltage
The objective of that approach is e.g. that smart-phone applications can be able to read/write certain information the electric bicycle without having to much about CANopen or EnergyBus (CiA 454) wheres more sophisticated applications or PC tools could use the full features of CiA-309-3.
Using such an approach the extended CiA-309 gateway in the EnergyBus network has to be aware of the characteristics of CiA-454 devices and the structure of the network. Thus an extended CiA-309-3 gateway for EnergyBus have to be located inside the EnergyBus Controller, which is the virtual device that controls the EnergyBus network. Besides CiA-309-3 other methods like HTTP-POST requests or more specific JSON or XMLHttpRequest requests have been considered as well. Anyway these approaches are currently rejected in favor of extending CiA-309-3 for the sake of backward compatibility.
Nevertheless the decision can also be reversed if the CANopen working group “CANopen and Internet of Things” comes up with a better generic approach that fits the needs of most CANopen users.
Although everybody is talking about IoT these days there is need for a generic CANopen solution. The proposed idea to extend CiA-309 will suit the needs of the author for the use case in EnergyBus (CiA 454) networks. In a more generalized way, it could be used for a broader range of applications but significantly more work has to be done. More interested parties are welcome to join the efforts of CAN in Automation e.V. to develop a generic solution for the Internet of Things even beyond the current scope of CANopen.