History of CAN technology

The very first documents published by Bosch describing the CAN protocol (CAN Specification 1.0), C Reference CAN model and SAE paper

In February of 1986, Robert Bosch GmbH introduced the Controller Area Network (CAN) serial bus system at the Society of Automotive Engineers (SAE) congress. It was the hour of birth for one of the most successful network protocols ever. Today, almost every new passenger car manufactured in Europe is equipped with at least one CAN network. Used also in other types of vehicles, from trains to ships, as well as in industrial controls, CAN is one of the most dominating bus protocols – maybe even the leading serial bus system worldwide.

From the idea to the first chip

In the early 1980s, engineers at Bosch were evaluating existing serial bus systems regarding their possible use in passenger cars. Because none of the available network protocols were able to fulfill the requirements of the automotive engineers, Uwe Kiencke started the development of a new serial bus system in 1983.

The new bus protocol was mainly supposed to add new functionalites – the reduction of wiring harnesses was just a by-product, but not the driving force behind the development of CAN. Engineers from Mercedes-Benz got involved early on in the specification phase of the new serial bus system, and so did Intel as the potential main semiconductor vendor. Professor Dr. Wolfhard Lawrenz from the University of Applied Science in Braunschweig-Wolfenbüttel, Germany, who had been hired as a consultant, gave the new network protocol the name 'Controller Area Network'. Professor Dr. Horst Wettstein from the University of Karlsruhe also provided academic assistance.

In February of 1986, CAN was born: at the SAE congress in Detroit, the new bus system was introduced as the 'Automotive Serial Controller Area Network'. Uwe Kiencke, Siegfried Dais, and Martin Litschel introduced the multi-master network protocol. It was based on a non-destructive arbitration mechanism, which grants bus access to the message with the highest priority without any delays. There was no central bus master. Furthermore, the fathers of CAN – the individuals mentioned above plus Bosch employees Wolfgang Borst, Wolfgang Botzenhard, Otto Karl, Helmut Schelling, and Jan Unruh – had implemented several error detection mechanisms. The error handling also included the automatic disconnection of faulty bus nodes in order to keep up the communication between the remaining nodes. The transmitted messages were not identified by the node address of the transmitter or the receiver of the message (as in almost all other bus systems), but rather by their content. The identifier representing the content of the message also had the function of specifying the priority of the message within the system.

A lot of presentations and publications describing this innovative communication protocol followed, until in mid 1987 – two months ahead of schedule – Intel delivered the first CAN controller chip, the 82526. It was the very first hardware implementation of the CAN protocol. In only four years, an idea had become reality. Shortly thereafter, Philips Semiconductors introduced the 82C200. These two earliest ancestors of CAN controllers were quite different concerning acceptance filtering and message handling. On one hand, the FullCAN concept favored by Intel required less CPU load from the connected micro-controller than the BasicCAN implementation chosen by Philips. On the other hand, the FullCAN device was limited regarding the number of messages that could be received. The BasicCAN controller also required less silicon. In today’s CAN controllers, a mixture of both concepts of acceptance filtering and message handling are implemented. This made the misleading terms BasicCAN and FullCAN obsolete.

Standardization and conformity

The Bosch CAN specification (version 2.0) was submitted for international standardization in the early 1990s. After several political disputes, especially involving 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, it also standardized a physical layer for bit-rates up to 1 Mbit/s. In parallel, a low-power, fault-tolerant way of data transmission via CAN was standardized in ISO 11519-2. This was never implemented due to weaknesses in the standard. In 1995, the ISO 11898 standard was extended by an addendum describing the extended frame format using 29-bit CAN identifier.

Unfortunately, all published CAN specifications and standardizations contained errors or were incomplete. To avoid incompatible CAN implementations, Bosch made sure (and still does) that all CAN chips comply with the Bosch CAN reference model. Furthermore, the University of Applied Science in Braunschweig/Wolfenbüttel, Germany, has been conducting CAN conformity testing for several years, lead by Prof. Lawrenz. The used test patterns are based on the internationally standardized test specification ISO 16845. Today, several test houses offer CAN conformance testing services.

Revised CAN specifications have been standardized. ISO 11898-1 describes the ‘CAN data link layer’, ISO 11898-2 defines the ‘Non-fault-tolerant’ CAN physical layer’, and ISO 11898-3 specifies the ‘Fault-tolerant CAN physical layer’. ISO standards 11992 (truck and trailer interface) and 11783 (agriculture and forestry machines) both define CAN-based application profiles based on the US-protocol J1939, however they are not compatible.

The time of the CAN pioneers

Although CAN was originally developed to be used in passenger cars, the first applications came from different market segments. Especially in northern Europe, CAN was already very popular in its early days. In Finland, the elevator manufacturer Kone used the CAN bus. The Swedish engineering office Kvaser suggested CAN as a communications protocol within machines to some textile machine manufacturers (Lindauer Dornier and Sulzer) and their suppliers. In this connection, under the leadership of Lars-Berno Fredriksson, these companies founded the 'CAN Textile User's Group'. By 1989, they had developed communication principles that helped to shape the development environment 'CAN Kingdom' in the early 1990s. Although CAN Kingdom is not an application layer with respect to the OSI reference model, it can be considered the ancestor of the CAN-based higher-layer protocols.

In the Netherlands, Philips Medical Systems had joined the industrial CAN users by deciding to use CAN for the internal networking of their X-ray machines. The 'Philips Message Specification' (PMS), mainly developed by Tom Suters, represented the first application layer for CAN networks. Professor Dr. Konrad Etschberger from the University of Applied Science in Weingarten, Germany, had almost identical ideas. In the Steinbeis Transfer Center for Process Automation (STZP), which he was in charge of, he developed a similar protocol.

In spite of the fact that the first standardized higher-layer protocols started to emerge, most CAN pioneers used a monolithic approach. Communication functions, network management, and application code were one piece of software. Even though some users would have preferred a more modular approach, they still would have had the disadvantage of a proprietary solution. The necessary efforts for enhancing and maintaining a CAN higher layer protocol had been underestimated – which is still partly true today.

In the early 1990s, the time was right to found a user’s group to promote the CAN protocol and to foster its use in many applications. In January of 1992, Holger Zeltwanger, at that time editor of the VMEbus magazine (publisher: Franzis), brought users and manufacturers together to establish a neutral platform for the technical enhancement of CAN as well as the marketing of the serial bus system. Two month later, the 'CAN in Automation' (CiA) international users and manufacturers group was officially founded. In these early days, the CAN Newsletter was already published.

The first technical publication, released after only a few weeks, was about the physical layer: CiA recommended using only CAN transceivers that comply to ISO 11898. Today, the manufacturer-specific EIA-485 transceivers, which were quite commonly used in CAN networks at that time and were not always compatible, should have completely vanished.

One of the first tasks of the CiA was the specification of a CAN application layer. Using the existing material from Philips Medical Systems and STZP, along with the help of other CiA members, the 'CAN Application Layer' (CAL), also called the 'Green Book', was developed. While developing specifications using CAN, one of the main tasks of the CiA was to organize the exchange of information between CAN experts and the ones who wanted to become more knowledgeable on CAN. Therefore, since 1994, the international CAN Conference (iCC) is held.

Another academic approach was pursued in the LAV: the German agricultural vehicle association. Since the late 1980s, a CAN-based bus system for agricultural vehicles (LBS) had been developed. But before the work could be successfully completed, the international committee had decided in favor of a US solution, J1939 (ISO 11783). This application profile, which is also based on CAN, was defined by the committees of the SAE Truck and Bus Association. J1939 is a non-modular approach that is very easy to use, but is also quite inflexible.

A standardization of CAN was also developed for trucks. The networking between truck and trailer is standardized as ISO 11992. This protocol is based on J1939 and must be used in Europe as of 2006. The trend for automotive vehicles goes toward OSEK-COM and OSEK-NM, a communication protocol and a network management. Both have been submitted for international standardization. Automotive builders however have been using proprietary software solutions so far.

From theory to practice

Of course, semiconductor vendors who implemented CAN modules into their devices are mainly focused on the automotive industry. Since the mid 1990s, Infineon Technologies (formerly Siemens Semiconductors) and Motorola have shipped large quantities of CAN controllers to European passenger car manufacturers and their suppliers. As a next wave, Far Eastern semiconductor vendors have also offered CAN controllers since the late 1990s. NEC came out with their legendary CAN chip 72005 in 1994, but in this case they were too early – the device was a no-go.

Since 1992, Mercedes-Benz has been using CAN in their upper-class passenger cars. As a first step, the electronic control units taking care of the engine management were connected via CAN. In a second step, the control units needed for body electronics followed. Two physically separate CAN bus systems were implemented, connected via gateways. Other car manufacturers have followed the example of their peers from Stuttgart and now usually also implement two CAN networks in their passenger cars. Nowadays, they all implement multiple CAN networks in their vehicles.

In the early 1990s, engineers at the US mechanical engineering company Cincinnati Milacron started a joint venture together with Allen-Bradley and Honeywell Microswitch regarding a control and communications project based on CAN. However, after a short while, important project members changed jobs and the joint venture fell apart. But Allen-Bradley and Honeywell continued the work separately. This led to the two higher layer protocols 'DeviceNet' and 'Smart Distributed System' (SDS), which are quite similar, at least in the lower communication layers. In early 1994, Allen-Bradley turned the DeviceNet specification over to the 'Open DeviceNet Vendor Association' (ODVA), which boosted the popularity of DeviceNet. Honeywell failed to go a similar way with SDS, which makes SDS look more like an internal solution by Honeywell Microswitch. DeviceNet was developed especially for factory automation and therefore presents itself as a direct opponent to protocols like Profibus-DP and Interbus. Providing off-the-shelf plug-and-play functionality, DeviceNet has become the leading bus system in this particular market segment in the US.

In Europe, several companies tried to use CAL. Although the CAL approach was academically correct and it was possible to use it in industrial applications, every user needed to design a new profile because CAL was a true application layer. CAL can be looked at as a necessary academic step to an application-independent CAN solution, but it never gained wide acceptance in the field.

Since 1993, within the scope of the Esprit project ASPIC, a European consortium lead by Bosch had been developing a prototype of what would become CANopen. It was a CAL-based profile for the internal networking of production cells. On the academic side, Professor Dr. Gerhard Gruhler from the University of Applied Science in Reutlingen (Germany) and Dr. Mohammed Farsi from the University of Newcastle (UK) participated in what was one of the most successful Esprit activities ever. After the completion of the project, the CANopen specification was handed over to the CiA for further development and maintenance. In 1995, the completely revised CANopen communications profile was released and within only five years became the most important standardized embedded network in Europe.

The first CANopen networks were used for internal machine communication, especially for drives. CANopen offers very high flexibility and configurability. The higher layer protocol, which has been used in several very different application areas (industrial automation, maritime electronics, military vehicles, etc.) has in the meantime been internationally standardized as EN 50325-4 (2003). CANopen is being used especially in Europe. Injection molding machines in Italy, wood saws and machines in Germany, cigarette machines in Great Britain, cranes in France, handling machines in Austria, and clock-manufacturing machines in Switzerland are just a few examples within industrial automation and machine building. In the United States, CANopen is being recommended for fork lifts and is being used in letter sorting machines.

CANopen not only defines the application layer and a communication profile, but also a framework for programmable systems as well as different device, interface, and application profiles. This is an important reason why whole industry segments (e.g. printing machines, maritime applications, medical systems) decided to use CANopen during the late 1990s.

With DeviceNet and CANopen, two standardized (EN 50325) application layers are available, addressing different industrial automation markets. DeviceNet is optimized for factory automation and CANopen is especially well suited for embedded networks in all kinds of machine controls. This has made proprietary application layers obsolete; the necessity to define application-specific application layers has become history (except, perhaps, for some specialized high-volume embedded systems).

Time-triggered communication

In the beginning of 2000, an ISO task force involving several companies defined a protocol for a time-triggered transmission of CAN messages. Dr. Bernd Mueller, Thomas Fuehrer, and other Bosch employees, together with experts from the semiconductor industry and from academic research defined the protocol 'Time-triggered communication on CAN' (TTCAN).

This CAN extension enabled the time-equidistant transmission of messages and the implementation of closed loop control via CAN, but also the use of CAN in x-by-wire applications. Because the CAN protocol has not been altered, it is possible to transmit time-triggered as well as event-triggered messages via the same physical bus system. However, the automotive industry has not adopted TTCAN. Also, industrial users have rarely made use of the time-triggered protocol extension. They used synchronous transmission functions instead, specified in CANopen, so-to-speak a soft time-triggering method.

Approval by authorities

In the late 90s, several proprietary CAN-based safety protocols were invented. Survived has the Safetybus p by Pilz, Germany. In the year 1999, CiA started to develop the CANopen-Safety protocol, which has been approved by the German TÜV. After heavy political deputes in the standardization bodies, this CANopen extension (CiA 304) was internationally standardized in EN 50325-5 (2009).

DeviceNet uses the CIP Safety protocol extension. The CANopen framework for maritime applications (CiA 307) was approved by one of the leading classification societies worldwide, Germanischer Lloyd. Among other things, this specification defines the automatic switchover from a CANopen network to a redundant bus system. These functions are nowadays generalized and specified in the CiA 302 series of additional CANopen application layer functions.

CAN FD development

At the beginning of 2011, General Motors and Bosch started the development of some CAN protocol improvements regarding higher throughput. The automotive industry suffered in particular when downloading increasing software packages end-of-line into the electronic control units (ECU). This time-consuming task had to be shortened by a higher performing communication system. The idea to increase the transmission speed of CAN by introducing a second bit-rate was not new. Several academics had published approaches since the beginning of 2000. But none of them were mature enough to convince carmakers. In cooperation with other CAN experts, Bosch pre-developed the CAN FD specification, officially introduced in 2012 on the 13th international CAN Conference in the Hambach Castle, Germany.

During the standardization process within ISO, several academic weaknesses in the proposed error detection mechanisms were found. This required a review of the CAN FD protocol and the introduction of additional safeguards (e.g. stuff-bit counter). This is the reason why there is a non-ISO CAN FD protocol, which is incompatible to the ISO CAN FD protocol standardized in ISO 11898-1.

Future of CAN

The future of CAN is bright. The lifetime of CAN technology might have been prolonged by 10 to 20 years with the introduction of the CAN FD protocol. The automotive industry has already started to adopt the CAN FD protocol for the next generation of in-vehicle networks. It can be expected that all future applications will make use of the CAN FD protocol. It doesn't matter if they require higher bandwidth or not. You can still use CAN FD with a single bit-timing setting. The payload length is configurable from 0 to 64 byte anyway.

CiA currently develops the CANopen FD protocol, which is based on the CAN FD lower-layers. In particular for industrial motion control application, higher transmission rates and longer payloads (up to 64 byte) are very welcome. CiA is also involved in the development of a CAN FD based application layer for commercial vehicles using the existing Parameter Groups as specified in the SAE J1939 series.