<\/p>\n
The CANopen\/Ethernet Gateway specification 309 \u201eInterfacing CANopen with TCP\/IP\u201c 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.
\n<\/p>\n
The CiA-309 specification consists of 3 parts. The 1st part CiA-309-1 describes general services and principles and defines 3 gateway classes. 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n The specification covers basically 4 service primitives. These are: 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\u2013Naur Form (BNF). The definition for a SDO request is e.g.: 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.<\/p>\n emtas provides both a CiA-309-2 <\/a>gateway to connect ModBus\/TCP to CANopen networks and a CiA-309-3<\/a> gateway as well for TCP\/IP connection using ASCII commands. 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\u00fcnsche 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.<\/p>\n 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.<\/p>\n Transferred to our CANopen domain it means to have Internet access down to a CANopen network or a single CANopen device.<\/p>\n 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. \u201cTemperature sensor 4\u201d 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.<\/p>\n Additionally, it has been discussed that there will be different types of CANopen device with different IoT capabilities: 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.<\/p>\n 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 \u201cCANopen and Internet of Things\u201d 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 \u201cCANopen and Internet of Things\u201d there is a need to add a functional addressing scheme to the geographical addressing the CANopen provides today. Mapped to CiA 309 it means: Mapped to CiA-309-3 these new commands look like these: Value Write Request similar to SDO write request Value Registration Value Indication 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. 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.<\/p>","protected":false},"excerpt":{"rendered":"
\nClass 1<\/strong>
\nNMT Slave + SDO Client
\nClass 2<\/strong>
\nClass 1+ SDO requesting device
\nClass 3<\/strong>
\nCANopen Manager<\/p>\n
\nrequest: communication service required
\nconfirmation: answer to a service request
\nindication: an event has occurred in the network
\nresponse: answer to an event<\/p>\n
\n“[“”]” [[net] node] r[ead]
\nand an example for such an request is:
\n[2232] 1 43 r 0x1000 0 u32
\nwhich 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.<\/p>\nModBus\/TCP and ASCII gateways<\/h2>\n
\nThe 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.<\/p>\nCurrent use cases of CiA-309<\/h2>\n
Use cases of Internet of Things(Iot)<\/h2>\n
\n1) CANopen devices with full Ethernet capabilities that can handle HTTP requests or similar and may able to be a web server itself
\n2) CANopen devices with limited Ethernet capabilities that can only respond to a restricted set of requests via Ethernet
\n3) CANopen devices without IoT support \u2013 classic CANopen devices which has to be address via a gateway.<\/p>\nCiA 309 and EnergyBus<\/h2>\n
\nUsage of device or function names instead of node-IDs
\ne.g. BATTERY_2 instead of Node-ID 31
\nUsage of Parameter names instead of index\/sub-index addressing
\nRegistration on data instead of PDOs
\nThe 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).
\nAdditionally, 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 \u201cRequest PDO Values\u201d service could be added to the CiA-309 gateways<\/p>\n
\nValue Read Request similar to SDO read request
\n“[“”]” r[ead] example:
\n>[1234] BATTERY_2 r rated_voltage
\n<[1234]] 4800<\/p>\n
\n“[“”]” w[ead]
\nexample:
\n>[815] MCU w assistance_level 2
\n<[815] OK<\/p>\n
\n“[“”]” register value example:
\n>[4711] BATTERY_2 register value current_voltage
\n<[4711] OK<\/p>\n
\nvalue
\nexample:<\/p>\n
\nUsing 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.
\nNevertheless the decision can also be reversed if the CANopen working group \u201cCANopen and Internet of Things\u201d comes up with a better generic approach that fits the needs of most CANopen users.<\/p>\nConclusion<\/h2>\n