CAN history

CAN milestones

1983: Start of the Bosch internal project to develop an in-vehicle network
1986: Official introduction of CAN protocol
1987: First CAN controller chips from Intel and Philips Semiconductors
1991: Bosch’s CAN specification 2.0 published
1991: CAN Kingdom CAN-based higher-layer protocol introduced by Kvaser
1992: CAN in Automation (CiA) international users and manufacturers group established
1992: CAN Application Layer (CAL) protocol published by CiA
1992: First cars from Mercedes-Benz used CAN network
1993: ISO 11898 standard published
1994: 1st international CAN Conference (iCC) organized by CiA
1994: DeviceNet protocol introduction by Allen-Bradley
1995: ISO 11898 amendment (extended frame format) published
1995: CANopen protocol published by CiA
2000: Development of the time-triggered communication protocol for CAN (TTCAN)

CAN history

In February of 1986, Robert Bosch GmbH introduced the serial bus system Controller Area Network (CAN) 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. Also used 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 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 functionality – 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 developed by Bosch was introduced as ‘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 would grant 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 the 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, the ‘grandchildren’, very often different concepts of acceptance filtering and message handling have been implemented in the same module, making 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 standard 11898 for CAN was published in November of 1993. In addition to the CAN protocol, it also defined a physical layer for baud rates up to 1 Mbit/s. In parallel, a fault-tolerant way of data transmission via CAN was standardized in ISO 11519-2. In 1995, the ISO 11898 standard was extended by an addendum describing the 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 test patterns used are based on the internationally standardized test specification ISO 16845.

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 to some textile machine manufacturers (Lindauer Dornier and Sulzer) and their suppliers as the communications protocol within the machine. In this connection, under the leadership of Lars-Berno Fredriksson, the 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 of the 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 standardize the different solutions. In the early months of 1992, Holger Zeltwanger, at that time editor in chief of VMEbus magazine (publisher: Franzis), brought together users and manufacturers to establish a neutral platform for the technical enhancement of CAN as well as the marketing of the serial bus system.
In March of 1992, the ‘CAN in Automation’ (CiA) international users and manufacturers group was officially founded. The first technical publication, already released after only a few weeks, was about the physical layer: CiA recommended to only use CAN transceivers that comply to ISO 11898. By now the manufacturer-specific RS485 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 the CAN experts and the ones who wanted to become more knowledgeable on CAN. Therefore, since 1994, an annual international CAN Conference (iCC) is held.

Another academic approach was pursued in the LAV, an agricultural vehicle association. Since the late 1980s, a CAN-based bus system for agricultural vehicles (LBS) was being 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 it is also very inflexible.

Also for trucks the standardization of CAN has developed. The networking between truck and trailer has been 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 the 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 the European passenger car manufacturers and their suppliers. As a next wave, Far Eastern semiconductor vendors also offered CAN controllers since the late 1990s. NEC came out with their legendary CAN chip 72005 in 1994, but in this case that was 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. Now BMW, Fiat, Renault, Saab, Volkswagen, and Volvo use CAN 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 should 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 features 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.
CANopen is being used especially in Europe. Injection modling 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 now available, addressing different 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 is history (except, perhaps, for some specialized high-volume embedded systems).

What’s ahead for CAN

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 and 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, which now has to be implemented in silicon, will not only allow 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.

When taken into account that CAN is still at the beginning of a global market penetration, even conservative estimates show further growth for this bus system for the next ten to fifteen years. This is underlined by the fact that the US and Far Eastern car manufacturers are just starting to use CAN in the serial production of their vehicles over the next few years. Furthermore, new potentially high-volume applications (e.g. entertainment) are in the pipeline – not only in passenger cars but also in domestic appliances.

Several enhancements regarding the approval for different safety-relevant and safety-critical applications can be expected for the higher layer protocols. The German professional association BIA and the German safety standards authority TÜV have already certified some of the proprietary CAN-based safety systems. CANopen-Safety is the first standardized CAN solution to earn a tentative BIA approval. DeviceNet-Safety will follow shortly. Approval of the CANopen framework for maritime applications by one of the leading classification societies worldwide, Germanischer Lloyd, is in preparation. Among other things, this specification defines the automatic switchover from a CANopen network to a redundant bus system.

To top