Uwe Koppe (CiA Technical Director), Christian Schlegel (CiA Business Director), and Reiner Zitzmann (CEO of CiA) answered questions about the next steps in CAN technology.
With the introduction of CAN FD, the CAN community has improved the Classical CAN protocol providing more bandwidth (today: up to 5 Mbit/s) and larger payload (up to 64 byte per data frame). First CAN FD controllers and transceivers qualified for 5 Mbit/s are available. CiA develops higher-layer protocols using the CAN FD lower-layers. The CiA 602-2 specification describing the mapping of J1939 messages on CAN FD frames is already released. CiA 301 specifying the CANopen FD application layer and communication profile will be released very soon.
CAN Newsletter: The CAN FD lower-layers have been internationally standardized and CiA has released some first design recommendations (CiA 601 series). What is still missing for the non-automotive users?
Koppe: From my point of view a design guideline needs to be developed which recommends combinations of arbitration and data phase bit-rates along with topology limitations (e.g. maximum stub length). This would allow users to evaluate an upgrade path for existing networks as well as having a specification for the next generation of machines.
Schlegel: When using Classical CAN, the users have been used not to think about the physical parameters of the cable. More or less just any cable was good enough. With CAN FD and its higher data rates the cable becomes an essential component in a network installation. The impedance is important and due to this the isolation material which physical parameters should be more resistant against humidity and temperature. Here we need clear specifications and CiA should also work with the cable manufacturers in order to make these cable types available as standard CAN FD cables.
Zitzmann: From a specification point of view, comprehensive implementation guidelines and application notes for system design and device design are still missing. System designers would appreciate a detailed cable specification as well. This is why CiA has started several initiatives to develop such kind of documents that enable system designers and device designers to introduce CAN FD in their applications. From a user’s point of view, we are on a very early stage. Suitable CAN FD hardware is just available for the developers. So a broad range of device and tool manufacturers have just started to introduce CAN FD in their products. Availability of suitable devices and network components is a prerequisite for system designers to consider CAN FD in the next generation of their applications.
CAN Newsletter: CANopen FD is in the pipeline and will be released soon. What are the main benefits compared to classic CANopen?
Koppe: I can imaging that most people rank the speed and the greater payload of CANopen FD first, especially when you have seen the CANopen FD demonstrator on the Embedded World fair. However, I believe the main benefits are a more comprehensive specification in combination with additional functionality, e.g. the error history has been revised. But the biggest advantage is the new USDO service, which allows unicast, multicast, and broadcast communication between CANopen nodes. Hence it is now possible to transfer data to all CANopen nodes in a network using only one request.
Schlegel: First of all CANopen FD benefits from the improvements of CAN FD compared to Classical CAN. CAN FD brings a performance improvement by two major modifications: first the increase of the maximum length of a message from 8 data bytes to 64 data bytes (which is also reflected in the revised PDO specification of CANopen FD), and second the increase of the maximum data rate from 1 Mbit/s up to 10 Mbit/s during the transmission of the payload data. As a side effect, the residual error probability of CAN FD could be even lowered compared to Classical CAN. Another major improvement in CANopen FD is the introduction of a new SDO service and protocol called Universal Service Data Object (USDO) which enables the efficient use of the longer CAN messages but also provides much more functionality like routing in different CANopen FD networks.
Zitzmann: I think CANopen FD is just to be considered as an add-on to the classic CANopen. It saves the advantages of todays well established CANopen and keeps therefore all its attributes such as the clear device architecture, high design flexibility, and the feasibility on very robust hardware platforms by demanding a very low power consumption. On top of this, CANopen FD allows meeting the requirements of tomorrow’s embedded networking, by making use of the increased data throughput that is provided by the new CAN FD data link layer. Lengthened PDOs allow a rapid transport of large amount of process data. On the one hand this eases meeting the increased demand for data by condition monitoring or predictive maintenance applications. On the other hand especially safety and security applications will benefit from the lengthened data field. The process data can be enhanced by safety or security signatures in a single CAN FD data frame. In more and more applications the system is not static but the end user modifies the system by adding or removing devices to/from the system. The new and highly flexible USDO meets the therefore required dynamic establishment of device cross-communication between the devices easily. During system runtime and without any pre-configuration, any CANopen device is enabled to communicate in unicast and broadcast with any other CANopen device that is connected to the entire CANopen system architecture. This even applies, if this CANopen system architecture consists of several CANopen networks, interconnected via CANopen-to-CANopen router devices.
CAN Newsletter: What are the next steps to make CANopen FD as successful as classic CANopen in different application fields?
Koppe: A good marketing campaign, which includes workshops and training for CiA members.
Schlegel: It is absolutely important that the semiconductor manufacturers provide micro-controllers with CAN FD support which are suitable for the non-automotive applications and markets. There are already several micro-controllers with CAN FD support available today, but they are mainly targeting more complex applications and ECUs in cars and therefore also provide interfaces and features which are not required in many devices for non-automotive applications but make the micro-controllers much more expensive. Preferably the existing families of micro-controllers with CAN support ranging from very small versions to more comprehensive versions should be enhanced with CAN FD support. Basically this is like the chicken and egg question – who came first. Once the right micro-controllers are available, CANopen FD probably can become a self-runner because it will provide many advantages for non-automotive applications compared to classic CANopen: higher band-width, possibility for longer network extensions, improved services (e.g. longer PDOs, USDO) and better management of the conformance of the CANopen FD devices.
Zitzmann: From a specification point of view, we have to adapt all the existing CiA CANopen specifications to CANopen FD. For any specification we have to keep as many CANopen aspects as possible stable but adapt them where necessary and beneficial. This is quite a lot of work. The most urgent documents are the XML-based device description (CiA 311) as well as the conformance test plan (CiA 310). But also an adaptation of specifications such as CiA 302 (network management functions), CiA 305 (layer setting services), and CiA 309 (external access to CANopen) is in the focus. CANopen FD users will demand for efficient usage of the lengthened PDOs, according to updated CiA device and application profiles. Therefore we have to start updating our CiA device and application profiles, as well.
From a marketing point of view, CiA is going to inform the public on the possibilities, offered by CANopen FD. A good option in this context is the CANopen FD demonstrator, jointly developed by our CiA member companies. The CiA community has to come up with CANopen FD devices and tools, so that CANopen FD becomes an interesting candidate. Some people may think that it could be a showstopper that for the moment, no big host controller manufacturer considers CANopen FD. But most of them have host controllers with CAN or even CANopen support. So as soon as a specific host controller supports CAN, we can assume that there will be automatically CAN FD capability in future. To make such a host controller CANopen FD capable, only the integration of a CANopen FD protocol stack is required. CANopen FD protocol stacks are available even today, and have already been demonstrated on occasion of the SPS IPC Drives 2016 and the Embedded World 2017, as part of our demonstrator, in a multi-vendor system.
CAN Newsletter: Will CANopen FD networks compete against Ethernet-based solutions?
Koppe: The hardware price for an Ethernet-based solution is roughly three to four times more than for a CAN FD solution. You also have to consider the much higher memory requirements (Flash and RAM) and power consumption for Ethernet-based solutions. However, Ethernet has a higher data throughput. So it is not a question of competition, both networks will coexist peacefully because of different application requirements from the market.
Schlegel: For sure there will be some markets and applications where there is an overlap and both technologies will compete. However on the major market for Ethernet-based networks, which is factory automation, where large machines are controlled by Industrial Ethernet networks, have strong requirements for motion control and where the machines are also interconnected in production lines on the factory floor, (Industrial) Ethernet is set.
CAN FD and therefore CANopen FD has some quite specific strengths compared to the different (Industrial) Ethernet standards which make it more interesting and suitable for certain non-automotive applications. Examples of its strengths are robustness (MTBF, error rate, EMI immunity), it’s a bus system (no active switches between the components are necessary), installation and maintenance, power consumption (typically 3 times less than a standard Ethernet interface) and price (3 to 5 times less than an Ethernet interface considering the interface and the micro-controller performance including memory size).
Zitzmann: For any kind of application, there is always the question, which kind of communication system meets the requirements of this application in the best way. On the one hand there are technical criteria such as robustness, supported topologies, power consumption, power-on times, communication speed, latency times, cycle times, etc. On the other hand there are business criteria such as availability of devices, components, and support from several sources for reasonable prices. So after analyzing technical and business criteria for a specific application, the synopsis will show also in the near future that CANopen FD is a good candidate for realizing embedded and deeply embedded applications. My expectation is, CANopen FD and industrial Ethernet will complement each other. CANopen FD is closing the gap in data throughput between classic, so-called “fieldbus systems” and backbone applications, based on industrial Ethernet.
CAN Newsletter: Do you think that there is a need to make CANopen (FD) a thing in the Internet? Are there any activities of CiA to do so?
Koppe: In order to get data from CAN (FD) to the Internet you will need a gateway, which typically has knowledge about the underlying network, including the object dictionary of all CANopen (FD) nodes. Hence we need to define IoT methods for accessing this data.
Schlegel: In order to answer this question we first have to discuss what is meant when referring to Internet of Things. In my opinion it is a buzzword used for many different things and topics. In the scope of industrial control and networking in non-automotive applications I see two major use-cases relating to CANopen (FD) and the Internet of Things: data exchange between the IT and the OT (Operational Technology) world by means of gateways or edge controllers and the collection of additional diagnostic and operational data from the individual devices in the network. Basically there exist two protocols which are strongly related to these use-cases: OPC UA and MQTT. Both protocols are TCP/IP based and can therefore not directly be used with CANopen (FD). Anyhow, in order tunable a link between CANopen (FD) and the Internet of Thing a specification is required defining how OPC UA or MQTT are mapped to CANopen (FD). This is done by so-called companion specifications. A CiA working group is already working on an OPC UA / CANopen (FD) companion specification.
Zitzmann: More and more added values are generated by web-based applications. Predictive maintenance, condition monitoring, individualization, and optimization of a product, based on tracked user-behavior are just a few examples of big data applications. Although embedded systems such as CANopen are not in the focus of these big data applications, they provide the database for the big data applications. However not any CANopen sensor has the requirement to be connected to the Internet, there has to be the general ability to do so. To ease the access to embedded devices from point of view of a web-based application, a standardized workflow and the usage of standardized data formats are very advantageous. CANopen supports this already by its standardized CANopen device architecture and the standardized application data, specified in various device and application profiles. Additionally, CANopen supports already standardized CANopen access services that allow a simple to use access to embedded CANopen networks, from TCP/IP-based networks (CiA 309). In general CANopen (FD) is already well equipped to make CANopen a part in the industrial Internet of things (IIoT). To put all the existing CiA specifications together to a harmonized workflow, the CiA working group “SIG CANopenIoT” has been established. The group evaluates how CiA 309 commands are usable with existing and well-established web services, based on Restful, HMP, Websocket, or MQTT. Furthermore the group considers discovery functions that provide an overview, which kind of functionality resides in an embedded CANopen network. In this context, the group has introduced a reference designation system, derived from the IEC 81346, to allow a logical addressing. This may free end users of the necessity to know any CANopen specifics, in case they would like to have an access to a CANopen system’s function or parameter.
In a connected world, we shall not forget on security issues. In the past we could always assume that CAN-based systems are deeply embedded and not accessible by unintended actors. But these days are gone. Opening an embedded system to the world opens the door to misuse of the application, as well. To avoid the unintended access to a CANopen (FD) system, CiA has established the working group TF security. This working group is analyzing the security functions available in the market as well as the security requirements in the various CANopen applications. Based on these results, the group is developing harmonized solutions to meet the particular security requirements.
By the way, both groups appreciate contributions in form of technical comments or submissions. Groups can just consider requirements and solutions, of which they are aware. So I would like to take the opportunity and to invite experts in the aforementioned topics, to take part in CiA’s working groups. Many meetings are organized as web-meetings. Therefore participation is rather simple and may be beneficial not only for the emerging specification but also for the personal networking.
CAN Newsletter: What is your view on the future of CAN-based solutions in non-automotive applications?
Koppe: The market for CAN and CAN FD will increase in future, because the bus offers a reliable and robust communication at the lowest possible cost. In addition it is quite easy to develop safety applications according to EN 50325-5. And finally the increased payload allows secure communication, a topic that is already in focus for non-automotive applications.
Schlegel: Also in the future, we will still see CAN-based networks in many areas. Based on the already mentioned strengths of CAN FD / CANopen FD, there are several markets and applications like health care, regenerative energy, transport (ships / vessels, trains, air crafts), „small machines“ (e.g. ticket machines, vending machines, handling systems), automation system in buildings (elevators, escalators, door control), small robots, utility vehicles, and especially everything which is battery operated. As in many of these areas simple serial interfaces are still used in manifold ways and CAN would bring considerable improvements to such systems we can expect that the use of CAN will become even broader. Besides of this, all car manufacturers confirm consistently that they will continue to use CAN FD in the future and CAN FD will not be replaced by Ethernet.
A major exception is the factory automation market. Here the Ethernet based systems have major advantages compared to CAN / CAN FD. However, for smaller units or sub-systems inside these machines CAN or CAN FD might still be the better and preferred choice.
Zitzmann: The automotive industry is just introducing CAN FD and is planning in long-term to substitute classical CAN by CAN FD. Due to the high volumes of CAN FD that are expected to be installed in the automotive industry, CAN FD will be supported on many MCUs. Therefore, for the next decade, CAN will be available also for the non-automotive market. This is why – as any “CAN FD controller” is able to communicate Classical CAN – CAN will remain an interesting candidate for non-automotive applications. But this means also that many of todays CAN users will get CAN FD capable hardware, even if they just use for the moment the Classical CAN functionality. Some day, they will recognize that they can meet their tomorrow’s requirements on embedded networking, e.g. just by replacing the CANopen protocol stack by a CANopen FD protocol stack. This CANopen FD stack makes use of the CAN FD functionality of the already available CAN hardware. This way, with a minimum effort, the embedded CAN is “ready for future” by reusing the existing topology and without a huge training effort of the involved device and system designers.
This interview originally appeared in the September issue of the CAN Newsletter magazine 2017.