Industrial communication
CAN FD also in factory automation?
Although initiated by the automotive industry, the extended CAN version CAN FD is also suitable for industrial applications. But can the CANopen protocol also be transmitted in CAN FD networks and is the whole thing suitable for Industry 4.0 and the IIoT?
Christian Schlegel, HMS/Ixxat: "The CANopen protocol will benefit from the higher CAN FD data rate."
© HMS/IxxatChristian Schlegel, Managing Director of HMS Technology Center Ravensburg GmbH with the Ixxat brand, provides information.
Markt&Technik: To what extent does CAN FD offer better performance than classic CAN?
Christian Schlegel: CAN FD increases performance through two major changes: firstly, the eightfold increase in the maximum number of data bytes transmitted in a message from 8 to 64 and, secondly, the increase in the data rate to up to 8 MBit/s. However, it should be noted that when sending a CAN message in its arbitration phase, the data rate is still a maximum of 1 Mbit/s and only switches to the higher data rate for the transmission of the data and the checksum after the arbitration phase has been completed. The switchover takes place seamlessly from one bit to the next within the message currently being transmitted. While the maximum net data rate of CAN is around 600 kBit/s, it reaches up to around 5.3 MBit/s with CAN FD.
One limitation of CAN in the past was that the network extension was limited if a higher data rate was required for the operation of a system - at 1 Mbit/s to a maximum of 25 meters. With CAN FD, it is now possible to use 500 kbit/s in the arbitration phase, for example. This makes it possible to extend the network by up to 100 m. In the data phase, you can still transmit at 4 Mbit/s, for example, and achieve a maximum data rate of around 3 Mbit/s in this combination.
In addition, the detection of errors has been adapted to the larger messages by means of a modified CRC checksum procedure and has also been improved. As a result, the residual error probability of CAN FD has been reduced by orders of magnitude compared to CAN.
Is CAN FD mainly aimed at automotive applications or also at industrial applications?
Like CAN, CAN FD was initiated by automotive companies. They were looking for a solution that would provide the increase in speed and range of functions to support current requirements in vehicle communication, which come from AUTOSAR and will also require encryption and authentication in the future, without having to switch to FlexRay or even Ethernet. The solution found with CAN FD has the advantage that it is more robust than CAN, just as inexpensive, has the same low energy requirements and, above all, a great deal of technological expertise is available in the vehicle world. All German OEMs will introduce CAN FD in the next generations of their vehicle types.
CAN is already widely used in non-automotive applications. CAN FD will also find its way here because today's CAN networks will benefit from the increased performance of CAN FD and CAN FD will certainly not cost any more in the future than CAN costs today. This is not necessarily the case in factory automation, where large machines are involved that are also networked with each other in a production line and place high demands on motion control. Industrial Ethernet solutions are increasingly finding their way into such applications, where they really come into their own. It is rather fields of application such as medical technology, renewable energies, transportation (ships, trains, airplanes), "small machines" such as ticket machines and handling systems as well as small robots and commercial vehicles where CAN / CAN FD continues to show its strengths: Robustness (MTBF, error rate), bus system (passive line or star topology - no active switches are required between components), installation and maintenance, power consumption (3 times less than an Ethernet interface) and price (3 to 5 times less than an Ethernet interface).
The CANopen protocol is normally used in industrial automation. To what extent can CANopen networks be brought up to the performance level of CAN FD?
The current CANopen protocol is designed for the maximum data length of CAN with its 8 bytes. It would therefore benefit from the higher CAN FD data rate. For some time now, a working group of the CAN in Automation (CiA) user organization has been working on extending CANopen for CAN FD (CANopen FD). This concerns both the PDOs and the SDOs, for which a new protocol is being introduced that eliminates the limitations of the previous SDO protocol and will provide a considerable performance boost in terms of the possible data rate. Some member companies of the working group have already successfully demonstrated initial implementations of CANopen FD as part of a joint CANopen FD demo at various trade fairs since SPS IPC Drives 2016 and at the international CAN conference at the beginning of March.
Interesting for new CAN-open networks
What are the ultimate benefits of CAN FD in industrial applications? Is CAN FD only interesting for increasing the performance of existing CANopen networks or also for new CANopen networks?
CAN FD will only be of interest for new CANopen networks. The reason for this is that a significant increase in performance and functionality is only possible with CANopen FD. Furthermore, existing products must be upgraded for CAN FD. This means that the hardware must be equipped with a CAN FD controller and a CAN transceiver that is specified for the higher data rates. CAN FD devices can generally support the "classic" CAN mode so that they can also be used in CAN/CANopen networks. However, it is not possible to operate pure CAN/CANopen devices in a CAN FD/CANopen FD network.
What future does CAN have - whether as classic CANopen or at the performance level of CAN FD - in Industrial Production 4.0?
To answer this question, we need to look at what Industry 4.0 or the Industrial Internet of Things (IIoT) actually wants to achieve from a communication technology perspective. The general aim of Industry 4.0 and IIoT is to collect considerably more operating and diagnostic data and to enable continuous data transmission between IT and automation networks in order to improve the maintenance and control of machines and systems, thereby optimizing production and making it more flexible.
The additional operating and diagnostic data to be recorded are usually data packets that are not transmitted as frequently, but have a larger volume. In contrast, the control data used in the field, i.e. within a machine, is small in volume and is transmitted frequently with high requirements for real-time data transmission.
As already mentioned, Industrial Ethernet or Ethernet TSN within machines only makes sense if the machines require the additional performance of Ethernet systems despite the associated disadvantages. For smaller units, but also as sub-systems in large machines, there are and will be many applications in the future in which CAN or, above all, CAN FD has clear advantages, be it in terms of robustness, price, energy requirements or ease of installation and maintenance. This is especially true for applications outside of factory automation.
Can CANopen be connected to OPC UA in any way?
OPC UA is a protocol based on TCP/IP. This means that the OPC UA protocol cannot be transmitted via CAN or CANopen without further ado. What is possible, however, and is already being done in a CiA working group, is to create a Companion Specification that defines how CANopen is mapped to OPC UA. This implementation can then take place within the machine controller or on a gateway. As already mentioned, much more data must be transferred than just for the pure control of the machine. This will no longer be a problem with CAN FD or CANopen FD.
There are many device profiles and application profiles from CiA for CANopen. Can they be used together with one of the established Industrial Ethernet systems or with TSN?
EtherCAT and Powerlink already use the CiA device and application profiles. They also define and use CANopen as an application layer. In addition, some of the device profiles and application profiles have already been adopted as international standards. TSN itself is not a protocol for data transmission, but a mechanism that ensures a defined latency time and bandwidth for the transmission of data via standard Ethernet in accordance with IEEE 802.1. TSN lacks a defined application layer. This could be OPC UA, for example, or TSN in conjunction with EtherNet/IP or Profinet, in which case we would be in the world of ODVA or PI, which have their own device profiles and application profiles (but significantly fewer profiles than CiA).
To what extent and under what circumstances can the CANopen profiles be used in Industrial Production 4.0?
As soon as there is a Companion Specification for OPC UA and CANopen, the device and application profiles can also be used in conjunction with OPC UA. This is still the biggest weakness of OPC UA today, because OPC UA has no definitions of how data, parameters and functions of devices and systems in the various application areas are modeled or mapped uniformly.
What roadmap is HMS/Ixxat pursuing with regard to CANopen and CAN FD in Industrial Communication 4.0?
In recent months, the existing CAN products of the Ixxat brand have been revised to support CAN FD, and numerous new product versions with CAN FD support were presented at this year's embedded world. A wide range of CAN FD interface cards, CAN FD topology components and CAN FD gateways are now available. Later this year, we will integrate support for OPC UA and MQTT into some of these components. HMS is a member of the CiA working group defining the Companion Specification for CANopen and OPC UA and is active in working groups of the OPC Foundation.











