The Controller Area Network

Controller Area Network
CAN History
Bosch originally developed the Controller Area

Network (CAN) in 1985 for in-vehicle networks. In the
past, automotive manufacturers connected electronic
devices in vehicles using point-to-point wiring
systems. Manufacturers began using more and more
electronics in vehicles, which resulted in bulky wire
harnesses that were very heavy and expensive. They
then replaced dedicated wiring with in-vehicle
networks, which reduce wiring cost, complexity, and
weight. CAN, a high-integrity serial bus system for
networking intelligent devices, emerged as the
standard in-vehicle network. The automotive industry
quickly adopted CAN and, in 1993, it became the
international standard known as ISO 11898. Since
1994, several higher-level protocols have been
standardized on CAN, such as CAN open and Device
Net. Other markets have widely adopted these
additional protocols, which are now standards for
industrial communications. This white paper focuses
on CAN as an in-vehicle network.
Milestones of CAN History
1983 Start of the Bosch internal project to

develop an
In vehicle network.
DEPARTMENT OF COMPUTER SCIENCEPage 1

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 car’s from Mercedes Benz used CAN

Network.
1993 ISO 11898 standard published.
1994 First international CAN conference (iCC)

Organized by CiA.
1994 Device net protocol introduction by Allen

Bradley.

1995 ISO 11898 amendment (Extended Frame

Format) published.
1995 CAN open protocol published by CiA.
2000 Development of the Time triggered

Communication protocol for CAN (TTCAN).

INTRODUCTION
The Controller Area Network (the CAN bus) is a serial

communications bus for real-time control
applications; operates at data rates of up to 1
Megabits per second, and has excellent error
detection and confinement capabilities.
CAN was originally developed by the German
company, Robert Bosch, for use in cars, to provide a
cost-effective communications bus for in-car
electronics and as alternative to expensive,
cumbersome and unreliable wiring looms and
connectors. The car industry continues to use CAN
for an increasing number of applications, but
because of its proven reliability and robustness, CAN
is now also being used in many other control
applications.
CAN is an international standard and is documented
in ISO 11898 (for high-speed applications) and ISO
11519 (for lower-speed applications).
Low-cost CAN controllers and interface devices are
available as off-the-shelf components from several of
the leading semiconductor manufacturers. Custom
built devices and popular microcontrollers with
embedded CAN controllers are also available. There
are many CAN-related system development
packages, hardware interface cards and easy-to-use

software packages that provide system designers,

builders and maintainers with a wide range of design,
monitoring, analysis, and test tools.
CAN technology used in Cars

To satisfy customer requirements for greater safety,
comfort, and convenience, and to comply with
increasingly stringent government legislation for
improved pollution control and reduced fuel
consumption, the car industry has developed many
electronic systems. Anti-lock Braking, Engine
Management, Traction Control, Air Conditioning
Control, central door locking, and powered seat and
mirror controls are just some examples.
The complexity of these controls systems, and the
need to exchange data between them meant that
more and more hard-wired, dedicated signal lines
had to be provided. Sensors had to be duplicated if
measured parameters were needed by different
controllers. Apart from the cost of the wiring looms
needed to connect all these components together,
the physical size of the wiring looms sometimes
made it impossible to thread them around the
vehicle (to control panels in the doors, for example).
In addition to the cost, the increased number of
connections posed serious reliability, fault diagnosis,
and repair problems during both manufacture and in
service.
A new solution was needed and, in the mid 1980s,

the Robert Bosch company (a highly regarded
supplier of components and sub systems to the
automotive industry) provided the answer by
specifying the Controller Area Network (CAN).
Many of the world's chip manufacturers now offer a
wide range of semiconductor devices that implement
the protocol in small low-cost controllers and
interface devices and most modern cars (certainly in
Europe - and increasingly in the rest of the world)
now use CAN.
Industrial Applications of CAN

CAN controllers and interface chips are physically
small. They are available as low-cost, off-the-shelf
components. They will operate at high, real-time
speeds, and in harsh environments. All these
properties have led to CAN also being used in a wide
range of applications other than the car industry.
The benefits of reduced cost and improved reliability
that the car industry gains by using CAN are now
available to manufacturers of a wide range of
products.
For example:
Marine control and navigation systems
Elevator control systems

Agricultural machinery
Production line control systems
Machine tools
Large optical telescopes
Photo copiers
Medical systems
Paper making and processing machinery
Packaging machinery
Textile production machinery
even toys for children
Using CAN to network controllers, actuators, sensors,
and transducers, manufacturers of all the above-
mentioned computer controlled products have
benefited from:
Reduced design time (readily available, multi
sourced components, and tools)
Lower connection costs (lighter, smaller cables and
connectors)
Improved reliability (fewer connections.)
Safety:
The safety-related aspects of using CAN in cars
attracted the attention of manufacturers of medical
systems. Because of the inherent reliability of the
data transmission and the stringent safety

requirements that need to be built into medical

equipment such as X-ray machines and radio-therapy
systems, CAN is now used in a range of these
systems.
User Groups:
To cater for the growth in the use of CAN and to
provide a forum for discussion, several User Groups
have been formed. One of the first to be formed was
the CAN Textile Users Group, but the principal
international Users Group is CAN in Automation (CiA).
Click here to access the CiA web site.
How does CAN works?

Principle:
Data messages transmitted from any node on a CAN
bus do not contain addresses of either the
transmitting node, or of any intended receiving node.
Instead, the content of the message (e.g. Revolutions
Per Minute, Hopper Full, X-ray Dosage, etc.) is
labelled by an identifier that is unique throughout the
network. All other nodes on the network receive the
message and each performs an acceptance test on
the identifier to determine if the message, and thus
its content, is relevant to that particular node.
If the message is relevant, it will be processed;
otherwise it is ignored. The unique identifier also

determines the priority of the message. The lower

the numerical value of the identifier, the higher the
priority.
In situations where two or more nodes attempt to
transmit at the same time, a non-destructive
arbitration technique guarantees that messages are
sent in order of priority and that no messages are
lost.
Bit encoding:
CAN uses Non Return to Zero (NRZ) encoding (with
bit-stuffing) for data communication on a differential
two wire bus. The use of NRZ encoding ensures
compact messages with a minimum number of
transitions and high resilience to external
disturbance.
The physical bus:
The two wire bus is usually a twisted pair (shielded or
unshielded). Flat pair (telephone type) cable also
performs well but generates more noise itself, and
may be more susceptible to external sources of
noise.
Robustness:
CAN will operate in extremely harsh environments
and the extensive error checking mechanisms ensure

that any transmission errors are detected. See the

'Error Handling' section of this site for more details.
The ISO11898 standard "Recommends" that bus
interface chips be designed so that communication
can still continue (but with reduced signal to noise
ratio) even if:
- Either of the two wires in the bus is broken
- Either wire is shorted to power
- Either wire is shorted to ground
Network Flexibility and Expansion:
The content-oriented nature of the CAN messaging
scheme delivers a high degree of flexibility for
system configuration.
New nodes that are purely receivers, and which need
only existing transmitted data can be added to the
network without the need to make any changes to
existing hardware or software.
Measurements needed by several controllers can be
transmitted via the bus, thereby removing the need
for each controller to have its own individual sensor.
Arbitrary Works on the CAN Bus:

In any system, some parameters will change more
rapidly than others. For example - parameters that
change quickly could be the RPM of a car engine, or
the current floor level of an elevator (US) - lift (UK).

Slower changing parameters may be the

temperature of the coolant of a car engine.
It is likely that the more rapidly changing parameters
need to be transmitted more frequently and,
therefore, must be given a higher priority.
To determine the priority of messages, CAN uses the
established method known as Carrier Sense, Multiple
Access with Collision Detect (CSMA/CD) but with the
enhanced capability of non-destructive bitwise
arbitration to provide collision resolution, and to
deliver maximum use of the available capacity of the
bus.
Non-Destructive Bitwise Arbitration:
The priority of a CAN message is determined by the
numerical value of its identifier.
The numerical value of each message identifier (and
thus the priority of the message) is assigned during
the initial phase of system design.
The identifier with the lowest numerical value has
the highest priority. Any potential bus conflicts are
resolved by bitwise arbitration in accordance with the
wired-and mechanism, by which a dominant state
(logic 0) overwrites a recessive state (logic 1).
The Benefits:
Non-destructive bitwise arbitration provides bus
allocation on the basis of need, and delivers

efficiency benefits that cannot be gained from either

fixed time schedule allocation (e.g. Token ring) or
destructive bus allocation (e.g. Ethernet.)
With only the maximum capacity of the bus as a
speed limiting factor CAN will not collapse or lock up.
Outstanding transmission requests are dealt with in
their order of priority, with minimum delay, and with
maximum possible utilization of the available
capacity of the bus.
CAN Message Format

Message Frames:
In a CAN system, data is transmitted and received
using Message Frames. Message Frames carry data
from a transmitting node to one, or more, receiving
nodes.
The Standard CAN protocol (version 2.0A), also now
known as Base Frame Format, supports messages
with 11 bit identifiers.
The Extended CAN protocol (version 2.0B), also now
known as Extended Frame Format, supports both 11
bit and 29 bit identifiers.
Most 2.0A controllers transmit and receive only
Standard format messages, although some (known
as 2.0B passive) will receive extended format

messages - but then ignore them. 2.0B controllers

can send and receive messages in both formats.
2.0A Format:
A Standard CAN (Version 2.0A) Message Frame
consists of seven different bit fields:
A Start of Frame (SOF) field - which indicates the
beginning of a message frame.
An Arbitration field, containing a message identifier
and the Remote Transmission Request (RTR) bit. The
RTR bit is used to discriminate between a transmitted
Data Frame and a request for data from a remote
node.
Fig.CAN 2.0A Message Frame
A Control Field containing six bits:

* two reserved bits (r0 and r1) and
* a four bit Data Length Code (DLC). The DLC
indicates the number of bytes in the Data Field that
follows
A Data Field, containing from zero to eight bytes.
The CRC field, containing a fifteen bit cyclic

redundancy check code and a recessive delimiter bit
The Acknowledge field, consisting of two bits. The
first is the Slot bit which is transmitted as recessive,
but is subsequently over written by dominant bits
transmitted from any node that successfully receives
the transmitted message. The second bit is a
recessive delimiter bit
The End of Frame field, consisting of seven
recessive bits.
Following the End of Frame is the Intermission field
consisting of three recessive bits.
After the three bit Intermission period the bus is
recognized to be free. Bus Idle time maybe of any
arbitrary length including zero.
2.0B Format:
The CAN 2.0B format provides a twenty nine (29) bit
identifier as opposed to the 11 bit identifier in 2.0A.
Version 2.0B evolved to provide compatibility with
other serial communications protocols used in
automotive applications in the USA. To cater for this,
and still provide compatibility with the 2.0A format,
the Message Frame in Version 2.0B has an extended
format.
The differences are:

- In Version 2.0B the Arbitration field contains two

identifier bit fields. The first (the base ID) is eleven
(11) bits long for compatibility with Version 2.0A. The
second field (the ID extension) is eighteen (18) bits
long, to give a total length of twenty nine (29) bits.
- The distinction between the two formats is made
using an Identifier Extension (IDE) bit.
- A Substitute Remote Request (SRR) bit is also
included in the Arbitration Field. The SRR bit is
always transmitted as a recessive bit to ensure that,
in the case of arbitration between a Standard Data
Frame and an Extended Data Frame, the Standard
Data Frame will always have priority if both
messages have the same base (11 bit) identifier.
All other fields in a 2.0B Message Frame are identical
to those in the Standard format.
2.0A and 2.0B Compatibility:
2.0B controllers are completely backward compatible
with 2.0A controllers and can transmit and receive
messages in either format.
Note, however, that there are two types of 2.0A
controllers:
- The first is capable of transmitting and receiving
only messages in 2.0A format. With this type of
controller, reception of any 2.0B message will flag an
error.

- The second (known as 2.0B passive) is capable of

sending and receiving 2.0A messages. They will also
acknowledge receipt of 2.0B messages - but then
ignore them.
Therefore, within the above mentioned constraints it
is possible to use both Version 2.0A (with 2.0B
passive capabilities) and 2.0B controllers on a single
network.
The number of unique identifiers available to users,
on a single 2.0A network, is 2,032 (2 to the power 11
- 2 to the power 4).
Leaving aside the use for compatibility purposes with
American buses, the number of unique identifiers
available on a 2.0B network is in excess of 500
million!
Implementations of CAN
Communication is identical for all implementations of
CAN. However, there are two principal hardware
implementations.
The two implementation are known as Basic CAN and
Full CAN.
***Note***
The terms Basic CAN and Full CAN must not be
confused with the terms Standard CAN - also known
as Base Frame Format (11 bit identifier, Version 2.0A

data format) and Extended CAN - also known as

Extended Frame Format (29 bit identifier, or Version
2.0B data format). Suitably configured, each
implementation (Basic or Full CAN) can handle both
Base and Extended data formats.
Basic CAN:
In the Basic-CAN devices, only basic functions
concerning the filtering and management of CAN
messages are implemented in hardware. A Basic-CAN
controller typically provides one transmit buffer for
outgoing
messages and one or two receive buffers for
incoming messages.
In the receive path, an acceptance filtering is

available which allows that only certain CAN
identifiers are stored in the receive buffer.
Because there are only two buffers for the reception

of messages the host controller is quite busy reading
and storing the incoming messages before they get
overwritten by the following ones which results in a
quite high CPU load. Also the answering of Remote
Frames with the
corresponding Data Frame has to be handled by the
host controller.
Therefore Basic-CAN devices should only be used at

low baud rates and low bus loads with only a few
different messages.

Full CAN:
Full-CAN devices provide the whole hardware for
convenient acceptance filtering and message
management. For each message to be transmitted or
received these devices contain one so called
message object in which all information regarding
the message (e.g. identifier, data bytes etc.) are
stored. During the initialisation of the device, the
host CPU defines which messages are to be sent and
which
are to be received. Only if the CAN controller receives
a message whose identifier matches with one of the
identifiers of the programmed (receive-) message
objects the message is stored and the host CPU is
informed by interrupt. Another advantage is that
incoming Remote
Frames can be answered automatically by the Full-
CAN controller with the corresponding Data Frame. In

this way, the CPU load is strongly reduced compared

to the Basic-CAN solution. Using Full CAN devices,
high baudrates and high bus loads with many
messages can be handled.
Many Full-CAN controller provide a "Basic-CAN

Feature": One of their message objects behaves like
a Basic-CAN Receive Buffer, i.e. it can be
programmed in a way that every message is stored
there that does not match with one of the other
message objects. This can be very helpful in
applications where the number of message objects is
not enough to receive all desired messages.
Network Sizes:

The number of nodes that can exist on a single

network is, theoretically, limited only by the number
of available identifiers. However, the drive
capabilities of currently available devices impose
greater restrictions. Depending on the device types,
up to 32 or 64 nodes per network is normal, but at
least one manufacturer now provides devices that
will allow networks of 110 nodes.
Data Rate vs. Bus Length:
The rate of data transmission depends on the total
overall length of the bus and the delays associated
with the transceivers. For all ISO11898 compliant
devices running at 1Mbit/sec speed, the maximum
possible bus length is specified as 40 Meters, For
longer bus lengths it is necessary to reduce the bit
rate. To give some indication of this the following
numbers are from the Device Net features list:
500 K bits per second at 100 meters (328 ft)
250 K bits per second at 200 metres (656 ft)
125 K bits per second at 500 metres (1640 ft)
The OSI model

ISO7498 defines a communications standard known
as the Open Systems Interconnection (OSI) model.
This model describes how communications should

occur between computers on any network, and has

been adopted as a general "open" network
communication standard. In principle - anything that
conforms to the standard can communicate,
electronically, with anything else that conforms to
the standard.
The OSI model defines seven independent "layers" of
a protocol stack. Strict compliance with the standard
requires that each layer is insulated from the others
by well-defined interfaces. Few, if any, networks
comply absolutely with the OSI model with regard to
provision of all seven layers as distinct entities.
Fig.OSI reference model.
CAN and the OSI Model

The CAN specification (ISO11898) discusses only the

Physical and Data-Link layers for a CAN network.
The Data-Link Layer - is the only layer that
recognizes and understands the format of messages.
This layer constructs the messages to be sent to the
Physical Layer, and decodes messages received from
the Physical Layer. In CAN controllers, the Data-Link
Layer is usually implemented in hardware.
The Physical Layer - specifies the physical and
electrical characteristics of the bus, and of the
hardware that converts the characters of a message
into electrical signals for transmitted messages - and
electrical signals into characters for received
messages. Although the other layers may be
implemented in either hardware (as chip level
functions) or software, the Physical Layer is always
"real" hardware.
CAN Applications Layers:
Many applications of CAN require services that are
beyond the basic functionality specified by the Data-
Link Layer but which may be implemented at the
Application Layer. For example, the transmission or
reception of data units longer than eight bytes. To
meet this need several organizations have developed
Application Layers. Brief details about just a few of
them and contact details are given below.
CAL (CAN Application Layer):

Aptly named, and based on an existing and proven

protocol originally developed by Philips Medical
Systems, CAL is an application-independent
application layer that has been specified and is now
maintained by the CAN in Automation (CiA) user
group. Anyone who implements CAL may do so free
of any license royalty. The CAL specification
(document reference CiA DS-201...207) may be
purchased from CiA. See the CiA web site for details.
CAN open:
CAN open is an implementation of CAL and is defined
by the CAN open Communications Profile in CiA DS-
301. This document may also be purchased from CiA.
Information about CAN open may be obtained from
the CiA User Group
You might also want to get hold of a copy of
"Embedded Networking with CAN and CAN open" by
Olaf Pfeiffer, Andrew Ayre and Christian Keydel.
Published by RTC Books. ISBN: 0-929392-78-7. Price
in the USA $49.95.
Device Net:
Device Net is a CiA-approved application layer based
on CAN 2.0A and is widely used in industrial
automation applications. Device Net (originally
developed by Rockwell/Allen-Bradley) is now an
“Open” field bus regulated by an independent
organization knows as the Open Device Net Vendors

Association, from who copies of the specification may

be purchased. Purchasers of the specification receive
an unlimited, royalty-free license to develop Device
Net compatible products. See the ODVA web site for
full details.
NMEA 2000:
An application layer used in the marine and pleasure
craft sector. For details see the NMEA web site.
SDS (Smart Distributed System):
SDS is also a CiA-approved application layer.
Developed by Honeywell, one of the main uses of
SDS is for machine control applications. See the
Honeywell web site for details.
CAN Kingdom:
Another CiA-approved application layer, named CAN
Kingdom, is provided by a Swedish company named
Kvaser AB. You can find out all about it if you search
the Kvaser site.

Error Detection
CAN implements five error detection mechanisms;
three at the message level and two at the bit level.
At the message level:
Cyclic Redundancy Checks (CRC)
Frame Checks
Acknowledgment Error Checks (ACK)
At the bit level:

Bit Monitoring
Bit Stuffing
Cyclic Redundancy Check:

Every transmitted message contains a 15 bit Cyclic
Redundancy Check (CRC) code. The CRC is computed
by the transmitter and is based on the message
content. All receivers that accept the message
perform a similar calculation and flag any errors. If
node B detects a mismatch between the calculated
and the received
CRC sequence, then a CRC error has occurred.
Node B discards the message and transmits an Error
Frame to request retransmission of the garbled
frame.

Frame Check:
There are certain predefined bit values that must be
transmitted at certain points within any CAN
Message Frame.
If a receiver detects an invalid bit in one of these
positions a Form Error (also known as a Format Error)
will be flagged.
If a transmitter detects a dominant bit in one of the

four segments:
 CRC Delimiter,
 Acknowledge Delimiter,
 End of Frame or
 Interframe Space

then a Form Error has occurred and an Error Frame is

generated. The message will then be repeated.
Acknowledgement (ACK) Error Check:

If a transmitter determines that a message has not
been acknowledged then an ACK Error is flagged.
With the Acknowledge Check, the transmitter checks
in the
Acknowledge Field of a message to determine if the
Acknowledge Slot, which is sent out as a recessive
bit, contains a dominant bit. If this is the case, at
least one other node, (here node B) has received the
frame correctly. If not, an Acknowledge Error has
occurred and the message has to be repeated. No
Error Frame is generated, though.

Bit Monitoring:
Any transmitter automatically monitors and
compares the actual bit level on the bus with the
level that it transmitted. If the two are not the same,
a bit error is flagged. All nodes perform Bit
Monitoring: A Bit Error occurs if a transmitter sends a
dominant bit but detects a recessive bit on the bus
line or, sends a recessive bit but detects a dominant
bit on the bus line. An Error Frame is generated and
the message is repeated. When a dominant bit is
detected instead of a recessive bit, no error
occurs during the Arbitration Field or the
Acknowledge Slot because these fields must be able
to be overwritten by a dominant bit in order to
achieve arbitration and acknowledge functionality.

Bit Stuffing:
CAN uses a technique known as bit stuffing as a
check on communication integrity. After five
consecutive identical bit levels have been
transmitted, the transmitter will automatically inject
(stuff) a bit of the opposite polarity into the bit
stream. Receivers of the message will automatically
delete (de-stuff) such bits before processing the
message in any way.
Because of the bit stuffing rule, if any receiving node
detects six consecutive bits of the same level, a stuff
error is flagged. If six consecutive bits with the same

polarity are detected between Start of Frame and the

CRC Delimiter, the bit stuffing rule has been violated.
A stuff error occurs and an Error Frame is generated.
The message is then repeated.
Error Frame:
If an error is detected by any node, using any and all
of the five mechanisms described above, the node
that detects the error aborts the transmission by
sending an Error Frame. This prevents any other
node from accepting the message and ensures
consistency of data throughout the network.
Error Confinement:
Error confinement is a mechanism which is
understood to be unique to CAN and provides a
method for discriminating between temporary errors
and permanent failures. Temporary errors may be
caused by, spurious external conditions, voltage

spikes, etc. Permanent failures are likely to be caused
by bad connections, faulty cables, defective
transmitters or receivers, or long lasting external
disturbances.
The general principle only is described here. More
detailed information is available in the ISO standard,
and in the data sheets from the device
manufacturers.
Error Counts:
When an error is flagged, error counts are added to
one of two dedicated error count registers within
each CAN controller on each node.
It's more complex than stated here, but - in principal
- receive errors are given a weighting of 1 and are
accumulated in a Receive Error Count register;
transmit errors are given a weighting of 8 and
accumulated in a Transmit Error Count register.
If errors continue to occur, the error counts continue
to increase. Any good messages decrement the Error
Count registers and, if no further errors are detected,
both Error Counts go back to zero.
The accumulated error counts determine the error
status of a node.

Error Active Mode:

Nodes usually operate in a state known as Error
Active mode. In this condition a node is fully
functional and both the Error Count registers contain
counts of less than 127.

Error Passive Mode:

If the count in either Error Count register in a node
exceeds 127, the node will go from Error Active mode
to a heightened state of "alert" known as Error
Passive mode.
Error Passive nodes can still transmit and receive
messages but are restricted in relation to how they
flag any errors that they may detect.
The ISO standard (and some of the device data
sheets) explain the precise mechanisms in more
detail.

Bus Off Mode:

If an error condition persists, such that the Transmit
Error Count of a device exceeds 255, the device will
take itself off the bus by going to BusOff mode. This
means that a permanently faulty device will cease to
be active on the bus until reconnected under user
control, but communications between the other
nodes can continue unhindered.
Error Detection Capabilities:

Error detection on CAN is extremely thorough.

Global errors which occur at all nodes are 100%

detectable.
For local errors (i.e. errors which may appear at only
some nodes) the CRC check alone has the following
error detection capabilities:
Up to 5 single bit errors are 100% detectable, even
if the errors are distributed randomly within the code
word
All single bit errors are detected if their total
number within the code word is odd
The residual (undetected) error probability of the CRC
check alone is 3 x 10 to the power -5.
In conjunction with all the other error checking
mechanisms, a more realistic value is 10 to the
power -11.
Bit time:
As defined in ISO11898, the nominal time for each bit
in a CAN message frame is made up of four non-
overlapping time segments as shown below.

Fig. Bit time segments

Sync-seg is the segment that is used to
synchronize the nodes on the bus. A bit edge (if there
is a data change) is expected during this segment.
Prop-Seg is a period of time that is used to
compensate for physical delay times within the
network.
Phase-seg1 is a buffer segment that may be
lengthened during resynchronization to compensate
for oscillator drift and positive phase differences
between the oscillators of the transmitting and
receiving node(s).
Phase-seg2 is a buffer segment that may be
shortened during resynchronization (described
below) to compensate for negative phase errors and
oscillator drift.
The Sample point is always at the end of Phase-seg1
and is the time at which the bus level is read and
interpreted as the value of the current bit.
Whether transmitting or receiving, all nodes on a
single CAN bus must have the same nominal bit time.
Bit time is programmable at each node on a CAN Bus

and is a function of the period of the oscillator local

to each node, the value that is user-programmed into
a Baud Rate Prescaler (BRP) register in the controller
at each node, and the programmed number of time
quanta per bit.
One time quanta (Also known as the system clock
period) is defined as the period of the local oscillator,
multiplied by the value in the BRP.
Each of the four time segments in one bit is one or
more time quanta long. As stated in the Bosch CAN2
spec:
Sync-Seg is always one time quantum long
Prop-Seg is programmable from one to eight (or,
optionally, more) time quanta long
Phase-seg1 is programmable from one to eight (or,
optionally, more) time quanta long
Phase-seg2 is the maximum of Phase-seg1 and the
Information Processing Time
Where the Information Processing Time is less than
or equal to 2 time quanta.
Synchronization
When any node receives a data frame or a remote
frame, it is necessary for the receiver to synchronize
with the transmitter.

Because there is no explicit clock signal that a CAN

system can use as a timing reference, two
mechanisms are used to maintain synchronization.
The first is hard synchronization and occurs at Start-
of-Frame (SOF).
To compensate for oscillator drift, and phase
differences between transmitter and receiver
oscillators, additional synchronization is needed.
So - for subsequent bits in any received frame, if a
bit edge does not occur in the Sync-Seg segment of
bit time, resynchronization is automatically invoked
and will shorten or lengthen the current bit time
depending on where the edge occurs. The maximum
amount by which the bit time is lengthened or
shortened is determined by a user-programmable
number of time quanta known as the Synchronization
Jump Width (SJW).

The overview of Controller Area Network’s

Basics
Is a high-integrity serial data communications bus for
real-time control applications.
Operates at data rates of up to 1 Mega bits per

second
Have excellent error detection and confinement

capabilities
Was originally developed for use in cars
Is now being used in many other industrial

automation and control applications
CAN is documented in ISO 11898 (for applications up

to 1 Mega bits per second) and ISO 11519 (for
applications up to 125 K bits per second)

CONTROLLER AREA NETWORK (CAN) PROTOCOL
The Controller Area Network (CAN) protocol,

developed by ROBERT BOSCH GmbH, offers a
comprehensive solution to managing communication
between multiple CPUs. The CAN protocol specifies
versatile message identifiers that can be mapped to
specific.
Control information categories. Communications

may occur at a maximum recommended rate of 1
Mbit/sec (roughly a 40 meter bus length). The
protocol
has found wide acceptance in automotive in-vehicle
applications as well as many non-automotive due to
its low cost, high performance, and the availability of
various CAN protocol implementations.
In-vehicle networking protocols must satisfy unique

requirements not present in other networking
protocols
such as those found in telecommunications and data
processing. These requirements include a high level
of
error detection, low latency times and configuration
flexibility.
The CAN protocol provides four primary benefits.

First, a standard communications protocol simplifies
and economizes the task of interfacing subsystems
from
various vendors onto a common network. Second,
the
communications burden is shifted from the host-CPU
to an intelligent peripheral; the host-CPU has more
time to run its system tasks. Third, as a multiplexed
network, CAN greatly reduces wire harness size and
eliminates point-to-point wiring. Lastly, as a standard
protocol, CAN has broad market appeal which
motivates
semiconductor makers to develop competitively
priced
CAN devices.
An example of an application well-served by the CAN

protocol is automotive networking because many
modules
are inter-dependent. Sub-systems such as the
engine,

transmission, anti-lock braking, and accident

avoidance systems require the exchange of
particular
performance and position information within a
defined
communications latency. The engine transmits
engine
speed and acceleration parameters to the
transmission
to allow smoother shifting. Perhaps the transmission
requests the engine to reduce fuel injection before a
gear change.
CAN is a CSMA/CD-A, or Carrier Sense Multiple Access

by Collision Detection using Arbitration protocol.
Through a multi-master architecture, prioritized
messages of length 8 bytes or less are sent on a
serial bus.
Error detection mechanisms, such as a 15-bit Cyclical
Redundancy Check (CRC), provide a high level of
data
integrity. For information on the CAN protocol, please
read the CAN Specification, Version 2.0.
The CAN 2.0 protocol was chosen by the SAE Truck &
Bus Control and Communications Network
Subcommittee
of the Truck & Bus Electrical Committee to support
its ``Recommended Practice for Serial Control and
Communciations Vehicle Network CLASS C'' called
the SAE J1939 specification. The SAE CLASS C
passenger car subcommittee is currently evaluating
CAN,

which is a candidate for its high speed networks.

Products
using CAN Version 2.0 are already in production.
The previous CAN specification, Version 1.2, has been
successfully implemented in passenger car, train and
factory automation applications since 1989. CAN
Version
2.0, which features an ``extended frame'' with a 29-
bit message identifier, broadens the application base
for
this protocol by allowing J1850 message schemes to
be
mapped into the CAN message format.
The Intel 82526 was the first implementation of the

CAN protocol, in production since 1989. The Intel
82527 is a follow-on to the 82526 which implements
CAN Version 2.0, provides greater message handling
capability and implements a more flexible interface
to
CPUs.

Vehicle Applications of
Introduction

In the automotive industry, embedded control has

grown from stand-alone systems to highly integrated
and networked control systems [11, 7]. By
networking electro-mechanical subsystems, it
becomes possible to modularize
functionalities and hardware, which facilitates reuse
and adds capabilities.
Figure shows an example of an electronic control unit

(ECU) mounted on a diesel engine of a Scania truck.
The ECU handles the control of engine, turbo, fan,
etc. but also the CAN communication. Combining
networks and mechatronic modules makes it possible
to reduce both the cabling and the number of
connectors, which facilitates production and
increases reliability. Introducing
networks in vehicles also make it possible to more
efficiently carry out diagnostics and to coordinate the
operation of the separate subsystems.
Protocol extensions

CAN provides the basic functionality described

above. In many situations, it is desirable to use
standardized protocols that define the
communication layers on top of the CAN. Such
higher-layer protocols are described below together
with CAN gateways and the time-triggered extension
of CAN denoted TTCAN, which allows periodic access
to the communication bus with a high degree of
certainty.
Higher-layer protocols
In order to use CAN, protocols are needed to define

the other layers. Field bus protocols usually do not
define the session and presentation layers, since
they are not needed in these applications. The users
may either decide to
define their own software for handling the higher
layers, or they may use a standardized protocol.
Existing higher-layer protocols are often tuned to a
certain application domain. Examples of such
protocols include SAE J1939,
CAN open, and Device Net. It is only SAE J1939 that
is specially developed for vehicle applications.
Recently, attempts have been made to interface CAN
and Ethernet, which is the dominant technology for
local area networks and widely applied for
connecting to the Internet. SAE J1939 is a protocol
that defines the higher-layer communication control.
It was developed by the American Society of
Automotive Engineers (SAE) and is thus targeted to
the automotive industry. The advantage of having a
standard is considerable, since it enables

independent development of the individual

networked components, which also allows vehicle
manufacturers to use components from different
suppliers. SAE J1939 specifies, e.g., how to read and
write data, but also how to calibrate certain
subsystems. The data rate of SAE J1939 is about 250
kbps, which gives up to about 1850 messages per
second [6]. Applications of SAE J1939 include truck-
and-trailer communication, vehicles in agriculture
and forestry, as well as navigation systems in marine
applications.
CAN open is a standardized application defined on

top of CAN and widely used in Europe for the
application of CAN in distributed industrial
automation.
It is a standard of the organization CAN in
Automation (CiA). CAN open specify communication
profiles and device profiles, which enable an
application-independent use of CAN. The
communication profile defines
the underlying communication mechanism. Device
profiles exist for the most common devices in
industrial automation, such as digital and analog I/O
components, encoders, and controllers. The device
can be configured through CAN open independent of
its manufacturer.
CAN open distinguish real-time data exchange and

less critical data exchange. It provides standardized
communication objects for real-time data,
configuration data, network management data, and

certain special functions (e.g., time stamp and

synchronization
messages).Device Net is another standardized
application defined on top of CAN for distributed
industrial automation. It is mainly used in the U.S.A.
and Asia and was originally developed by Rockwell
Automation.
Device Net, Control-Net, and transmission control
protocol/Internet protocol (TCP/IP) are open network
technologies that share upper layers of the
communication protocol, but are based on lower
layers.
Device Net is built on CAN, Control Net on a token-
passing bus protocol, and TCP/IP on Ethernet. CAN
Kingdom is a high-layer protocol used for motion
control systems.
It is also used in the maritime industry; CAN Kingdom

allows the changing of network behavior at any time,
including while the system is running. For example,
CAN Kingdom allows the system troubleshooter to
turn off individual nodes. The CAN node identifiers
and the triggering conditions for sending messages
can be changed while the system is running. One
instance when real-time network reconfiguration is
used is during failure conditions. An example is a loss
of a radio link ECU
in a maritime application. The network monitor, also
known as the King, in that case first shuts off the
radio node to keep it from sending any more
commands, and then tells the appropriate nodes to
get data from the King.

This operation eliminates the problem of a node

receiving two simultaneous but conflicting
commands. It also eliminates the problem of two
nodes sending the same CAN id. The high-level
protocols described above have been developed with
different applications and traditions in mind, which is
reflected, for example, in their support for real-time
control. Although SAE J1939 is used for implementing
control algorithms, it does not provide explicit
support for time-constrained messaging. In contrast,
such functionalities are provided by CAN Kingdom
and CAN open, which handle explicit support for
inter-node synchronization. CAN Kingdom and CAN
open allow static and dynamic configuration of the
network, whereas SAE J1939 provides little flexibility.
CAN gateways
Gateways and bridges enable CAN-based networks to

be linked together or linked to networks with other
protocols. A gateway between a CAN and another
communication network maps the protocols of the
individual networks.
There exist many different types of CAN gateways,
e.g., CAN-RS232 and CAN-TCP/IP gateways. The latter
can provide remote access to a CAN through the
Internet, which allows worldwide monitoring and
maintenance.
The networks connected through a gateway or a
bridge are disconnected in terms of their real-time
behavior, so obviously the timing and performance of

the complex inter-connected network can be hard to

predict even if the
individual networks are predictable. Ethernet (or
rather Ethernet/IP) is quite a different communication
protocol
compared to CAN, but is still of growing importance
in industrial automation either in constellations with
CAN or on its own. Traditionally, Ethernet is used in
office automation and multimedia applications, while
CAN dominates in vehicles and in certain industrial
automation systems. The strength of Ethernet is the
ability to quickly move large amounts of data over
long
distances and that the number of nodes in the
network can be large. CAN, on the other hand, is
optimized for transmitting small messages over
relatively short distances. A drawback with a network
based on the Ethernet protocol is that the nodes
need to be quite powerful and complex (and
therefore more expensive) in order to handle the
communication control. Another drawback with
Ethernet is that during network traffic congestion the
delay jitter can be severe and unpredictable,
although at low network load Ethernet gives almost
no delay.
Time-triggered communication on CAN
Traditional CAN communication is event based:

asynchronous events are triggered by node
applications that initialize each transmission session.
In many cases, this strategy is an efficient way to

share the network resource. There are a variety of

applications, however, that require a guaranteed
access to the communication bus with a fixed
periodic rate. This constraint is typical for sampled-
data feedback control systems. In the automotive
industry, x-by-wire systems are examples of such
control systems with deterministic communication
behavior during regular operation. By introducing the
notion of global network time, the standard ISO
11898-
4 define the extension Time-triggered
communication on CAN (TTCAN). It is built on top of
the traditional event-triggered CAN protocol and
enables existing CAN nodes to work in parallel with
TTCAN nodes. The global clock requires hardware
implementation; otherwise, TTCAN is a pure software
extension of CAN. The synchronization in TTCAN
takes place through a periodic reference message,
which all TTCAN nodes recognize and use to
synchronize their clocks. The nodes are configured to
know when to send their message after the reference
message. The period time of the transmission of a
periodic node should be a multiple of the reference
period. Traditional CAN nodes (or event-based TTCAN
nodes) compete for the access of the free windows
between the reference messages, along the line of
the conventional CAN protocol. This mechanism is
thus the reason why time-triggered and even
triggered scheduling is possible simultaneously in
TTCAN.
The sender of the reference message is obviously a

crucial node in TTCAN to guarantee clock

synchronization. Therefore, an automatic procedure

is provided for letting another node take over if the
reference sender fails, and taking the reference back
when the original clock master recovers. It is possible
to use an external clock, for example, from the global
positioning system (GPS).
Control Applications
Two vehicular control systems with loops closed over

CAN buses are discussed in this section. The first
example is a vehicle dynamics control system for
passenger cars that is manufactured by Bosch. The
second example is an
attitude and orbit control system for the SMART-1
spacecraft discussed in the previous section.
Vehicle Dynamics control system
Vehicle dynamics control4 systems are designed to

assist the driver in over steering, under-steering and
roll-over situations [15, 9]. The principle of a vehicle
dynamics control (VDC) system is illustrated in
figure. The left
figure shows a situation where over-steering takes
place, illustrating the case where the friction limits
are reached for the rear wheels causing the tire
forces to saturate (saturation on the front wheels will

instead cause an under-steer situation). Unless the

driver is very skilled, the car will start to skid,
meaning that the vehicle yaw rate and vehicle side
slip angle will deviate from what the
driver intended. This is the situation shown for the
left vehicle. For the vehicle on the right, the on-board
VDC will detect the emerging skidding situation and
will compute a compensating torque, which for the
situation illustrated is translated into applying a
braking force to the outer front wheel. This braking
force will provide a compensating torque and the
braking will also reduce the
lateral force for this wheel. The central components
of
VDC are illustrated on the right in figure. In essence,
the VDC will assist the driver by making the car
easier to steer and by improving its stability margin.
Illustration of behavior during over-steering for vehicle with and

without VDC system (left figure). Central components of VDC (right
figure). (Based on figures provided by the Electronic Stability Control
Coalition.)

Attitude and orbit control system
This section describes parts of the SMART-1 attitude

and orbit control system and how it is implemented
in the on-board distributed computer system. The
control objectives of the attitude and orbit control
system are to:
• follow desired trajectories according to the goals of
the mission,
• point the solar panels toward the sun, and
• minimize energy consumption.
The control objectives should be fulfilled despite the

harsh environment and torque disturbances acting
on the spacecraft, such as aero drag (initially when
close to earth), gravitational gradient, magnetic
torque, and solar pressure (mechanical pressure from
photons). There are several phases that the control
system should be able to handle, including the phase
just after separation from
the launcher, the thrusting phases on the orbit to the
moon, and the moon observation phase.

Structure of SMART-1 spacecraft with sensors and actuators for the

attitude
And orbit control system. (Courtesy of the Swedish Space Corporation.)
The attitude and orbit control system consists of a

set of control functions for rate damping, sun
pointing, solar array rotation, momentum reduction,
three-axis attitude control, and electric propulsion
(EP) thruster orientation.
The system has a number of operation modes, which
consist of a subset of these control functions. The
operation modes include the following:
• Detumble mode: In this mode, rotation is stabilized
using one P-controller per axis with the aid of the
hydrazine thrusters and the rate sensors.
• Safe mode: Here the EP thruster is pointed toward
the sun and set to rotate one revolution per hour
around the sun vector. The attitude is controlled
using a bang-bang strategy for large sun angles and
a PID controller for
smaller angles. Both controllers use the reaction
wheels as actuators and the sun tracker as sensor.
The spacecraft rotation is controlled using a PI

controller. When the angular velocity of the reaction
wheels exceeds a
Certain limit, their momentum is reduced by use of
the hydrazine thrusters.
• Science mode: In this mode, ground provides the
attitude set-points for the spacecraft and the star
tracker provides the actual attitude. The reaction
wheels and the hydrazine thrusters are used.
• Electric propulsion control mode: This mode is
similar to the science mode apart from the additional
control of the EP orientation mechanism. This
mechanism can be used to tilt the thrust vector in
order to off-load the
reaction wheel momentum about the two spacecraft
axes that form the nominal EP thrust plane. This
reduces the amount of hydrazine needed. The EP
mechanism is controlled in an outer and slower
control loop (PI)
based on the speed of the reaction wheels and the
rotation of the spacecraft body.
Sales of CAN Nodes in Automation
The CAN protocol was internationally standardized in

1993 as ISO 11898-1. The development of CAN was
mainly motivated by the need for new functionality,
but it also reduced the need for wiring.
The use of CAN in the automotive industry has

caused mass production of CAN controllers. Today,
CAN controllers are integrated on many
microcontrollers and available at a low cost. Figure

shows the number of CAN nodes that were sold

during 1999–2003.
The number of CAN nodes sold per year is currently about 400 million.
(Data from the association CAN in Automation)
Perspectives
The development of vehicles is going through a

dramatic evolution, in their transition from pure
mechanical systems to mechatronic machines with
highly integrated hardware and software subsystems.
DaimlerChrysler estimates that 90% of the

innovations in the automotive area lie in electronics
and software.
A challenge in the development of vehicular
embedded control systems is safety and real-time

requirements. The control systems are increasingly

being implemented in distributed computer systems
and require a multitude of
competences to be developed and integrated to
meet quality requirements in a cost-efficient way. A
major research problem is to develop techniques and
tools to bridge the gap between functional
requirements and the final design. In this section, we
describe two particular trends in the vehicular
networked embedded systems, namely, brake-by-
wire and other x-by-wire systems, and standardized
platforms and open-ended architectures for
distributed control units in vehicles.
The enhanced Controller Area Network (eCAN)
ARCHITECTURE
The enhanced Controller Area Network (eCAN)
module implemented in the C28x DSP is compatible
with the CAN 2.0B standard (active). It uses
established protocol to communicate serially with
other controllers in electrically noisy environments.
With 32 fully configurable mailboxes and
time−stamping feature, the eCAN module provides a
versatile and robust serial communication interface.

This reference guide is applicable for the
TMS320x28xx and TMS320x28xxx
family of processors. The CAN modules used in these
devices are exactly identical to each other. The eCAN
module in TMS320x281x devices and the eCAN-A
module in TMS320x28xxx devices are mapped to the
same address space, with identical register offset
addresses. Some devices in the TMS320x28xxx
family have a second CAN module, eCAN-B.
The word eCAN is generically used to refer to the

CAN modules. The specific module reference (A or B)
is used where appropriate.
Features
The eCAN module has the following features:
 Fully compliant with CAN protocol, version 2.0B

 Supports data rates up to 1 Mbps
 Thirty−two mailboxes, each with the following
properties:
 Configurable as receive or transmit
 Configurable with standard or extended
identifier
 Has a programmable acceptance filter mask
 Supports data and remote frame
 Supports 0 to 8 bytes of data
 Uses a 32−bit time stamp on received and
transmitted message
 Protects against reception of new message

 Allows dynamically programmable priority of

transmit message
 Employs a programmable interrupt scheme
with two interrupt levels
 Employs a programmable interrupt on
transmission or reception time−out
 Low−power mode
 Programmable wake−up on bus activity
 Automatic reply to a remote request message
 Automatic retransmission of a frame in case of loss
of arbitration or error
 32−bit time−stamp counter synchronized by a
specific message (communication in conjunction
with mailbox 16)
 Self−test mode
 Operates in a loopback mode receiving its own
message. A “dummy” acknowledge is
provided, thereby eliminating the need for
another node to provide the acknowledge bit.
eCAN BLOCK DIAGRAM

eCAN Compatibility With Other TI CAN Modules

The eCAN module is identical to the “High−end CAN

Controller (HECC)” used in the TMS470_ series
microcontrollers from Texas Instruments with some
minor changes. The eCAN module features several
enhancements (such as increased number of
mailboxes with individual acceptance masks, time
stamping, etc ) over the CAN module featured in
240x series of DSPs. For this reason, code written
for 240x CAN modules cannot be directly ported to
eCAN. However, eCAN follows the same register bit-
layout structure and bit
functionality as that of 240x CAN (for registers that
exist in both devices) i.e., many registers and bits
perform exactly identical functions across these two
platforms. This makes code migration a relatively
easy task, more so with code written in C language.
eCAN Controller Overview
The eCAN is a CAN controller with an internal 32−bit

architecture.
 The eCAN module consists of:
 The CAN protocol kernel (CPK)
 The message controller comprising:
 The memory management unit (MMU),
including the CPU interface and the receive
control unit (acceptance filtering), and the
timer management unit
 Mailbox RAM enabling the storage of 32
messages
 Control and status registers
After the reception of a valid message by the CPK,
the receive control unit of the message controller

determines if the received message must be stored

into one of the 32 message objects of the mailbox
RAM. The receive control
unit checks the state, the identifier, and the mask of
all message objects to determine the appropriate
mailbox location. The received message is stored into
the first mailbox passing the acceptance filtering. If
the receive control unit could not find any mailbox to
store the received message, the message is
discarded.
A message is composed of an 11− or 29−bit

identifier, a control field, and up to 8 bytes of data.
When a message must be transmitted, the message
controller transfers the message into the transmit
buffer of the CPK in order to start the message
transmission at the next bus−idle state. When more
than one message must be transmitted, the message
with the highest priority that is ready to be
transmitted is transferred into the CPK by the
message controller. If two mailboxes have the same
priority, then the mailbox with the higher number is
transmitted first.
The timer management unit comprises a

time−stamp counter and apposes a time stamp to all
messages received or transmitted. It generates an
interrupt
when a message has not been received or
transmitted during an allowed period of time
(time−out). The time−stamping feature is available
in eCAN
mode only.

To initiate a data transfer, the transmission request

bit has to be set in the corresponding control register.
The entire transmission procedure and possible error
handling are then performed without any CPU
involvement. If a
mailbox has been configured to receive messages,
the CPU easily reads its data registers using CPU
read instructions. The mailbox may be configured to
interrupt the CPU after every successful message
transmission or reception.
Standard CAN Controller (SCC) Mode
The SCC Mode is a reduced functionality mode of the

eCAN. Only 16 mailboxes (0 through 15) are available
in this mode. The time stamping feature is not
available and the number of acceptance masks
available is reduced.
This mode is selected by default. The SCC mode or
the full featured eCAN mode is selected using bit SCB
(CANMC.13).
Memory Map
The eCAN module has two different address

segments mapped in the TMS320x28xx memory. The
first segment is used to access the control registers,
the status registers, the acceptance masks, the time
stamp, and the time−out of the message objects.
The access to the control and status registers is

limited to 32−bit wide accesses. The local

acceptance masks, the time stamp registers, and the
time−out registers can be accessed 8−bit, 16−bit
and 32−bit wide. The second address segment is
used to access the mailboxes. This memory range
can be accessed 8−bit, 16−bit and 32−bit wide.
Each of these two memory blocks, shown in Figure

1−4, uses 512 bytes of address space.
The message storage is implemented by a RAM that
can be addressed by the CAN controller or the CPU.
The CPU controls the CAN controller by modifying the
various mailboxes in the RAM or the additional
registers. The contents of the various storage
elements are used to perform the functions of the
acceptance filtering, message transmission, and
interrupt handling. The mailbox module in the eCAN
provides 32 message mailboxes of 8−byte data
length, a 29−bit identifier, and several control bits.
Each mailbox can be configured as either transmit or
receive. In the eCAN, each mailbox has its individual
acceptance mask.
Message Objects
The eCAN module has 32 different message objects

(mailboxes). Each message object can be configured
to either transmit or receive. Each message object
has its individual acceptance mask.
A message object consists of a message mailbox
with:
 The 29−bit message identifier
 The message control register
 8 bytes of message data

 A 29−bit acceptance mask
 A 32−bit time stamp
 A 32−bit time−out value
Furthermore, corresponding control and status bits
located in the registers allow control of the message
objects.
Message Mailbox
The message mailboxes are the RAM area where the

CAN messages are actually stored after they are
received or before they are transmitted. The CPU
may use the RAM area of the message mailboxes
that are not used
for storing messages as normal memory.
Each mailbox contains:
✔ The message identifier
✔ 29 bits for extended identifier
✔ 11 bits for standard identifier
✔ The identifier extension bit, IDE (MSGID.31)
✔ The acceptance mask enable bit, AME
(MSGID.30)
✔ The auto answer mode bit, AAM (MSGID.29)
✔ The transmit priority level, TPL
(MSGCTRL.12−8)
✔ The remote transmission request bit, RTR
(MSGCTRL.4)
✔ The data length code, DLC (MSGCTRL.3−0)
✔ Up to eight bytes for the data field
Each of the mailboxes can be configured as one of
four message object types Transmit and receive

message objects are used for data exchange

between one sender and multiple receivers (1 to n
communication link), whereas request and reply
message objects are used to set up a one−to−one
communication link.
Transmit Mailbox
The CPU stores the data to be transmitted in a

mailbox configured as transmit mailbox. After writing
the data and the identifier into the RAM, the message
is sent if the corresponding TRS[n] bit has been set,
provided the mailbox is enabled by setting the
corresponding the CANME.n bit.
If more than one mailbox is configured as transmit

mailbox and more than one corresponding TRS[n] is
set, the messages are sent one after another in
falling
order beginning with the mailbox with the highest
priority. In the SCC−compatibility mode, the priority
of the mailbox transmission depends on the mailbox
number. The highest mailbox number (=15)
comprises the highest transmit priority.
In the eCAN, the priority of the mailbox transmission

depends on the setting of the TPL field in the
message control field (MSGCTRL) register. The
mailbox with the highest value in the TPL is
transmitted first. Only when two mailboxes have the
same value in the TPL is the higher numbered
mailbox transmitted first.

If a transmission fails due to a loss of arbitration or

an error, the message transmission will be
reattempted. Before reattempting the transmission,
the CAN module checks if other transmissions are
requested and then transmits the mailbox with the
highest priority.
Receive Mailbox
The identifier of each incoming message is compared

to the identifiers held in the receive mailboxes using
the appropriate mask. When equality is detected, the
received identifier, the control bits, and the data
bytes are written into the matching RAM location. At
the same time, the corresponding
receive−message−pending bit, RMP[n] (RMP.31−0),
is set and a receive interrupt is generated if enabled.
If no match is detected, the message is not
stored.
When a message is received, the message controller

starts looking for a matching identifier at the mailbox
with the highest mailbox number. Mailbox 15 of the
eCAN in SCC compatible mode has the highest
receive priority; mailbox
31 has the highest receive priority of the eCAN in
eCAN mode. RMP[n] (RMP.31−0) has to be reset by
the CPU after reading the data. If a second message
has been received for this mailbox and the receive
message pending bit is already set, the
corresponding message−lost bit (RML[n]
(RML.31−0)) is set. In this case, the stored message

is overwritten with the new data if the

overwrite−protection bit OPC[n] (OPC.31−0) is
cleared; otherwise, the next mailboxes are checked.
If a mailbox is configured as a receive mailbox and
the RTR bit is set for it, the mailbox can send a
remote frame. Once the remote frame is sent, the
TRS bit of the mailbox is cleared by the CAN module.
CAN Module Operation in Normal Configuration
If the CAN module is being used in normal

configuration (i.e., not in self−test mode), there
should be at least one more CAN module on the
network, configured for the same bit rate. The other
CAN module need NOT be configured to actually
receive messages from the transmitting node. But, it
should be configured for the same bit rate. This is
because a transmitting CAN module expects at least
one node in the CAN network to acknowledge the
proper reception of a transmitted message. Per CAN
protocol specification, any CAN node that received a
message will acknowledge (unless the acknowledge
mechanism has been explicitly turned off),
irrespective of whether it has been configured to
store the received message or not.
The requirement of another node does not exist for

the self−test mode (STM). In this mode, a
transmitting node generates its own acknowledge
signal. The only requirement is that the node be
configured for any valid bit−rate. That is, the bit

timing registers should not contain a value that is not

permitted by the CAN protocol.

The Controller Area Network

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Controller Area Network

Uploaded by

Copyright:

Available Formats

Controller Area Network

Bosch originally developed the Controller Area

Milestones of CAN History

1983 Start of the Bosch internal project to

DEPARTMENT OF COMPUTER SCIENCEPage 1

1986 Official introduction of CAN protocol

1987 First CAN controller chips from Intel and

1991 Bosch’s CAN specification 2.0 published.

1991 CAN kingdom CAN based higher layer

1992 CAN in automation (CiA) international

1992 CAN application layer (CAL) protocol

1992 First car’s from Mercedes Benz used CAN

1993 ISO 11898 standard published.

1994 First international CAN conference (iCC)

1994 Device net protocol introduction by Allen

DEPARTMENT OF COMPUTER SCIENCEPage 2

1995 ISO 11898 amendment (Extended Frame

1995 CAN open protocol published by CiA.

2000 Development of the Time triggered

DEPARTMENT OF COMPUTER SCIENCEPage 3

The Controller Area Network (the CAN bus) is a serial

DEPARTMENT OF COMPUTER SCIENCEPage 4

software packages that provide system designers,

CAN technology used in Cars

A new solution was needed and, in the mid 1980s,

Industrial Applications of CAN

DEPARTMENT OF COMPUTER SCIENCEPage 6

DEPARTMENT OF COMPUTER SCIENCEPage 7

requirements that need to be built into medical

How does CAN works?

DEPARTMENT OF COMPUTER SCIENCEPage 8

determines the priority of the message. The lower

DEPARTMENT OF COMPUTER SCIENCEPage 9

that any transmission errors are detected. See the

Arbitrary Works on the CAN Bus:

DEPARTMENT OF COMPUTER SCIENCEPage 10

Slower changing parameters may be the

DEPARTMENT OF COMPUTER SCIENCEPage 11

efficiency benefits that cannot be gained from either

CAN Message Format

DEPARTMENT OF COMPUTER SCIENCEPage 12

messages - but then ignore them. 2.0B controllers

Fig.CAN 2.0A Message Frame

A Control Field containing six bits:

The CRC field, containing a fifteen bit cyclic

DEPARTMENT OF COMPUTER SCIENCEPage 14

- In Version 2.0B the Arbitration field contains two

DEPARTMENT OF COMPUTER SCIENCEPage 15

- The second (known as 2.0B passive) is capable of

DEPARTMENT OF COMPUTER SCIENCEPage 16

data format) and Extended CAN - also known as

In the receive path, an acceptance filtering is

Because there are only two buffers for the reception

Therefore Basic-CAN devices should only be used at

DEPARTMENT OF COMPUTER SCIENCEPage 17

DEPARTMENT OF COMPUTER SCIENCEPage 18

this way, the CPU load is strongly reduced compared

Many Full-CAN controller provide a "Basic-CAN

DEPARTMENT OF COMPUTER SCIENCEPage 19

The number of nodes that can exist on a single

The OSI model

DEPARTMENT OF COMPUTER SCIENCEPage 20

occur between computers on any network, and has

Fig.OSI reference model.