With CAN FD a reality in the automotive domain, with a key focus on bandwidth and the new ISO11898-2:2016 now published, making a robust CAN FD network still remains a challenge. This paper explains NXP’s experiences in working with automotive OEMs and insights gained in network simulation.

Flight simulators are used for entertainment or training purposes. These systems reproduce the cockpit of an aircraft as realistically as possible. Nowadays there is a thriving community of users of this kind of products and several companies that provide hardware blocks to build the cockpits. Traditional architectures of flight simulators use several personal computers and point-to-point connections to link the cockpit devices with the simulation software. This paper describes the development of CAN-based modules for A320 flight simulators. These modules were developed for the Virtual Aviation Systems company and comprise blocks for the throttle, engine panel, gear, flaps, spoilers, pedals, FCU and EFIS systems. All the modules provide transparent RS-232 and CAN connections in order to be used individually or in a CAN network. The application layer follows the CANaerospace interface specification and provides users with the ability to ask for the identification of the devices, to change the Node-ID, to configure some of the modules and to automatically configure the baud rate.

Scheduling frames with offsets has been shown in the literature to be very beneficial for reducing response times in real-time networks because it allows the workload to be better spread over time and thus to reduce peaks of load. Maintaining a global synchronization amongst the stations induces substantial overhead and complexity in networks not providing a global time service such as CAN. Indeed, on CAN, a global clock is rarely implemented in practice and each station possesses its own local clock. Without a global clock, the de-synchronization between the streams of frames created by offsets remains local to each station and thus less efficient. In a previous paper [1], we developed a method to compute latency upper bounds for set of messages with offsets when the inter-node synchronization is not perfect. On a simplified test case, we obtained a reduction of 65% of the delay using a clock accuracy of only 1ms. In this article, we extend the method to consider a realistic case study (mixing periodic and asynchronous flows, considering errors and tacking into account the synchronization protocol).

FDT is a standardized device management technology, evolving to IIoT including OPC UA and mobile technologies. This will allow (existing) CANopen devices to be part of this evolution. This contribution shortly describes the concept of the FDT technology as it is specified today. Then it is explained how the use of OPC UA in conjunction with FDT allows to provide data of existing field devices (e.g. CANopen). Further on the concept of managing field equipment with mobile devices. The respective architecture in discussion shows how a standardized mechanism using FDT will help the user and avoid proprietary solutions. Finally an outlook is given how these pieces are building the basis to evolve into the IIoT world.

CAN nodes that have an attack surface like user accessible connections (e.g. WiFi, USB, Bluetooth, CD/DVD) could be compromised and pretend to be another node by sending messages with CAN IDs that are assigned to that other node. With that, they start to control functions in a network which they normally would not interfere with. Such compromised node could also generate a high bus load by sending high priority CAN messages very frequently, causing a denial of service for messages with low priority. To avoid such cyber-attacks, the CAN transceiver can monitor the CAN IDs sent and stop transmission when they do not comply with a whitelist of allowed CAN IDs. Transmission can also be stopped in case the node generates too much bus load. Current transceivers are easily replaced by security enhancing transceivers, which is way easier than upgrading the host and its software. The transceiver offers a security level that is independent from a potentially compromised host and thus enhances the cybersecurity of CAN systems. These firewall-like functions are neutral to message latency and avoid the complexity of handling cryptographic keys. Configurability allows for flexibility and reduces the chance of success for hackers. This is the next evolution in smart transceivers after partial networking and FD shield.

The “Concise Device Configuration File” format was conceived to support a simple method to configure a CANopen device. The CDCF is primarily a list of write accesses for an Object Dictionary. This paper describes an enhanced CDCF format which supports various commands including setting timeouts, reading back values for confirmation, transmitting the NMT master message and executing a LSS Master cycle. These commands support custom test sequences including identification. A player supporting this format can verify if a device matches the CDCF (for example vendor ID and product code match), before continuing. The files required can be created based on CSV files as supported by spread sheet programs, which greatly simplifies CDCF generation and editing.

Those who design CAN FD networks for automotive applications know about the advantages of the CAN successor: the new system maintains existing CAN concepts such as bus arbitration, frame identification, event control, etc. in order that specialists familiar with it do not have to deal with new types of strategies. However, the CAN FD development confronts network designers with some additional challenges mainly attributable to the higher bandwidth in the data phase. CAN FD is noticeably more sensitive to unfavorable network topologies, electromagnetic interference sources and influences as well as wrong termination, for instance. In order to realize robust networks, CAN FD designers must thoroughly deal with these effects which primarily take place on the physical layer. This article presents a comprehensive concept which establishes a strict time-related reference between the logical network analysis and the events on the physical layer. This approach enables users to detect errors and their causes at a very early stage of development, to correct them or to take corresponding measures and thus to come to suitable results more quickly.

The new XML device description (CiA 311) is mandatory for CANopen FD devices. It substitutes the existing electronic data sheets as defined in CiA 306. The new format provides much more possibilities to describe CANopen FD devices in detail – both the application and the communication parts. This paper gives an overview of the XML device descriptions (XDD) and compares it with the previous EDS format. It focuses on use cases and advantages for CANopen FD device manufactures, system integrators and tool manufacturers. Additionally, migration paths from existing EDS files to modern XML device description files are discussed.

As a result of the 2 world wars, every year there are still approximately 300 ton[1] of bombs found on Belgian soil. To uncover these explosives on a safe manner the use of a remote controlled vehicle can reduce the possible threat of human casualties. The Belgian Army has given us, VIVES University College, the task to convert an existing skidsteer so that it can be remote controlled. The skidsteer is fitted with a custom shovel arm so it’s possible to reach a reasonable depth to uncover the bomb. The body of the skidsteer is also reinforced to withstand a possible bomb blast.

The ever increasing number of electronic control units in modern cars, connected by networks to form a distributed computing system, led to the development of an open industry standard for automotive E/E architectures, AUTOSAR (AUTomotive Open System ARchitecture). It standardizes a layered software architecture, interfaces, APIs, and a runtime environment that allow a modular design method where re-usable software components may be transferred inside the system. The execution of software tasks that are distributed between different ECUs requires that the ECUs share a common time base. AUTOSAR defines methods how to synchronize the time bases between ECUs that are connected to the same network. The new CiA 603 standard specifies a hardware time-stamping concept to be imple-mented in future CAN controllers. This concept is compatible with the AUTOSAR syn-chronization method, allowing to use both software and hardware time stamping in the same network. The hardware time stamping is independent of interrupt response times and results in higher accuracy of the time base synchronization. This paper describes the new time-stamping concept and its implementation into CAN IP modules.

As CAN was developed 30 years ago, the CAN bus was used in automotive applications only. The CAN bus was active in driving mode. New features, such as keyless entry require permanently supplied ECUs, which must be activated via CAN bus. This article describes how to wake up a transceiver with one or more CAN frames very fast.

Due to the upcoming requirements of multimedia applications and driver assistance systems, the volume of communication data in a car is continuously increasing. Current network architectures will soon require new topologies in order to cope with those requirements and to ensure data security. Consequently, gateways within new topologies will change as well. This in turn impacts the functional requirements of the key component of a gateway, the gateway microcontroller and its internal system architecture. New gateway IPs with dramatically improved functionality are required. CAN and Ethernet will come closer, and a gateway will have to handle both. Bridging CAN networks via a backbone Ethernet will also be covered. This paper presents a view on a future gateway controller hardware architecture and its routing capabilities. The concept is compared against alternative approaches. Interaction between a new kind of gateway IP and the associated host software provides a way to handle both CAN signal and CAN frame routing challenges. A preliminary insight into the hardware functionality completes this contribution.

Commonly used security methods for authentication and encryption/decryption on the Internet cannot easily be applied to CAN/CANopen. The CANcrypt framework described in the book “Implementing scalable CAN security with CANcrypt”[1] adds different levels of security features to CAN. The CANcrypt system is protocol independent and can be used with CANopen or other higher-layer CAN protocols. A manager / configurator is only required for the generation and exchange of keys, but not during regular operation. For key generation, CANcrypt uses a CAN feature that allows two devices to exchange a bit not visible to other CAN devices. This allows generating pairing keys that only the two participants know. Per default, CANcrypt uses a dynamic 64-bit key to cover the longest possible secure data block, 8 bytes. From this key, a pseudo one-time pad is generated and changes frequently. How often new random bits are introduced to modify the shared key is configurable. 128-bit keys for AES-128 are also supported. CANcrypt provides a security infrastructure for CAN where developers can still select or customize specific security functions. It can be integrated into existing code at the lower driver level, making it independent from protocol or application layers above.

A motor control system using the CANopen CiA-402 device profile was developed for controlling and monitoring individually the seed dispensing for a planter row unit. The paper describes relevant aspects in the integration of the CANopen protocol in electronic motors for planter systems. We discuss the flexibility the protocol provides for covering specific applications like seeding, the advantages of using a standardized driver profile like CiA-402 instead of manufacturer-specific designs, the mode of operations: speed and position modes for closed-loop regulation, the network configuration, feedback signals for monitoring the motor performance and the emergency mechanism established between components. The paper is mainly focused on describing the most relevant decisions in terms of design that were made during the integration of CANopen communications in an electronic motor for seeding applications.

Influenced or driven by Industry 4.0, we can see that digitalisation also has a strong impact on sensors and measurement systems. CANopen was established to distribute digitalised measurement data. Using a controller inside a sensor with CANopen communication features is generally a part of a system with distributed intelligence. This also means distributed safety liability whenever the measurement data is part of the monitoring chain of the system. We present the following: Short introduction to CANopen safety, development of CANopen Safety environments, the process of certification.

Safety standards require, that manufacturers are responsible for maintaining safety level of systems throughout their life cycle. Traditionally the implementations have been designed and validated design time only. Despite of the requirements, little extra attention has been paid for guaranteeing assembly, maintenance and service of the systems without degradation of safety performance. Experience has shown, that safety performance after assembly is lower than designed and further, maintained level gradually decreases from assembled one. More systematic approach for reliable spare part orders, logistics and assembly is presented. Main enabling thing is adding machine understandable identifications for components, transportation means, systems and target positions. Then, information may be accessed by consumer devices so, that error prone manual typing of identifiers and information searching are not required. Consistent identification enables automated information collection in the background, without intentional human effort. Main results include order of correct and valid spare parts, including second sources, up-to-date product documents and configuration packages in the field. Status in the field is continuously up-to-date, including errors. In addition to the automated live reports, most serious exceptions trigger notifications, including links to corresponding reports. With the presented concept, it is possible to maintain the designed safety level in practice.

CAN technology was developed in the 1980s and became available in 1987, just as other industrial fieldbus systems like PROFIBUS or INTERBUS entered the stage of industrial communication. Beside the fact that CAN is a success in the automotive industry and used in all types of cars today, it has also made its way in many other industrial areas. About 15 years ago, new technologies based on Ethernet started to emerge, with appealing and sometimes outstanding features. Some six years ago Ethernet also started to find its way into automobiles. Today, other new communication technologies are showing up on the horizon driven by the omnipresent Industrial Internet of Things. But even now, 30 years after their introduction, these “classic” fieldbus technologies are still alive – with varying success. Since CAN was initially developed with a focus for use in automobiles, CAN has certain features that still make it the best choice for many applications in automobiles and industrial areas – even when compared to the newer technologies. This paper discusses why CAN is still a valid or even better choice for certain application areas than Ethernet-based technologies, not just focusing on the advanced features provided by the enhanced capabilities of CAN FD but also highlighting how these applications benefit from the features of “classic” CAN.

Automakers are about to introduce CAN FD into the next generation of vehicle E/E architectures. This paper will give an overview about general trends and technologies in the next generation of vehicle architectures. It will be shown how CAN FD fits into these new architectures and where, how and why it is used there. The way CAN FD interacts with other communication systems will be discussed. An insight into the everyday implications one has to deal with while integrating CAN FD from the architecture, software and hardware point of view will be given. Finally the paper will conclude with an outlook what to expect from CAN FD in future.

Modern CAN controllers, especially for FPGA integration, keep growing stronger and more versatile. Also the issues in Industrial Automation are increasingly complex. As a result the number of requirements, in particular for high precision timestamps, grows as well. The required accuracy can only be obtained through a hardware based solution. For this reason, the CAN controller has to be extended with a 64 bit timestamp counter and every received CAN frame gets a timestamp at the receiving time. In complex systems such as test benches or airplanes, global time networks are necessary. Via an external source (e.g. IRIG-B) a timestamp synchronisation of all CAN controllers and other nodes in the whole system is possible. Through the availability of an internal timestamp high precision CAN frame transmissions will be facilitated. The TX-FIFO of the CAN controller is expanded with a 64 Bit timestamp which contains the sending time. This enables approximate real-time behaviour in non-real-time operating systems. Additionally a precise feedback containing the transmission time of any given CAN frame is available. This is particular used by higher level protocols like ARINC825.

In 2012, Bosch has released the first version of the CAN FD protocol specification to fulfill the increasing demands for bandwidth and cost efficient communication protocols. The first CAN FD transceivers, supporting communication in the CAN FD fast phase at higher data rates, are already available on the market. New automotive functionalities are required without putting the expected interoperable behavior in risk. After having addressed CAN FD conformance testing in the new international standards, ISO 16845-1 and ISO 16845-2 requirements from OEMs and silicon vendors were collected and aligned, and test cases have been drafted and specified to enable interoperability of CAN FD transceivers in a multi-vendor environment. The first release of the Interoperability test specification for high speed CAN transceiver or equivalent devices [1] was published in 2016. This paper discloses lessons learned from CAN high speed interoperability tests and gives insight into interoperability aspects dealing with higher data rates communications and, additionally, coexistent scenarios considering CAN FD transceivers and CAN transceivers with selective wake up capability representing used cases intended to be adopted by some carmakers. This presentation will convey a detailed overview of the new interoperability test specification in conjunction with the respective test system implementation.

The nonprofit CAN in Automation (CiA) users’ and manufacturers’ group started from its beginning the development of higher-layer protocols and additional physical layer recommendations, which were not covered by Bosch’s CAN 2.0 A/B specification. Additionally, the association started the promotion of CAN technology in many different markets – first in Germany, then in Europe, and later in North America as well as in Far and Middle East. With the introduction of CAN FD, the next generation of CAN technology was born giving it another 20 to 25 years of lifetime. At least in 2020, we will see the first cars on the road using CAN FD networks. Other industries will follow or they will surprise me and adapt CAN FD earlier.