Time-triggered CAN

The TTCAN (time-triggered CAN) protocol (standardized in ISO 11898-4) is a higher

layer protocol on top of the CAN (Controller Area Network) data link layer as
specified in ISO 11898-1. It may use standardized CAN physical layers such as
specified in ISO 11898-2 (high-speed transceiver) or in ISO 11898-3 (fault-tolerant
low-speed transceiver). 
Time-triggered communication means that activities are triggered by the elapsing
of time segments. In a time-triggered communication system all points of time of
message transmission are defined during the development of a system. A time-
triggered communication system is ideal for applications in which the data traffic is
of a periodic nature.

TTCAN benefits

TTCAN provides mechanisms to schedule CAN messages in a time-triggered way as

well as in an event-triggered way. This allows using CAN-based networks for
closed-loop control. Also the real-time performance in CAN-based in-vehicle
networks increases with the use of TTCAN.
In vehicles data traffic must usually be both event-triggered (e.g. a temperature
change in the cooling mechanism) and time-triggered (e.g. the status of the
brakes). In order not to have to develop two different network systems the ISO
defined the TTCAN protocol.

Basic TTCAN functionality

The TTCAN protocol is realized in software in a higher layer on top of CAN. This is
why in a TTCAN network messages can be transmitted both event-triggered as well
as time-triggered. The transmitted frames do not need any additional overhead in
the CAN frame. The time-triggered control and thus the synchronization of the
involved control units within the network are done via a reference message. All
participants of the TTCAN network identify the reference message by its identifier.
As soon as the first bit of the frame (Start of Frame: SOF) is recognized, the local
time unit is synchronized. The accuracy of the local time units depend only on the
physical signal propagation of the bus line and is thus neglectable. The individual
TTCAN participants are configured to know when to send their frames after having
received the reference frame. 
The time between two reference frames is called the basic cycle. Basic cycles are
not always identical in order to be able to transmit messages at different periodic
frequencies. The system matrix comprises several basic cycles and is repeated
indefinitely until the vehicle is turned off. 
For some applications it is necessary that the reference frame is sent corresponding
to an event. For these cases a bit is inserted in the basic cycle, which discontinues
the periodic transmission of messages until the event has taken place. This is done
e.g. to synchronize communication and motor rotation.

Within a basic cycle there are exclusive windows, during which only one node may
send a frame. Apart from that there are free windows and arbitrating windows, for
which the nodes compete for bus access just as in the regular CAN communication.
Several arbitrating windows can be merged (merged windows). The end of an
arbitrating window is always predictable. Thus the advantages of event-triggered
communication can be combined with those of time-triggered communication.
This is especially interesting for off-highway vehicles such as forestry vehicles or
forklifts. 

These vehicles often use the higher-layer protocol CANopen. Therefore there are
intentions of implementing TTCAN-specific objects in the CANopen standard. Also a
specific TTCAN transmit mode for process data objects (PDO) is planned. CANopen
networks are also used for separate vehicle add-ons such as fire fighting
equipment, cranes and add-on devices for municipal vehicles.
The sending of CAN frames in TTCAN (level 1) between two reference frames is
triggered by the local time units. Since there may be minimum time differences
despite the initial synchronization, a system designer may implement a level 2
TTCAN network. In level 2 TTCAN a reference frame includes a time-stamp
(Master_Ref_Mark). This means that after at least two times receiving of the
reference frame the nodes can resynchronize according to the time-stamp. Thus a
synchronization accuracy of 1 µs is achievable. This should suffice even for high
requirements of vehicle builders.

Should the sender of the reference frame fail, another node automatically takes
over the task of sending it. Up to eight potential time givers are installable. In case
a higher-ranking time master has been replaced by a lower-ranking time master
but returns to the network, it automatically tries to become time master again. The
TTCAN specifications provide the procedure of the return/take over of a time
master.

If the time stamp is provided by an external clock (e.g. GPS), the time is given as
part of a second. An internal time base in regular operation depends of the bit rate
of the CAN network. With an external time base even several TTCAN networks of
other systems may be synchronized with a TTCAN network. 

The TTCAN protocol also defines an error level state machine as well as several
error modes. The ISO 11898-4 also defines all "visible" interfaces. Scheduling
tables are locally implemented in every node and must be configured before system
start-up.

TTCAN implementations

After the ISO had submitted their TTCAN standard proposal for international
standardization the first few manufacturers started implementing the TTCAN
protocol. Bosch had already implemented it in an FPGA successfully and presented
it at a TTCAN workshop of the CAN in Automation (CiA) international users and
manufacturers group. Due to market responses Bosch has by now implemented the
TTCAN module in a chip. The TTCAN stand-alone chip with integrated TTCAN level 1
and level 2 (with time correction) is pin-compatible to the company's CAN controller
CC170 and Intel's 82527. It is available for the evaluation of TTCAN interfaces and
for the development of TTCAN-compatible control units and software tools (e.g. bus
analyzers and configurators). The controller provides different interfaces to host
controllers by Intel and Motorola. Samples have been available since July 2003.
Basically all CAN controllers that support single-shot mode or are able to support
the cancellation of a transmission request are able to support level 1 of TTCAN in
software. For level 2 they additionally require the ability to time-stamp the Start of
Frame-bit and send the time-stamp within the very same frame. For reasons of
performance enhancement it makes sense to realize the protocol functions in
hardware. 
First CAN controllers with partial TTCAN support have been announced by Atmel.
The 8-bit T89C51CC01/2 provides 15 message objects that are adjustable via filter
masks. The message objects may optionally be transformed to a FIFO, which
prevents the erasure of received but not yet processed data.

The NEC CAN microcontroller family has provided the hardware requirements for
TTCAN since the mid-nineties with the patented SOF-synchronization, which is
necessary to implement TTCAN. The company is still working on a hardware version
of a standalone TTCAN module. 

Hitachi has implemented the protocol in a chip, which is being tested by an

independent institute for conformity to the standard.
CiA members are currently working on extending the CANopen standard in order to
enable the usage of TTCAN hardware within CANopen networks. This entails the
definition of a further transmission mode for PDOs and a new communication object
(TREF). The CANopen extensions are due for publication with the official release of
the TTCAN standard.

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.

CAN physical layer

 Bit encoding
 Bit-timing and synchronization
 Interdependency of data rate and bus length
 Physical media
 Network topology
 Bus access
 Physical layer standards

1. ISO 11898-2 (high-speed)

2. ISO 11898-3 (fault-tolerant)

3. SAE J2411 (single-wire)

4. ISO 11992 (point-to-point)

5. Others

The Controller Area Network (CAN) protocol defines the data link layer and part of
the physical layer in the OSI model, which consists of seven layers. The
International Standards Organization (ISO) defined a standard, which incorporates
the CAN specifications as well as a part of physical layer: the physical signaling,
which comprises bit encoding and decoding (Non Return to Zero, NRZ) as well as
bit-timing and synchronization.

Bit encoding

In the chosen Non Return to Zero (NRZ) bit coding the signal level remains
constant over the bit time and thus just one time slot is required for the
representation of a bit (other methods of bit encoding are e. g. Manchester or
Pulse-width-modulation). The signal level can remain constant over a longer period
of time; therefore measures must be taken to ensure that the maximum
permissible interval between two signal edges is not exceeded. This is important for
synchronization purposes. Bit stuffing is applied by inserting a complementary bit
after five bits of equal value. Of course the receiver has to un-stuff the stuff-bits so
that the original data content is processed.

NRZ compared with Manchester bit representation

Bit-timing and synchronization

On the bit-level (OSI layer 1, physical layer) CAN uses synchronous bit
transmission. This enhances the transmitting capacity but also means that a
sophisticated method of bit synchronization is required. While bit synchronization in
a character-oriented transmission (asynchronous) is performed upon the reception
of the start bit available with each character, a synchronous transmission protocol
there is just one start bit available at the beginning of a frame. To enable the
receiver to correctly read the messages, continuous resynchronization is required.
Phase buffer segments are therefore inserted before and after the nominal sample
point within a bit interval.

The CAN protocol regulates bus access by bit-wise arbitration. The signal
propagation from sender to receiver and back to the sender must be completed
within one bit-time. For synchronization purposes a further time segment, the
propagation delay segment, is needed in addition to the time reserved for
synchronization, the phase buffer segments. The propagation delay segment takes
into account the signal propagation on the bus as well as signal delays caused by
transmitting and receiving nodes.

Nominal bit-time

Two types of synchronization are distinguished: hard synchronization at the start of

a frame and resynchronization within a frame.

 After a hard synchronization the bit time is restarted at the end of the sync
segment. Therefore the edge, which caused the hard synchronization, lies
within the sync segment of the restarted bit time.
 Resynchronization shortens or lengthens the bit time so that the sample point is
shifted according to the detected edge

The device designer may program the bit-timing parameters in the CAN controller
by means of the appropriate registers.
Interdependency of data rate and bus length

Depending on the size of the propagation delay segment the maximum possible bus
length at a specific data rate (or the maximum possible data rate at a specific bus
length) can be determined. The signal propagation is determined by the two nodes
within the system that are farthest apart from each other. It is the time that it
takes a signal to travel from one node to the one farthest apart (taking into account
the delay caused by the transmitting and receiving node), synchronization and the
signal from the second node to travel back to the first one. Only then can the first
node decide whether its own signal level (recessive in this case) is the actual level
on the bus or whether it has been replaced by the dominant level by another node.
This fact is important for bus arbitration.

Some modern transceivers support no low data rates. Therefore on acquisition of

transceivers the maximal required network length must be considered.

Physical media

This clause is most interesting for system designers.

The basis for transmitting CAN messages and for competing for bus access is the
ability to represent a dominant and a recessive bit value. This is possible for
electrical and optical media so far. Also powerline and wireless transmission is
possible.
For electrical media the differential output bus voltages are defined in ISO 11898-2
and ISO 11898-3, in SAE J2411, and ISO 11992 (see below). 
With optical media the recessive level is represented by "dark" and the dominant
level by "light".
The physical media most commonly used to implement CAN networks is a
differentially driven pair of wired with common return. For vehicle body electronics
single wire bus lines are also used. Some efforts have been made to develop a
solution for the transmission of CAN signals on the same line as the power supply. 

The parameters of the electrical medium become important when the bus length is
increased. Signal propagation, the line resistance and wire cross sections are
factors when dimensioning a network. In order to achieve the highest possible bit
rate at a given length, a high signal speed is required. For long bus lines the
voltage drops over the length of the bus line. The wire cross section necessary is
calculated by the permissible voltage drop of the signal level between the two
nodes farthest apart in the system and the overall input resistance of all connected
receivers. The permissible voltage drop must be such that the signal level can be
reliably interpreted at any receiving node.

The consideration of electromagnetic compatibility and choice of cables and

connectors belongs also to the tasks of a system integrator.

assumed line length 100 m

Specific signal propagation time (ns/m) Maximum bit rate (kbit/s)

5.0 80

5.5 73

6.0 67

6.5 62

7.0 58

Network topology

This clause is most interesting for system designers.

Electrical signals on the bus are reflected at the ends of the electrical line unless
measures against that have been taken. For the node to read the bus level correctly
it is important that signal reflections are avoided. This is done by terminating the
bus line with a termination resistor at both ends of the bus and by avoiding
unnecessarily long stubs lines of the bus. The highest possible product of
transmission rate and bus length line is achieved by keeping as close as possible to
a single line structure and by terminating both ends of the line. Specific
recommendations for this can be found in the according standards (i.e. ISO 11898-
2 and -3).
It is possible to overcome the limitations of the basic line topology by using
repeaters, bridges or gateways. A repeater transfers an electrical signal from one
physical bus segment to another segment. The signal is only refreshed and the
repeater can be regarded as a passive component comparable to a cable. The
repeater divides a bus into two physically independent segments. This causes an
additional signal propagation time. However, it is logically just one bus system. 
A bridge connects two logically separated networks on the data link layer (OSI layer
2). This is so that the CAN identifiers are unique in each of the two bus systems.
Bridges implement a storage function and can forward messages or parts thereof in
an independent time-delayed transmission. Bridges differ from repeaters since they
forward messages, which are not local, while repeaters forward all electrical signals
including the CAN identifier.
A gateway provides the connection of networks with different higher-layer
protocols. It therefore performs the translation of protocol data between two
communication systems. This translation takes place on the application layer (OSI
layer 7).

Bus access

The connection between a CAN controller chip and a two-wire differential bus a
variety of CAN transceiver chips according to different physical layer standards are
available (see below ISO 11898-2 and -3, etc.).
This interface basically consists of a transmitting amplifier and a receiving amplifier
(transceiver = transmit and receive). Aside from the adaptation of the signal
representation between chip and bus medium the transceiver has to meet a series
of additional requirements. As a transmitter it provides sufficient driver output
capacity and protects the on-controller-chip driver against overloading. It also
reduces electromagnetic radiation. As a receiver the CAN transceiver provides a
defined recessive signal level and protects the on-controller-chip input comparator
against over-voltages on the bus lines. It also extends the common mode range of
the input comparator in the CAN controller and provides sufficient input sensitivity.
Furthermore it detects bus errors such as line breakage, short circuits, shorts to
ground, etc. A further function of the transceiver can also be the galvanic isolation
of a CAN node and the bus line.
Physical layer standards

ISO 11898-2 high speed

ISO 11898-2 is the most used physical layer standard for CAN networks. It
describes the bus access unit (implemented as CAN high-speed transceiver)
functions as well as some medium-dependent interface features. 
In this standard the data rate is defined up to 1 Mbit/s with a theoretically possible
bus length of 40 m at 1 Mbit/s. The high-speed standard specifies a two-wire
differential bus whereby the number of nodes is limited by the electrical busload.
The characteristic line impedance is 120 Ohm, the common mode voltage ranges
from -2 V on CAN_L to +7 V on CAN_H. The nominal specific propagation delay of
the two-wire bus line is specified at 5 ns/m. All these figures are valid only for a 1
Mbit/s transfer rate and a maximum network length of 40 m.
In order to achieve physical compatibility all nodes in the network must use the
same or a similar bit-timing. For automotive applications the SAE published the SAE
J2284 specification. For industrial and other non-automotive applications the
system designer may use the CiA 102 recommendation. This specification defines
the bit-timing for rates of 10 kbit/s to 1 Mbit/s. It also provides recommendations
for bus lines and for connectors and pin assignment.

ISO 11898-3 fault-tolerant

An alternative form of bus interfacing and arrangement of bus lines is specified in
ISO 11898-3 (fault-tolerant CAN). This standard is mainly used for body electronics
in the automotive industry. Since for this specification a short network was
assumed, the problem of signal reflection is not as important as for long bus lines.
This makes the use of an open bus line possible. 
This means low bus drivers can be used for networks with very low power
consumption and the bus topology is no longer limited to a linear structure. It is
possible to transmit data asymmetrically over just one bus line in case of an
electrical failure of one of the bus lines. 
ISO 11898-3 defines data rates up to 125 kbit/s with the maximum bus length
depending on the data rate used and the busload. Up to 32 nodes per network are
specified. The common mode voltage ranges between -2 V and +7 V. The power
supply is defined at 5 V. 
Transceiver chips, which support this standard, are available from several
companies. The fault-tolerant transceivers support the complete error management
including the detection of bus errors and automatic switching to asymmetrical
signal transmission.

SAE J2411 single wire

The single-wire standard SAE J2411 is also for CAN network applications with low
requirements regarding bit rate and bus length. The communication takes place via
just one bus line with a nominal data rate of 33,3 kbit/s (83,3 kbit/s in high-speed
mode for diagnostics). The standard defines up to 32 nodes per network. The main
application area of this standard is in comfort electronics networks in motor
vehicles. 
An unshielded single wire is defined as the bus medium. A linear bus topology
structure is not necessary. The standard includes selective node sleep capability,
which allows regular communication to take place among several nodes while
others are left in a sleep state. Transceivers for this standard are available, too. 

ISO 11992 point-to-point

An additional approach to using CAN low-speed networks with fault-tolerant
functionality is specified in the ISO 11992 standard. It defines a point-to-point
connection for use in e.g. towing vehicles and their trailers. For one vehicle with
one trailer, a point-to-point connection is defined. For one vehicle with two trailers,
a daisy-chain connection is defined. The nominal data rate is 125 kbit/s with a
maximum bus line length of 40 m. The standard defines the bus error management
and the supply voltage (12 V or 24 V). An unshielded twisted pair of wires is
defined as the bus medium. 

Others
Not standardized are fiber-optical transmissions of CAN signals. Due to the directed
coupling into the optical media, the transmitting and receiving lines must be
provided separately. Also, each receiving line must be externally coupled with each
transmitting line in order to ensure bit monitoring. A star coupler can implement
this. The use of a passive star coupler is possible with a small number of nodes,
thus this kind of network is limited in size. The extension of a CAN network with
optical media is limited by the light power, the power attenuation along the line and
the star coupler rather than the signal propagation as in electrical lines. 
Advantages of optical media are emission- and immission-free transmission and
complete galvanic decoupling. The electrically neutral behavior is important for
applications in explosive or electromagnetically disturbed environments.

Download the information as pdf (184 KiB)

CAN protocol
The CAN protocol is an international standard defined in the ISO 11898. Beside the
CAN protocol itself the conformance test for the CAN protocol is defined in the ISO
16845, which guarantees the interchangeability of the CAN chips.

Principles of data exchange

CAN is based on the “broadcast communication mechanism”, which is based on a

message-oriented transmission protocol. It defines message contents rather than
stations and station addresses. Every message has a message identifier, which is
unique within the whole network since it defines content and also the priority of the
message. This is important when several stations compete for bus access (bus
arbitration).

As a result of the content-oriented addressing scheme a high degree of system and

configuration flexibility is achieved. It is easy to add stations to an existing CAN
network without making any hardware or software modifications to the present
stations as long as the new stations are purely receivers. This allows for a modular
concept and also permits the reception of multiple data and the synchronization of
distributed processes. Also, data transmission is not based on the availability of
specific types of stations, which allows simple servicing and upgrading of the
network.
Real-time data transmission

In real-time processing the urgency of messages to be exchanged over the network

can differ greatly: a rapidly changing dimension, e.g. engine load, has to be
transmitted more frequently and therefore with less delays than other dimensions,
e.g. engine temperature.

The priority, at which a message is transmitted compared to another less urgent

message, is specified by the identifier of each message. The priorities are laid down
during system design in the form of corresponding binary values and cannot be
changed dynamically. The identifier with the lowest binary number has the highest
priority.

Bus access conflicts are resolved by bit-wise arbitration of the identifiers involved
by each station observing the bus level bit for bit. This happens in accordance with
the wired-and-mechanism, by which the dominant state overwrites the recessive
state. All those stations (nodes) with recessive transmission and dominant
observation lose the competition for bus access. All those "losers" automatically
become receivers of the message with the highest priority and do not re-attempt
transmission until the bus is available again.

Transmission requests are handled in order of their importance for the system as a
whole. This proves especially advantageous in overload situations. Since bus access
is prioritized on the basis of the messages, it is possible to guarantee low individual
latency times in real-time systems.

Message frame formats

The CAN protocol supports two message frame formats, the only essential
difference being in the length of the identifier. The “CAN base frame” supports a
length of 11 bits for the identifier, and the “CAN extended frame” supports a length
of 29 bits for the identifier.

CAN base frame format

A CAN base frame message begins with the start bit called "Start Of Frame (SOF)",
this is followed by the "Arbitration field" which consist of the identifier and the
"Remote Transmission Request (RTR)" bit used to distinguish between the data
frame and the data request frame called remote frame. The following "Control field"
contains the "IDentifier Extension (IDE)" bit to distinguish between the CAN base
frame and the CAN extended frame, as well as the "Data Length Code (DLC)" used
to indicate the number of following data bytes in the "Data field". If the message is
used as a remote frame, the DLC contains the number of requested data bytes. The
"Data field" that follows is able to hold up to 8 data byte. The integrity of the frame
is guaranteed by the following "Cyclic Redundant Check (CRC)" sum. The
"ACKnowledge (ACK) field" compromises the ACK slot and the ACK delimiter. The
bit in the ACK slot is sent as a recessive bit and is overwritten as a dominant bit by
those receivers, which have at this time received the data correctly. Correct
messages are acknowledged by the receivers regardless of the result of the
acceptance test. The end of the message is indicated by "End Of Frame (EOF)". The
"Intermission Frame Space (IFS)" is the minimum number of bits separating
consecutive messages. Unless another station starts transmitting, the bus remains
idle after this.

CAN extended frame format

The difference between an extended frame format message and a base frame
format message is the length of the identifier used. The 29-bit identifier is made up
of the 11-bit identifier (“base identifier”) and an 18-bit extension (“identifier
extension”). The distinction between CAN base frame format and CAN extended
frame format is made by using the IDE bit, which is transmitted as dominant in
case of an 11-bit frame, and transmitted as recessive in case of a 29-bit frame. As
the two formats have to co-exist on one bus, it is laid down which message has
higher priority on the bus in the case of bus access collision with different formats
and the same identifier / base identifier: The 11-bit message always has priority
over the 29-bit message.
The extended format has some trade-offs: The bus latency time is longer (in
minimum 20 bit-times), messages in extended format require more bandwidth
(about 20 %), and the error detection performance is lower (because the chosen
polynomial for the 15-bit CRC is optimized for frame length up to 112 bits).

CAN controllers, which support extended frame format messages are also able to
send and receive messages in CAN base frame format. CAN controllers that just
cover the base frame format do not interpret extended frames correctly. However
there are CAN controllers, which only support the base frame format but recognize
extended messages and ignore them.

Detecting and signaling errors

Unlike other bus systems, the CAN protocol does not use acknowledgement
messages but instead signals errors immediately as they occur. For error detection
the CAN protocol implements three mechanisms at the message level (data link
layer: OSI layer 2):

 Cyclic Redundancy Check (CRC): The CRC safeguards the information in the
frame by adding a frame check sequence (FCS) at the transmission end. At the
receiver this FCS is re-computed and tested against the received FCS. If they
do not match, there has been a CRC error.
 Frame check: This mechanism verifies the structure of the transmitted frame by
checking the bit fields against the fixed format and the frame size. Errors
detected by frame checks are designated "format errors".
 ACK errors: Receivers of a message acknowledge the received frames. If the
transmitter does not receive an acknowledgement an ACK error is indicated.

The CAN protocol also implements two mechanisms for error detection at the bit
level (physical layer: OSI layer 1):

 Monitoring: The ability of the transmitter to detect errors is based on the

monitoring of bus signals. Each station that transmits also observes the bus
level and thus detects differences between the bit sent and the bit received.
This permits reliable detection of global errors and errors local to the
transmitter.
 Bit stuffing: The coding of the individual bits is tested at bit level. The bit
representation used by CAN is "Non Return to Zero (NRZ)" coding. The
synchronization edges are generated by means of bit stuffing. That means after
five consecutive equal bits the transmitter inserts a stuff bit into the bit stream.
This stuff bit has a complementary value, which is removed by the receivers.

If one or more errors are discovered by at least one station using the above
mechanisms, the current transmission is aborted by sending an "error frame". This
prevents other stations from accepting the message and thus ensures the
consistency of data throughout the network. After transmission of an erroneous
message that has been aborted, the sender automatically re-attempts transmission
(automatic re-transmission). Nodes may again compete for bus access. 

However effective and efficient the method described may be, in the event of a
defective station it might lead to all messages (including correct ones) being
aborted. If no measures for self-monitoring were taken, the bus system would be
blocked by this. The CAN protocol therefore provides a mechanism to distinguish
sporadic errors from permanent errors and local failures at the station. This is done
by statistical assessment of station error situations with the aim of recognizing a
station's own defects and possibly entering an operation mode in which the rest of
the CAN network is not negatively affected. This may continue as far as the station
switching itself off to prevent other nodes' messages erroneously from being
recognized as incorrect.