Many automotive manufacturers are now in full evaluation of a CAN FD introduction and over the next five years, we can expect to see these new platforms in production. This is predominantly driven by the need for bandwidth to handle more complex operations, introduce security on the CAN network and for ECU (electronic control unit) fast flashing, when software is downloaded via the CAN network onto ECUs in the production line. In fast flashing, CAN FD can increase the net-bit-rate dramatically, with a resultant reduction in flashing time. In general operation, bit-rates can also be accelerated, but are limited by EMC and network topology constraints.

In the past few years, there has been a remarkable development in the vehicle front lighting field. Intelligent systems for automatic adjustment of light distribution to particular road and weather conditions have entered the Front Lighting ECUs. After an introduction of Full-LED headlights in the mid-range cars, the next step has to be done. The aim of increasing the safety for drives by night leads to adaptive high beam systems with an automatic dim out of other traffic participants to avoid dazzling them. In connection with a front camera, it is possible to either switch the high beams automatically on to low or to switch off individually the potential glaring segments of a multiple beam headlight system. With an increasing number of such light sources and segments the communication bus load increases as well. This paper focuses on the option of transmitting data to high-definition headlight systems using the nowadays implemented CAN bus and coming CAN FD bus. Some examples and limits are presented and discussed.

Some of the drawbacks of CAN depend on bit stuffing. Stuff bits worsen both timing accuracy, because of jitters on transmission times, and data integrity, due to undesired interactions with CRC calculation. The Zero Stuff-bit (ZS) mechanism operates on conventional CAN controllers and prevents stuff bits completely all over the frame by suitably encoding the data field. ZS has been experimentally proven to decrease worst-case transmission jitters from more than 20?s to less than 0.5?s at a bit rate of 1Mb/s. It also achieves a reduction in the residual error probability of about two orders of magnitude, and ensures full coexistence with conventional CAN devices and applications. An industrial-grade ZS codec has been developed for embedded platforms, whose footprint is about 2.5KB only. Its contribution to end-to-end delays is below 12?s. This confirms that ZS can be adopted as an interim software solution to ease migration from CAN to CAN FD.

The AUTOSAR release 4.2.1 introduced a Dynamic Multi-PDU-to-Frame Mapping (PDU: Protocol Data Unit). Primarily this allows an easy migration from existing architectures to CAN FD with a higher data-rate (e.g. packing multiple classic CAN-frames into one CAN FD frame). But this new functionality allows also a reduction of communication variants across the vehicle model ranges. By assigning each data-element/object an own unique ID (PDU-ID) across the full model range, the communication is getting independent from the frame architecture and CAN ID. Functionalities can be moved within the vehicle without modifying any receiving node. This approach opens a high flexibility in the variety of vehicle architectures. But there are also drawbacks. The resource demand for each ECU increases. Tools are also concerned. Testing and analyzing requires new functions. The paper introduces the Dynamic Multi-PDU-to-Frame Mapping with its benefits and its drawbacks. Further it shows the impact on gateways and its influence on SOME/IP. Requirements for analyzing and testing the dynamic PDU concept will finalize the paper.

The CAN bus protocol is used in a wide variety of applications, including industrial, automotive, and medical. Approximately 1.5B CAN nodes are used each year. Designers of these applications benefit from the many advantages CAN offers, such as reliability, cost effectiveness, engineering expertise and the availability of tools and components. CAN FD builds on the existing benefits of CAN 2.0 technology, allowing designers to leverage CAN 2.0 expertise, tools, hardware and software while also taking advantage of CAN FD’s increased data rate and data field length. This paper will explore some of the considerations associated with CAN system design and how designers can transition their applications from CAN 2.0 to CAN FD. These considerations relate to physical layer, controller and overall system topics. Application designers must begin with hardware that conforms to both physical layer and controller requirements. Solutions for CAN FD controllers will be discussed, highlighting external CAN FD controllers as an alternative to integrated CAN FD controllers. These external controllers allow designers more flexibility when choosing an MCU that best fits the application and can reduce the migration effort from CAN 2.0 to CAN FD.

Only two weeks after disclosure of the CAN FD main features at 13th iCC [1] the Linux CAN community started to discuss about a seamless integration of CAN FD into the CAN subsystem of the Linux operating system. This paper gives a comprehensive survey about the integration, configuration and usability of CAN FD in the Linux operating system as well as an introduction into the new ISO15765-2:2015 with CAN FD support.

CAN FD offers, at similar costs, a net data rate that is several times higher than in Classical CAN. Beside this, CAN FD also provides improved error detection mechanisms. Error detection is a crucial functionality provided by communication protocols. A receiving node has to be able to judge with a high probability whether a frame was received with or without bit errors. This paper introduces the four main improvements in CAN FD regarding error detection: use of CRC polynomials of higher order, inclusion of dynamic stuff bits into CRC calculation, inclusion of the number of inserted dynamic stuff bits into the frame, and the use of fixed stuff bits in the CRC field of the frame. Three of these improvements were already present in the original Bosch proposal for CAN FD. Improvement was introduced during the ISO standardization process, which provides an opportunity for participating experts to propose and review improvements or additional requirements. The experts of the ISO standardization project team assumed two fault types: fault type A (bit flip) and fault type B (bit drop and bit insertion). This paper describes these fault types. It also shows, that in a practical setup, even a single bit drop is hard to achieve and a single bit insertion is nearly impossible to achieve. This paper also classifies the potential error cases at a receiving node into three classes to analyze the interaction of fault types and error detection mechanisms.

In automotive and industrial applications the CAN protocol is very well established. But in this applications more and more data will be used and the limitation of the classical CAN network with 1 Mbit/s was not sufficient for the future. With bit rates up to 5Mbit/s, the improvement of CAN called CAN FD is now available to increase the average data rate. An update of the physical layer requirements for this high bit rates was necessary and all new and modified parameters are described in this article.

As the number of electronic control units (ECUs) in an automobile steadily increases, the demand significantly rises for achieving higher data rates, and for connecting more ECUs into Controller Area Network (CAN). As a method to achieve higher data rates up to 10 Mbps without change in the existing CAN system, CAN FD (CAN with Flexible Data-rate) is proposed. However, it is difficult to establish a CAN FD communication under the network which has much signal ringing, because the bit decision timing is shortened while the ringing convergence time is same as in conventional CAN. As a result, it has to limit network size, and this means potential of CAN FD is not enough pilled out. In this paper, we propose ringing suppression technology to boost CAN FD world which shortens the ringing convergence time, and which enables CAN FD communication with higher data rates. Typical network configurations are considered, and showed the effect of the technology up to 2 Mbps.

Fire-fighting trucks are needed in truly precarious situations, regardless of whether it‘s a fire fighting or rescue operation. The vehicles and, therefore, the installed electronics systems as well, have low operating hours. During an operation, 100 % availability is vital in the truest sense of the word. The variance of the vehicles is tremendous, no two vehicles are the same (aside from rare large-scale productions).

More than one million cars were recently recalled by Fiat-Chrysler when a new attack on the Engine Control Unit (ECU) was made public. The attackers had no access to the code the attack used a pure “black box” approach. All companies are in a rat race - trying to find vulnerabilities in their networks, and then patching them (or blocking them with defense tools). But some, like the auto manufacturers have bigger problems: vulnerabilities in automotive systems. This talk will describe technologies that allow organizations to identify as yet unknown vulnerabilities in their own and in 3rd party products, thereby considerably increasing resilience against such attacks it will explain how a “resilience certification” process can be established to quantify whether a device, an application or an entire car is reasonably secure, in a systematical and repeatable process. It will also discuss what to do once such an unknown vulnerability is discovered. The main concepts in the talk will be black box testing and fuzzing, with a special focus on automatic testing that requires little security expertise and can be done (once the guidelines are established) by junior or inexperienced personnel, making the process efficient and scalable. Examples will be given for CAN-BUS and OBDII which are unique to the automobile industries, as well as some more common examples used by network devices and Internet servers.

Even if all new CAN-controllers will support both CAN FD and Classical-CAN (referred as C-CAN in the rest of the text) it is impossible to use CAN FD frames on a CAN-bus as long as there are old C-CAN controllers connected to the CAN-bus. This paper will describe how it is possible to add some logic to the legacy C-CAN controllers to make it possible to connect them to a CAN-bus with CAN FD frames. If this logic is combined with a CAN-driver in a standard SO8 package, it is possible to make all old C-CAN units CAN FD tolerant just by replacing the CAN-driver circuit. This will be as simple as swapping two ISO 11898-2 driver circuits and should demand very limited testing and validation. This logic complies with all rules in the CAN-protocol as described in ISO 11898-1.

Security is a topic of rapidly increasing importance in both automotive as well as industrial applications. This is driven by the current trend towards ubiquitously connected systems, a higher degree of automation, and the increasing openness of systems, with a multitude of interfaces and APIs that an attacker might use for malicious purposes. In today’s systems, the communication via CAN is often insecure. Although suitable concepts and cryptographic algorithms are basically available, the distribution of the required (symmetric) cryptographic keys between the involved nodes is still challenging. Currently, the key establishment comes along with either a high lo-gistical / organizational effort or high complexity and/or costs. For that reason, we propose a novel approach for establishing and refreshing symmetric cryptographic keys between different nodes in a CAN network in a plug-and-play manner. Our ap-proach captivates by its simplicity, low complexity and high cost-efficiency, and may be readily implemented without any modifications of standard CAN controllers.

The increasing amount of electronic control units (ECUs) and message traffic in in-vehicle and industrial communication networks cause a rising demand for higher bandwidth and low message response times. As a prominent real-time distributed control network, CAN responds to this demand with the CAN FD protocol which provides improved bandwidth and payload capacities. CAN FD provides performance improvements mainly in two ways: firstly, by increasing the bit-rate in the data-phase of the frame, which results in faster message transmission secondly, by increasing the payload size, which provides better payload to overhead ratio. In a control network, it is crucial to meet the critical timing requirements of hard real-time tasks. Simulating a real-time system is an important process to investigate the timing behaviour and analyse the performance of system. This study provides the performance analysis of a CAN FD system with SAE Benchmark based message set, comprised of both timetriggered and event-triggered messages. In order to investigate the performance improvements, the models for both CAN and CAN-FD systems have been developed in Matlab Simulink environment. The message delay and bus utilisation results obtained with the simulation models show that the CAN-FD protocol provides high performance improvements to meet the requirements of real-time control systems.

CAN FD addresses the increasing demands on automotive system bandwidth offering an easier adaptability and high re-use factor of existing CAN, the most disseminated in-vehicle network protocol. However, it brings new challenges to the designers. Since the dynamic behavior of the system cannot be predicted by manual calculations, the developers are required to use the simulation to analyze the network design for a robust layout and to investigate the influences of new components with two main goals: improving the signal quality and ensuring a correct communication with precise results even under worst case environmental conditions. Simulation is the only choice to determine the asymmetry of the bits caused by physical layer effects. In order to obtain a design of robust CAN-FD networks, developers are faced with a lot of variations causing a significant amount of data to be analyzed and therefore automatization is a decisive factor to address it properly.

Highly dynamic systems supporting plug-and-play require more advanced testing methods both at the device level as well as at the integration level. This paper summarizes the tests available and used for CiA 447. These are the CiA 447 version of the CANopen conformance test, an enhanced “Concise Device Configuration File” format, the CANopen Test Machine and an automated system event analyzer for the integration phase. 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. A CANopen device with a CANopen SDO client can easily process a CDCF by executing the SDO write accesses one by one. However, there is no interaction or flow control supported. The enhanced CDCF format by Embedded Systems Academy 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 as well as complex bootloader control. The CANopen Test Machine was jointly defined by Daimler and Embedded Systems Academy and supports creating and editing test graphs drawn in Microsoft Visio®. Although developed and optimized for the CiA 447 SiG it can be used with any CANopen device. The system supports complex test sequences using multiple timers, buffers and CAN messages. The tests are state diagram based and each transition can be based on a condition (check variable or timer) and contain an action (modifying variable or timer) and a CAN transmit or receive. The generated test files can be executed on various hardware platforms, which generate a log file containing the device ID of the DUT as well as a signature line.

Troubleshooting and configuration management in the assembly and service of distributed control systems has been understood a mission impossible, which partially explains why centralized systems have commonly been used instead. Traditionally used tools in service have been based on tools used in development, not primarily intended for easy and efficient execution of limited set of repetitive service tasks. It has also been challenging to get correct spare parts, configure them and get feedback from the problems in the field. This paper presents a cloud based service approach, especially designed for the use in assembly line and field service of CANopen systems. Main focus has been in simplifying the tasks to be performed in the field. Effort has also been put on seamless integration of the framework into the standardized design process, in order to guarantee intrinsic availability of correct source information. Main contribution is in coupling the information into target systems with standardized and widely adopted mechanisms for computer aided identification of the target positions. Each operation may be systematically targeted for correct position, without adding additional components and overloading the service persons. As a result, any service action may be achieved by up to single point and two clicks.

Everybody seems to be talking about the Internet of Things these days, but what are the actual implications for industrial machine builders? What do you need to do to make your machines “IoT-ready”? Will heavy investments be needed or is there an easier way? Tag along as we try to straighten out these question marks.

The objective of this paper is to give general design rules for the physical layer of CAN FD networks. As an introduction influencing parameters are analyzed and physical relationships are shown. Critical values of typical components are given. The main section will then present a systematical analysis of basic CAN FD topologies (e.g. star, bus or sub topology). The topologies will be described by geometrical parameters and the respective physical characteristics will be derived. Finally an assessment of the possible baud rates of given network topologies as a function of the geometrical parameters will be provided.

Security in embedded systems is currently an ignored topic. But there are possibilities to easily add a broadcast authentic communication. This will allow diagnostic and debugging possibilities.

Cable harnessing is always a headache in any system design. Although CAN Bus implementation is a cable friendly solution compared to other communication protocols used in the industrial space, in some applications - especially demanding areas such as Robotic Systems and Heavy Duty Machinery - cable wearing is a well-known un-resolved issue. Another complicating factor is that electronically controlled features are becoming more advanced and their quantity increases year on year. As a result, more nodes and network gateways appear in the system and complex cable harnessing and routing mechanisms are required. The idea of replacing CAN cabling with a wireless solution is not new. Indeed, many similar CAN-Wireless gateway products with a variety of wireless solutions can be found in the market. Such a solution results in the problem of merging two different types of communication protocol (CAN and Wireless). From a system design point of view, how to implement wireless communication into CAN is a challenge. Issues such as data throughput, latency and data security need to be addressed.

Commercial vehicles include road, off-highway as well as off-road vehicles. Many of them are equipped with multiple CAN networks. Some of them are already at their lim-its regarding the busload. The CAN FD data link layer is an option to overcome these limits. However, the physical layer needs to be designed more carefully. Additionally, low-volume applications require the reuse of already existing higher-layer protocols and application software. The paper discusses the chances and challenges to intro-duce CAN FD in commercial vehicle control systems.