Although the CAN bus was originally developed for automotive communications, it is now popular in low-bandwidth industrial applications. Given the demand for CAN protocols in various markets, developments in HLPs continue. One of these developments by Bosch began in 2018 with the design of the CAN XL. In early 2011, General Motors and Bosch began developing improvements to the CAN protocol for higher throughput. The automotive industry has been particularly affected by the end-of-line downloading of increasing software packages into electronic control units (ECUs). This time-consuming task had to be shortened by a more powerful communication system. The idea of increasing the transmission speed of the ADC by introducing a second bit rate was not new. Several scientists had published approaches since the early 2000s. But none of them were mature enough to convince the automakers. Together with other CAN experts, Bosch pre-developed the CAN FD specification, which was officially presented at the 13th CAN International Conference at Hambach Castle in 2012. In automotive communication, CAN buses enable efficient and reliable communication with a low-level network. A CAN bus is a two-wire bidirectional serial communication system that is a preferred communication protocol in industrial automation.

These networks reduce the cost, complexity and footprint associated with point-to-point cabling systems and are now the standard for embedded networks. In this article, we will explore the history of the CAN bus to see where this technology stands. A Controller Area Network (CAN) is a serial bus protocol originally developed by the German company Bosch in the mid-1980s. Bosch`s CAN specification (version 2.0) underwent international standardization in the early 1990s. After several political disputes, notably within the framework of the “Vehicle Area Network” (VAN) developed by some major French car manufacturers, the ISO 11898 standard was published in November 1993. In addition to the CAN protocol, a physical layer for bitrates of up to 1 Mbit/s has also been standardized. At the same time, ISO 11519-2 standardized an energy-efficient and fault-tolerant type of data transmission via CAN. This was never implemented due to weaknesses in the standard. In 1995, ISO 11898 was supplemented by an addendum describing the extended frame format with 29-bit ADC. CAN is a low-level protocol that does not support security features per se.

There is also no encryption in standard CAN implementations, leaving these networks open to interception of man-in-the-middle images. In most implementations, applications are expected to provide their own security mechanisms. For example, to authenticate incoming commands or the presence of certain devices on the network. Failure to comply with the implementation of appropriate security measures can lead to various types of attacks if the adversary manages to insert messages into the bus. [19] While passwords exist for some security-critical functions, such as changing firmware, programming buttons, or controlling anti-lock brakes, these systems are not universally implemented and have a limited number of primer/key pairs. As electronics engineers with fingertips constantly contaminated with rosin, it`s easy to get lost in voltage levels, count electrons, and discuss electromagnetic interference out loud. Nevertheless, the CAN bus is primarily a network protocol. An undesirable side effect of the bit stuffing scheme is that a small number of bit errors in a received message can corrupt the unloading process, resulting in the propagation of a greater number of errors in the uncompressed message. This reduces the protection that the CRC would otherwise provide against original errors. This protocol deficiency was corrected in CAN FD frames by using a combination of solid material bits and a counter that records the number of material bits inserted. In early 2000, an ISO working group involving several companies defined a protocol for the time-controlled transmission of CAN frames.

Dr. Bernd Müller, Thomas Führer and other Bosch associates defined the TTCAN (Time-trigger communication on CAN) protocol in collaboration with experts from the semiconductor industry and academic research. During the standardization process within ISO, several academic weaknesses were identified in the proposed error detection mechanisms. This required a review of the ADC FD protocol and the introduction of additional safeguards (e.g., fill bit counters). For this reason, there is a non-ISO CAN FD protocol that is not compatible with the ISO CAN FD protocol standardized in ISO 11898-1. CAN in Automation (CiA) is the international organization of users and manufacturers that develops and supports CAN-based top-layer protocols and their international standardization. [18] These specifications include: Despite the fact that the first standardized protocols appeared at a higher level, most CAN pioneers used a monolithic approach.