Download CAN Communication Protocol - University of Wisconsin

CAN Communication
Ann Lazare
Software Engineering
University of Wisconsin-Platteville
Abstract
The Controller Area Network (CAN) implements a vehicle bus to which all CAN devices are
connected. This allows the devices to communicate with one another without having to have a
single computer with which all the devices must channel their messages. This message-based
protocol was designed specifically for automotive applications and released in 1986 with the first
CAN controller chips on the market in 1987. Since then CAN communication has become
widespread and Controller Area Networks can be found anywhere from medical equipment like
CAT scanners to something as seemingly simply as an automated coffee maker. CAN is popular
since it provides fast and reliable communication at a relatively inexpensive price. This paper
will describe the details of the CAN message frames and key points in the CAN communication
protocol.
History of CAN
The Controller Area Network was developed in Germany in the 1980's by engineers working at
Robert Bosch. The engineers wished to add more functionality to the Mercedes-Benz vehicles
they were designing while reducing the weight and complexity of the wiring between controllers.
This lead to the use of a bus system based on serial communication. [2]
The bus resulted in a multi-processor system which inherently has better performance, increased
reliability and is more maintainable. However, no communication protocols at the time met the
speed and reliability requirements. This led Robert Bosch to develop their own standard, CAN
specification 2.0, which was introduced in 1986 and published in 1991. [1]
Benefits of CAN
One of the reasons that CAN is such an easy protocol to implement and use is due to the fact that
CAN only implements the physical layer, data link layer and application layer of the ISO model
shown below.
2
Figure 1: ISO model
The physical layer is completely implemented in the CAN node hardware by the manufacturer.
The physical layer includes communication details like measuring electrical signals like voltage
level and monitoring timing of the network. [3]
The data link layer connects the data read by the physical layer to the protocol itself by
interpreting the data as errors, fault confinement, acknowledgements or other communication
details. [1]
The final layer is the application layer and the essence of CAN is that this is the only layer the
software developer must implement. They must define how the operation system interacts with
the CAN devices in the network. This can be done by interacting with the data and physical layer
by initializing them, reading to them and writing from them and finally by checking status' and
flags the lower layers set. [1]
Another benefit of CAN is its low cost. Since most major semiconductor manufacturers sell
CAN chips and millions are used in cars and other applications the chips remain relatively cheap
and have world wide acceptance. [1]
CAN Communication Protocol Defined
CAN has four different message types, or frames, defined: data frame, remote request frame,
error frame and overload frame. The data frame sends data and the remote request frame requests
data and results in the sending of a data frame. The error frame reports an error and the overload
frame is sent by an overloaded or overwhelmed node to cease transmissions of data temporarily
until it can process the data in its buffer and recover. [1]
Data Frame and Remote Request Frame
A data frame and remote frame are almost identical in description and can therefore be explained
together.
3
Figure 2: Data Frame/Remote Frame
The first bit is a start of frame bit. When the bus is idle the bus will be at a recessive (high) level
for 11 consecutive bits. The start of frame is a dominant (low) bit which signals to all nodes on
the bus that a message is beginning. The falling edge of the start of frame bit also serves as a
means to synchronize the nodes in the network. [5]
The arbitration is next and consists of an 11 bit message ID followed by the remote transmission
request. The message ID signifies the meaning of the data the message contains, not where the
frame came from or is going. The message ID is also used to prioritize messages in the system
where a lower message ID represents a higher priority message. The remote transmission request
is a single bit which is recessive for a remote request frame and dominant for a data frame. [5]
The control field is next which contains bit DLC3 to DLC0 which use the following lookup table
to determine the size of the data to follow.
Table 1: Data length lookup table
Note that the maximum size of the data that may be sent with a data frame is 8 bytes. If the
remote transmission request is set to a remote request frame then the data length code is ignored.
Next the specified amount of data follows for a data frame or nothing for a remote request frame.
[5]
Following the data is a 15 bit cyclical redundancy checker (CRC) from the start of frame bit
through the data and a 1 bit CRC delimiter bit which is always recessive. [5]
4
The next segment is an acknowledgment bit which specifies if the CRC was correct. If it was the
bit is recessive, if not it is dominant. The ACK also has a delimiter bit which is always recessive.
[5]
The last part of the frame is the end of frame segment which always has 7 recessive bits and is
followed by the interframe space which leaves space in between message and has 3 recessive
bits. Notice that the ACK delimiter, end of frame segment and interframe space result in the 11
recessive bits that signify the bus is idle and another message may be broadcast. [5]
Extended Data Frame
Another point to note about the data frame is that there is an alternate version of CAN available
(CAN 2.0B) which implements an extended message ID. The traditional CAN specification
(CAN2.0A) implements the 11 bit message ID which results in 2,048 different message types.
For some applications, particularly off-road vehicles this is not enough and the extended CAN
message consists of a 29 bit message ID resulting in over 536 million messages. Both standards
may coexist on the bus but the 11 bit message ID always has a higher priority over the 29 bit
extended version. The extended version also results in several down sides including transport
delay, greater bandwidth needs and errors since the CRC is optimized for message frames up to
112 bits and the 29 bit message ID results in frame of greater length. [5]
Error Frame
The second message type that is transmitted on the CAN bus is the error frame as shown below:
Figure 3: Error Frame
An error frame begins with the error flag sent consisting of 6 dominant bits followed by the error
delimiter of 8 recessive bits and the interframe space of 3 recessive bits. The first point to note is
that any time more than 5 bits of the same polarity are detected on the bus, a node responds by
sending out an error frame. This means that all nodes detect a single error frame and respond
with their own error frame resulting in a superposition of error flags or simply time when one
node may have finished transmitting but not another. Another point to note is that the error
delimiter and interframe result in the 11 recessive bits that once again signal the bus is idle after
the error occurs. When an error frame is received on the bus, it results in the retransmission of
the previous data or remote frame where the error occurred. [5]
5
Overload Frame
The final message type on the bus is the overload flag which can be used to signal that a node is
overloaded and needs time to process the data in its buffer. When this happens the node simply
sends out the following message frame:
Figure 4: Overload Frame
The frame begins with 6 dominant bits followed by the overload delimiter with 8 recessive bits
and the interframe space with 3 recessive bits. Notice that in terms of bits this is identical to an
error frame and therefore results in the same response. That is, all nodes cease messaging,
allowing the overloaded node time to process its data, and to transmit the overload frame. [5]
Message Broadcasting
The message broadcasting in CAN consists of a producer consumer model in which one node
produces a message frame and all other nodes on the bus consume the message. All nodes
receive the same message at the same time and simply react to the relevant messages based on
the message ID found in the data and remote frames. All messages go to a nodes buffer where
they are acknowledged for consistency and if a message is relevant it is filtered and processed by
the node. [1]
Bus Arbitration
One question that ought to be asked as this point is that given the producer consumer model, how
do the nodes know when to transmit messages on the bus without colliding with another nodes
message sending. CAN uses bitwise arbitration to solve this question and prevent collisions on
the bus. The first fact to establish is that the bus is recessive only if all nodes are recessive,
otherwise the bus is dominant. To reiterate, if a single node transmits a dominant bit, the bus will
be dominant. CAN uses this fact to establish bitwise arbitration using the message ID's of the
data and remote frames where a lower message ID has higher priority. The bitwise arbitration
works as follows: If a node sends a start of frame with a dominant bit all non-sending nodes
begin listening; A node sends the next bit and compares their output signal to that of the actual
bus level and if they sent a recessive bit but detect a dominant bit they begin listening since a
6
node with higher priority has evidently transmitted the dominant bit; If a node sends bits but
finds that the bus level matches their output signal they continue transmitting the rest of the
message and if they transmit all message ID bits they have won the arbitration process and may
send their message. The following example may be more helpful in describing the arbitration
process:
Figure 5: Bus Arbitration Example
Since node A has a lower message ID (higher priority) we know that node A should win the
arbitration process. So assume node A and B begin to transmit at the same time. Node A and B
both transmit and recessive bit and read that the bus level is recessive and continue transmitting.
With the second bit, node A transmits a dominant bit and reads that the bus level is dominant and
continues transmission. Node B however transmits a recessive bit and reads the dominant bus
level. This tells node B that a node with higher priority must have transmitted the dominant bit
and so node B stops transmitting and begins listening. [1]
Error Detection
Errors on the CAN bus are detected through bit monitoring, the checksum, bit stuffing, frame
checks and acknowledgement checks and all generate an error frame. Bit monitoring occurs
when the nodes compare the bit they're transmitting with the bus level. As seen in the bus
arbitration and node may transmit a recessive bit and read a recessive or dominant but level and
may transmit a dominant bit and read a dominant bus level. However, if a node transmits a
dominant bit and reads a recessive bus level, this is an error. The checksum is a 15 bit
polynomial calculation from the start of frame bit through the data bytes. The checksum the
frame contains is compared with the checksum the node calculates and if the checksum do not
match, an error has occurred. Bit stuffing refers to the event when more than 5 bits of data with
the same polarity are received in a row with the exception of the data bytes. This can occur due
to malfunctioning nodes or noise on the bus and is an error. Frame checks involve examining the
CRC and ACK delimiters, the end of frame field and the intermission field. All of these bits
should be recessive and if they are dominant an error has occurred. Finally, the
acknowledgement bit is used to reply that the checksum was calculated correctly. A dominant
ACK is always expected and if the bit is recessive, either the CRC was incorrect or the ACK bit
was flipped resulting in this error condition. [1]
Fault Confinement
7
When errors occur on the bus, CAN is quick to recover and continue normal processing. When
this happens, a temporary error may have occurred due to an electrical disturbance or other
environmental effect. Permanent errors can also occur on the bus, though and need to be
rectified. A permanent malfunction that could disrupt the system could be a transmitting error
from a malfunctioning node or a receiving error from a malfunctioning node. When a
transmitting error occurs, a node with high priority sends a defective frame to the bus. All other
nodes on the bus report the error and the malfunctioning node retransmits the same defective
frame over and over. When a receiving error occurs a node receives a good frame but reports an
error and the sending node retransmits the same good frame continually as the malfunctioning
node continues to report an error. Both of these situations could result in a hold up on the bus of
normal messaging and thus need to be rectified. CAN detects and fixes these errors by
implementing two counters on each CAN node: a transmit error counter and a receive error
counter. Based on the counters, the CAN nodes can be in an error active, error passive or bus-ff
state. When a node is in an error active state both counters are less than 128 which means that the
node is working properly and the error flag the node transmits consists of the typical 6 dominant
bits. An error passive node has a transmit or receive counter greater than 127 and they can
retransmit a message if an error is reported by another node but cannot report an error in
response to another nodes message. This results in fixing an error thrown from a malfunctioning
receiving node but not a malfunctioning transmitting node. Therefore, if the transmit counter
continues to ramp up and the transmitting counter is greater than 255 a node is a malfunctioning
transmitting node and has a self retirement function which removes the malfunctioning node
completely from all bus communication. When this occurs the only way to recovery is by user
interaction in the form of a hardware reset of the counters. [1]
Physical Layer
The CAN physical layer is most commonly described by ISO 11898-2. The physical layer
consists of nodes connected by 2 wires: CAN_H (CAN high) which is typically 3.5V and
CAN_L (CAN low) which is typically 1.5V. The bus level is determined by the difference
between these two voltages as Vdiff = Vcan_h – Vcan_l and so a recessive level is typically 2V
and a dominant level is 0V. The benefit in using the voltage differential to determine the bus
level is that if there is electrical interference on the bus, Vcan_h and Vcan_l are typically
affected in the same way by the interference and so the differential remains unchanged. The bus
is terminated by two 120Ω resistors to suppress these electrical reflections though. Due to the
durability of this physical layer the CAN bus can be up to 40m long at a maximum baud rate of 1
Mbit/sec and using a lower baud rate of <10 kbit/sec a CAN bus can be as long as 5000m long.
[3]
Conclusion
CAN communication has shown to be a relatively inexpensive yet extremely reliable protocol to
implement and it's no wonder it is found in so many application today. The simplicity that CAN
offers developers in having the physical and data link layer implemented in the CAN hardware
itself makes engineering with CAN an easy pick and the simplicity of the protocol using the four
message frames: the data frame, remote frame, error frame and overload frame makes CAN easy
to understand and use. The CAN network itself makes use of the producer consumer pattern
8
allowing for a single bus which also helps to reduce cost and increase simplicity. The wide use of
CAN today through higher layer protocols such as DeviceNet and CANOpen make even the
most complex tasks implementable using the basic CAN protocol as a base and CAN will no
doubt continue to be a good choice for developers in the future in both automotive and industrial
applications.
References
[1]
Wilfried Voss. (2005). A Comprehensible Guide to Controller Area Network. Greenfield:
Copperhill Technologies Corporation.
[2]
Pazul Keith. (2002). Controller Area Network (CAN) Basics. In Microchip.
[3]
CiA. (2001). Can physical layer. Retrieved 1 24, 2012, from http://www.cancia.de/index.php?id=systemdesign-can-physicallayer
[4]
International Standard ISO 11898. First edition 2003-12-01. Road vehicles - Controller
area network (CAN).
[5]
Robert Bosch. (1991). CAN Specification. Robert Bosch GmbH.
[6]
National Instruments. (2012). Controller Area Network (CAN) Overview. Retrieved 2 2,
2012, from http://zone.ni.com/devzone/cda/tut/p/id/2732
[7]
Vehicle Spy. (2005-2012). Vehicle Spy Professional. Retrieved 2 4, 2012 from
http://intrepidcs.com/VehicleSpy/
[8]
CANopen. CANopen USA. Retrieved 2 4, 2012 from http://www.canopen.us/
[9]
Real Time Automation. DeviceNet Introduction. Retrieved 2 4, 2012 from
http://www.rtaautomation.com/devicenet/#2