History of CAN technology (2023)

In February 1986, Robert Bosch GmbH presented the Controller Area Network (CAN) serial bus system at the congress of the Society of Automotive Engineers (SAE). It was the birth of one of the most successful network protocols of all time. Today almost all new cars in Europe are equipped with at least one CAN network. Also used in other types of vehicles, from trains to ships, as well as industrial controls, CAN is one of the most dominant bus protocols, perhaps even the world's leading serial bus system.

From the idea to the first chip

In the early 1980s, Bosch engineers evaluated existing serial bus systems for possible use in automobiles. Since none of the available network protocols could meet the requirements of automotive engineers, Uwe Kiencke began developing a new serial bus system in 1983.

The main goal of the new bus protocol was to add new functionality - harness reduction was just a by-product, not the driving force behind the development of CAN. Mercedes-Benz engineers were involved in the first specification phase of the new serial bus system, as was Intel as a potential major semiconductor supplier. Professor Dr. Wolfhard Lawrenz of the Braunschweig-Wolfenbüttel University of Applied Sciences (today: Ostphalia University of Applied Sciences) named the new network protocol "Controller Area Network". Also Professor Dr. Horst Wettstein from the University of Karlsruhe provided scientific support.

CAN was born in February 1986: At the SAE Congress in Detroit, the new bus system was presented as "Automotive Serial Controller Area Network". Uwe Kiencke, Siegfried Dais, and Martin Litschel introduced the multidrop network protocol. It was based on a non-destructive arbitration mechanism that grants bus access to the highest priority frame without delay. There was no central authority to mediate access to the network. In addition, the parents of CAN, the people mentioned above, as well as Bosch employees Wolfgang Borst, Wolfgang Botzenhard, Otto Karl, Helmut Schelling and Jan Unruh, have implemented various error detection mechanisms. Error handling also included the automatic disconnection of the participants from the failed bus, to maintain communication between the other participants. The transmitted frames were not identified (as in almost all other bus systems) by the node addresses of the sender or receiver of the frame, but by their content. The identifier, which represents the payload of the frame, also had the function of indicating the priority of the frame within the network segment.

Many presentations and publications followed, describing this innovative communication protocol, until in mid-1987, two months ahead of schedule, Intel released the first CAN controller chip, the 82526. It was the first hardware implementation of the CAN protocol. In just four years, an idea became a reality. Soon after, Philips Semiconductors introduced the 82C200. These two early ancestors of CAN controllers were very different in terms of accept filtering and frame handling. For one thing, the FullCAN concept favored by Intel requires less CPU (central processing unit) load on the connected microcontroller than the BasicCAN implementation chosen by Philips. On the other hand, the FullCAN device was limited in terms of the number of frames received. The BasicCAN controller also required less silicon. A combination of acceptance filtering and frame handling concepts is implemented in current CAN controllers. This made the misleading terms BasicCAN and FullCAN obsolete.

Standardization and Compliance

The Bosch CAN specification (version 2.0) was submitted for international standardization in the early 1990s. The ISO 11898 standard was published in November 1993 after several political disputes, particularly over "Vehicle Area Network" (VAN) developed by some of the major French car manufacturers. In addition to the CAN protocol, it also standardized a bit transmission layer. Rates up to 1Mbps. At the same time, a fault-tolerant and low-power type of data transmission via CAN was standardized in ISO 11519-2. This was never implemented due to deficiencies in the standard. In 1995, the ISO 11898 standard was extended with an addition describing the extended frame format with a 29-bit CAN identifier.

Unfortunately, all published CAN specifications and standards were inaccurate or incomplete. To avoid incompatible CAN implementations, Bosch has ensured that all CAN chips match the Bosch CAN reference model. In addition, the Braunschweig University of Applied Sciences/Wolfenbüttel has been carrying out CAN conformance tests for several years under the direction of Prof. Lorenzo. The test standards used are based on the ISO 16845 compliance test plan set of standards. Currently, several test houses offer CAN compliance testing.

The revised CAN specifications have been standardized. ISO 11898-1 describes the "CAN security layer", ISO 11898-2 standardizes the "non-fault tolerant" CAN physical layer and ISO 11898-3 specifies the "fault tolerant CAN physical layer". The ISO 11992 series (truck and trailer interface) and ISO 11783 series (agricultural and forestry machinery) specify application profiles based on the SAE J1939 network approach. They are not compatible because the physical layer specifications are different.

The era of the pioneers of the CAN

Although CAN was originally developed for use in passenger cars, the first applications came from different market segments. In Northern Europe in particular, CAN was very popular from the start. In Finland, the elevator manufacturer Kone used the CAN bus. The Swedish engineering company Kvaser proposed CAN as an on-machine communication protocol for some textile machine manufacturers (Lindauer Dornier and Sulzer) and their suppliers. In this context, these companies founded the CAN Textile User Group, led by Lars-Berno Fredriksson. In 1989, they developed the communication principles that helped shape the "CAN Kingdom" development environment in the early 1990s. Although CAN Kingdom is not an application layer to the OSI reference model, it can be considered the ancestor upper layer CAN. protocols based on

In the Netherlands, Philips Medical Systems joined industrial CAN adopters with the decision to use CAN for the internal network of its X-ray machines. The "Philips Message Specification" (PMS), extensively developed by Tom Suters , represents the first application layer for CAN networks. Konrad Etschberger of the Weingarten University of Applied Sciences. He developed a similar protocol at the Steinbeis Transfer Center for Process Automation (STZP), which he managed himself.

Although the first standardized upper layer protocols appeared, most of the CAN pioneers used a monolithic approach. Communication functions, network management, and application code were a single piece of software. While some users would prefer a more modular approach, they would still have the disadvantage of a proprietary solution. The effort required to develop and maintain a higher layer CAN protocol was underestimated, which is still true to some extent today.

In the early 1990s, it was time to create a user group to promote the CAN protocol and encourage its use in many applications. In January 1992, Holger Zeltwanger, former editor of VMEbus magazine (publisher: Franzis), brought users and manufacturers together to create a neutral platform for the technical development of CAN and the commercialization of the serial bus system. Two months later, the international user and manufacturer group "CAN in Automation" (CiA) was officially founded. In those early days, the CAN bulletin was already published.

The first technical post, released after a few weeks, was about the physical layer: CiA recommended using only CAN transceivers that were ISO 11898 compliant at the time and not always compliant if they had gone completely.

One of CiA's first tasks was the specification of a CAN application layer. Using existing material from Philips Medical Systems and STZP, the "CAN Application Layer" (CAL), also known as the "Green Book", was co-developed with the help of other CiA members. When developing specifications using CAN, one of CiA's main tasks was to organize the exchange of information between CAN experts and those who wanted to learn more about CAN. Therefore, the international CAN conference (iCC) has been held since 1994.

Another scientific approach was followed at LAV: the German Association for Agricultural Machinery. A CAN-based agricultural vehicle bus (LBS) system has been developed since the late 1980s. But before the work could be successfully completed, the international committee decided on an American solution, J1939 (ISO 11783). This application profile, also based on the CAN, was defined by committees of the SAE Truck and Bus Association. J1939 is a non-modular approach that is very easy to use but also quite inflexible.

A CAN standardization for trucks was also developed. The network between truck and trailer is standardized as ISO 11992. This protocol is based on J1939 and should be used in Europe from 2006. The trend in motor vehicles is towards OSEK-COM and OSEK-NM, a network of communication protocols and Management. Both were submitted to international standardization. However, until now, car manufacturers have relied on proprietary software solutions.

From the theory to the practice

Of course, the semiconductor manufacturers that have implemented CAN cores in their microcontrollers are mainly focused on the automotive industry. Since the mid-1990s, Infineon Technologies (formerly Siemens Semiconductors) and Motorola (spun off as Freescale and later acquired by NXP) have supplied large numbers of CAN controllers to European car manufacturers and their suppliers. As the next wave, semiconductor vendors in the Far East have also been offering CAN controllers since the late 1990s. NEC released its legendary 72005 CAN chip in 1994, but it was too soon: the component was not a commercial success.

Since 1991, Mercedes-Benz has used CAN in its luxury cars. In a first step, the electronic control units in charge of managing the engine were connected via CAN. In 1995, BMW used a tree/star topology CAN network with five ECUs (Electronic Control Units) in its 7 Series cars. The control units needed for the body electronics followed in a second step. Two physically separate CAN networks have been implemented, usually connected via gateways. Other car manufacturers followed the example of their Stuttgart competitors and generally implemented two CAN networks in their cars. Today everyone implements multiple CAN networks in their vehicles.

In the early 1990s, engineers from the American mechanical engineering company Cincinnati Milacron founded a joint venture with Allen-Bradley and Honeywell Microswitch for a CAN-based control and communication design. But after a short time, the key members of the project changed jobs, and the joint venture collapsed. But Allen-Bradley and Honeywell continued the work separately. This led to the two upper layer protocols "Devicenet" and "Intelligent Distributed System" (SDS), which are quite similar, at least in the lower communication layers. In early 1994, Allen-Bradley submitted the Devicenet specification to the Open Devicenet Vendor Association (ODVA), increasing Devicenet's popularity. Honeywell didn't follow a similar path with SDS, making SDS more like an internal Honeywell Microswitch solution. Devicenet was specially developed for factory automation and is therefore a direct opponent of protocols such as Profibus-DP and Interbus. Devicenet offers plug-and-play functionality out of the box and has become the leading bus system in the US in this special market segment.

In Europe, several companies tried to use CAL. Although the CAL approach was academically sound and could be used in industrial applications, because CAL was a true application layer, each user had to design a new profile. CAL may be seen as a necessary academic step towards an application-independent CAN solution, but it never really caught on in practice.

Since 1993, a European consortium led by Bosch has been developing a prototype of what would later become CANopen as part of the Esprit Aspic project. It was a CAL-based profile for the internal network of production cells. On the academic side, Professor Dr. Gerhard Gruhler from the University of Reutlingen (Germany) and Dr. Mohammed Farsi from the University of Newcastle (UK) in one of the most successful Esprit activities of all time. Upon completion of the project, the CANopen specification was delivered to CiA for further development and maintenance. The completely revised CANopen communication profile was published in 1995 and became the most important standardized integrated network in Europe in just five years.

The first CANopen networks were used for internal machine communication, especially for the drives. CANopen offers a high level of flexibility and configurability. The upper layer protocol, which is used in very different application areas (industrial automation, marine electronics, military vehicles, etc.), has been internationally standardized as EN 50325-4 (2003). CANopen is mainly used in Europe. Injection molding machines in Italy, saws and woodworking machines in Germany, cigarette machines in Britain, cranes in France, handling machines in Austria, and watchmaking machines in Switzerland are just a few. examples of industrial automation and mechanical engineering. In the US, CANopen is recommended for forklifts and is used in mail sorting machines.

CANopen not only defines the application layer and a communication profile, but also a framework for programmable systems and various device, interface and application profiles. This is a major reason why entire branches of industry (eg printing machines, marine applications, medical systems) decided to use CANopen in the late 1990s.

With Devicenet and CANopen, two standardized application layers (IEC 62026-3 and EN 50325-4/5) are available, serving different industrial automation markets. Devicenet is optimized for factory automation and CANopen is especially suitable for networks embedded in all types of machine controls. This made proprietary app layers obsolete; The need to define application-specific application layers is history (except perhaps for some high-volume specialized embedded systems).

timed communication

In early 2000, a multi-company ISO working group defined a protocol for the time-controlled transmission of CAN frames. Dr. Bernd Müller, Thomas Führer and other Bosch associates, together with experts from the semiconductor industry and academic research, defined the "Time Triggered Communication on CAN" (TTCAN) protocol.

This CAN extension allowed the transmission of frames equidistant in time and the realization of the control via CAN, but also the use of CAN in x-by-wire applications. Since the CAN protocol has not changed, it is possible to transmit time-triggered and event-triggered frames on the same physical bus system. However, the auto industry has not adopted NAFTA. Industrial users also rarely made use of the time controlled protocol extension. Instead, they used synchronous transfer functions specified in CANopen, a type of soft, time-controlled method.

Approval by the authorities

Several proprietary CAN-based safety protocols were invented in the late 1990s. Safetybus p from Pilz, Germany survives. In 1999, CiA began to develop the CANopen security protocol, which was approved by the German TÜV. After strong political delegates in standardization committees, this CANopen extension (CiA 304) was internationally standardized in EN 50325-5 (2009).

Devicenet uses the CIP Safety protocol extension. Germanischer Lloyd, one of the world's leading classification societies, has approved the CANopen framework for marine applications (CiA 307). Among other things, this structure specifies the automatic changeover from a standard CANopen network to a redundant bus system. Currently, these functions are generalized and specified in the CiA 302 series of CANopen application layer additional functions.

CAN FD development

In early 2011, General Motors and Bosch began developing some enhancements to the CAN protocol to achieve higher performance. The automotive industry has been particularly affected by the end-of-line download of more and more software packages to 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 CAN by introducing a second bit rate was not new. Various scientists have published approaches since the early 2000s. But none of them were mature enough to convince automakers. In cooperation with other CAN experts, Bosch previously developed the CAN FD specification, which was published on November 13, 2012.^ºCAN International Conference at Hambach Castle, Germany.

During the standardization process within ISO, several academic weaknesses were found in the proposed error detection mechanisms. This required a revision of the CAN FD protocol and the introduction of additional measures (eg bit counter). Because of this, there is a non-ISO CAN FD protocol that is incompatible with the ISO CAN FD protocol standardized in ISO 11898-1.

Daimler's Dr. Mark Schreiner provided many tips and tricks for designing CAN FD networks. Many of his ideas were incorporated into the CiA 601 series of CAN FD nodes and system design recommendations and specifications.

CAN's future is bright

The lifetime of CAN technology has been extended with the introduction of the CAN FD protocol. The automotive industry has already begun to adopt the CAN FD protocol for the next generation of vehicle networks. All future applications are expected to use the CAN FD protocol. It doesn't matter if you need more bandwidth or not. You can still use CAN FD with a single bit time setting. The payload length can be set from 0 bytes to 64 bytes in any way.

For those who need more bandwidth and hybrid topologies, CiA has developed what is known as the Signal Enhancement Circuit (SIC) Transceiver Specification (CiA 601-4). The original idea came from Denso, a Japanese Tier 1 supplier.

CiA also developed the CANopen FD protocol based on the CAN FD sublayers. Higher baud rates and longer payloads (up to 64 bytes) are very welcome, especially for industrial motion control applications. CiA is also involved in the development of a CAN FD based application layer for commercial vehicles using existing parameter sets as specified in the SAE J1939 series.

The third generation CAN

In late 2018, CiA started developing CANXL, the third generation of CAN-based data link layer protocols. It was started at the request of Volkswagen. Carsten Schanze and Alexander Mueller provided many of the initial ideas. The maximum payload (data field) of CANXL is 2048 bytes. The separation of the priority function (11-bit priority field) and the address/content function (32-bit accept field) is also new. Dr. Arthur Mutter (Bosch) and Ralf Hildebrand (Fraunhofer) contributed many new ideas together with other experts.

In the meantime, several CiA think tanks are developing a series of CiA papers on CANXL. This includes a new approach to attaching physical media using PWM encoding instead of traditional NRZ encoding. NXP experts, led by Matthias Muth, presented the original proposal for PWM coding.

In addition to the lower layer CANXL specifications, including compliance test plans, there are CANXL device and network design recommendations, upper layer CANXL protocol specifications, and layer management specifications. In addition, CiA members specify a security protocol for the CANXL data link layer.