The benefits of CANopen IoT

In many applications, specifically-designed cell phone or tablet applications enable users to perform remote control and maintenance of air conditioning and heating regardless of the location. Those apps also allow condition monitoring of automated systems’ components for preventive maintenance. There is demand to provide access from the web-based monitoring or control unit to the embedded sensor with fieldbus interface and vice-versa. This is fulfilled for the networks supporting internet protocols. This access may invoke cloud connection or using the cloud for remote data processing or distribution.

The CAN in Automation (CiA) Special Interest Group (SIG) CANopen IoT designed specification CiA 309.5. It allows CANopen embedded network users to access their local and remote CANopen networks using web protocols and communication services such as Restful HTTP, Websocket, and MQTT.

What is CANopen IoT?

One of the challenging issues is the end user has typically no detailed information on the fieldbus interface. Usually, the fieldbus system is transparent for the end user. Nevertheless, fieldbus systems often require geographical addresses such as device identifier, or device parameter addresses, to allow access to a specific network participant or a dedicated function. A pool of harmonized functions is accessible from anywhere in and outside the embedded fieldbus network.

The end user can rely on and control the harmonized functionality independently from the hardware platform and communication technique without having knowledge of fieldbus details. CiA suggested using logical addressing as system-wide and technology-independent identifiers for CANopen elements. This addressing method allows users to request functions such as data monitoring and process control without knowing CANopen. However, the system itself still has to be pre-configured by a technician who knows CANopen.

CiA members also intend to offer more confortable diagnostics by providing an enhanced, harmonized, visualization. The embedded devices provide diagnostic data in a certain manner. Providing the visualization on the embedded device may solve this requirement. Therefore, any industrial terminal, tablet, cell phone, remote desktop, etc. might serve as a human-machine interface (HMI) for diagnostic services. Bypassing the limiting central host controller opens possibilities for remote diagnostics and maintenance.

However, providing visualization typically demands a lot of memory. Small sensors, which do not have the required memory resources, can provide visualization using an HTTP and Websocket with a broadband internet connection.

CiA members are working on this challenge. The SIG CANopen IoT harmonizes the previously mentioned challenges. On an application level, CiA offers function-oriented services. Using these new services, the application-specific, harmonized functions can be initiated, monitored, and controlled. The functions are CANopen communication services and parameters mapped with logical addressing into Restful HTTP or Websocket. The functions are requested/collected either straight or through the cloud using an existing internet infrastructure. The requester/collector is the web-based application while data provided is the application server located in the CANopen IoT gateway.

Web or cloud

For example, the CANopen IoT gateway may either tunnel HTTP requests/responses to the web app or through the cloud. Through the cloud, the communication path has to comprise the edge gateway having all tunneled data prepared for cloud-conform processing. The example of the local communication includes a CANopen IoT gateway, which contains the IoT and CANopen functional parts, and manages the interaction between them.

The CANopen functional part communicates with the CANopen embedded network while the gateway provides the data obtained there to the other gateway functional parts. The IoT functional part prepares the embedded CANopen data in JSON format and maps it into the Restful HTTP request/response to transmit to the CANopen network/web-based application.

Since CANopen process data or diagnostic information may occur upon an event with data dynamically updated to submit to the web, using a Websocket protocol may optimize the bidirectional communication. A Websocket session is established by the web app. Once CANopen data occurs in the CANopen functional part, it is processed in the IoT part and submitted to the web app. In this case, the web app does not need to poll HTTP requests for this data to the gateway.

Oskar Kaplun is an engineer at CAN in Automation, a CFE Media content partner. Edited by Emily Guenther, associate content manager, Control Engineering, eguenther@cfemedia.com.

MORE ANSWERS

KEYWORDS: CANopen, Internet of Things (IoT)

CiA’s CANopen IoT challenges

CANopen’s functions and benefits

Consider this

How can CANopen IoT optimize a facility’s data?

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.