Advancements in automotive electronics have brought huge benefits to automotive manufacturers and customers alike. Powerful electronic control units (ECU) integrated into electronic control systems provide dramatic improvements in comfort, vehicle control, and performance and help reduce emissions.
The real-time sharing of information between these ECUs can decrease the overall cost of the vehicle by reducing the number of sensors required. Information such as wheel speed and engine temperature may be shared between ECUs, eliminating the need for redundant sensors.
To answer the need for real-time sharing of vehicle information, these ECUs are linked with a high-speed communications bus. Some of the more popular real-time automotive serial buses used worldwide are based on the controller area network (CAN) protocol. The CAN bus protocol has unique features and challenges for automotive designers and manufacturers.
Background
The CAN protocol was developed by Robert Bosch, GmbH in response to the need for high-speed communications in automotive applications. The robustness and error-detection capabilities of CAN make it ideal for all types of harsh electrical environments.
The initial release of the CAN specification was CAN 1.2. It specified an 11-bit message ID, known as the standard message format, and limited the number of unique messages to 2,032. As CAN became more popular, it was clear that more than 2,032 message IDs would be necessary. Bosch updated the CAN specification to include 29 bits of message ID, known as the extended message format.
The definition for the extended message format is included in CAN 2.0, the latest release. The CAN 2.0 specification contains two parts:
Part A describes the CAN message format as defined in CAN 1.2.
Part B describes the extended format CAN.
The CAN specification itself really only addresses the data-link layer of the seven-layer Open Systems Interconnect (OSI) model. The data-link layer defines characteristics such as the construction of the message frame, arbitration, and error checking. The CAN specification doesn’t define the electrical interconnect (physical layer) or the upper layers of the OSI protocol stack.
The developers at Bosch intentionally limited the CAN specification to address only this layer so it could be adapted and optimized to the application as required. This gives designers of a CAN-based bus the flexibility to choose the electrical interconnect and the ability to define network management messages and characteristics.
Media such as single-ended electrical, differential electrical, or even optical may all be used within the definition of CAN. However, this flexibility also can be a cause of confusion since both the electrical and network messaging characteristics may vary from application to application.
Fortunately, physical-layer definitions are provided by some of the more popular ISO and Society of Automotive Engineers (SAE) protocols based on CAN. Two ISO specifications are based on CAN: ISO 11898 for high-speed applications and ISO 11519 for low-speed applications. SAE adopted the CAN protocol within the J1939 specification targeted for truck and bus applications.
ISO 11898, ISO 11519, and J1939 are based on a 5-V differential electrical bus as shown in Figure 1. Many automotive CAN applications are based on one of these three specifications and, as a result, use a differential physical layer.
But be aware that this is not always the case. Some CAN applications may be based on a single-ended, Vbatt-referenced physical layer. To be sure, always get clarification on which physical layer is used when discussing a CAN application.
As with the physical layers, the system designers of CAN applications are free to choose a specific implementation of the higher protocol layers. The defined characteristics of the higher protocol layers (HPL) include, but are not limited to, message IDs and meanings, data formats, network keep-alive messages, and wake-up, shutdown sequences. As with the physical layer, when discussing a CAN bus application, be sure that the HPL characteristics are defined and understood.
As we can see, the CAN protocol is limited in focus to the data-link layer. However, CAN is such a solid foundation for communications buses that it is used by many automotive and industrial serial bus designers. An understanding of the characteristics and features defined by the CAN specification is the first step in realizing the full power of CAN.
A Message-Based Structure
The CAN protocol is unique because it is message-based instead of address- based. That is, the devices on the serial bus and the messages exchanged are not explicitly based on node addresses. Instead, a message ID is used to define the content and priority of the data within the message.
This simple concept has great advantages in automotive applications since the bus may operate in a single broadcaster, multiple-receiver mode. All devices on the bus that need information in the message will receive it at the same time. For example, if only one device on the bus has direct access to a specific sensor, such as a wheel- speed sensor, all of the other devices on the bus may receive an update simultaneously at the instant the device with the information broadcasts the message.
Conversely, if a device on the bus needs information, it may broadcast a request for that information by sending a message identifier while asserting a special bit called the Remote Transmission Request (RTR) bit. Any module on the bus that has that information may respond to the request.
This message-based characteristic makes it easy for an ECU to be added to a CAN-based system if the ECU simply needs information. In this case, there is no need to modify the other modules on the bus. Just physically attach the new ECU to the bus, and it will listen to the proper message IDs which contain the information it requires.
Multiple Access With Arbitration
On a CAN bus, all nodes have an equal opportunity to begin transmitting a message frame any time when the bus is idle. There are no master or slave nodes. This presents a problem if two modules detect an idle bus and proceed with sending their message at precisely the same time. A data collision will occur, and the message will be corrupted.
To resolve this issue, the CAN protocol supports nondestructive collision detection and arbitration. Simply stated, in the event that two devices on the bus begin transmitting at the same time, the CAN protocol can detect the resulting collision of data on the bus and resolve the collision. All of this is accomplished without the higher- priority message being corrupted or delayed.
The CAN bus is the Carrier Sense, Multiple Access (CSMA) type with nondestructive collision detection and arbitration. This is quite a mouthful, but its implementation is not difficult to understand. Two characteristics are essential to support nondestructive collision detection and arbitration:
Logic states are defined as recessive and dominant.
The transmitting node must monitor the bus to determine if the bits it sends are actually present on the bus.
The terms recessive and dominant indicate which state will win in the event of a bus collision; the dominant state will always overwrite a recessive state. A simple example is shown in Figure 2. In this example, the bus is an open collector wired-or bus, but the concept is the same if the bus happens to be differential in nature. Collision detection and arbitration are possible since each node is monitoring the state of the bus. If any node sends a recessive state and detects a dominant state, a bus collision has occurred and is detected by the node that sent out the recessive bit. The node that detects the collision must immediately cease transmission and give way to the node(s) that sent out the dominant bit. If we define a logic 0 to be the dominant state, the node that sends out the lower number (message ID) wins arbitration: Node A has won with the message ID of 0xF0 vs 0xF1 and 0xF3.
Message Frames
The CAN protocol defines four different message frame types: data, remote, error, and overload.
The data frame is, by far, the workhorse of all the frames. It transports data from one sending node to one or more receiving nodes.
The remote frame is similar to the data frame except that, instead of transporting data, it signifies a request for data. The frame structure for the remote frame is identical to the data frame except for a single bit, the RTR bit.
Any node on the bus may generate error frames. The error frame is unique because the assertion of the error frame may vary based on the node’s error mode that can be either passive or active. Nodes that require more time to assimilate a message may send overload frames.
Data and Remote Frames
CAN 2.0 defines two types of data and remote frames: standard and extended. The standard frame consists of an 11-bit message ID, and the extended frame consists of a 29-bit message ID. The actual data frames are shown in Figure 3 and consist of seven distinct data fields:
Start of Frame.
Arbitration.
Control.
Data.
Cyclical Redundancy Code (CRC).
Acknowledge (ACK).
End of Frame.
The start of frame is a simple, single-bit, dominant state. This may be transmitted at any time that an idle bus state has been detected.
The Arbitration-Field bit order and content depend on whether the frame is a standard or an extended frame. In both cases, the 11 most significant bits (MSBs) are transmitted first.
In the standard data frame, the RTR bit follows the 11 ID bits. The RTR bit always is transmitted as a dominant state for data frames and as a recessive state for the remote frames. This single bit changes the type of frame from data to remote. As a result, the frame will change from a source of data to a request for data. This is the major difference between a data frame and a remote frame.
The RTR, IDE SRR, and r0 bits are set dominant or recessive as specified by CAN 2.0, so a standard frame with the same 11 MSBs will have priority over an extended frame.
For extended data or remote frames, the second half of the message identification (18 bits) is transmitted next. The first seven MSBs of the message identifier may not all be transmitted as recessive. This means that the maximum number of message identifiers is 2,032 for the 11-bit headers and more than 500 million for the 29-bit headers.
The data length code declares how many data bytes will follow in the data field. This code contains four bits and is sent MSB first.
The CRC is a standard CRC that is optimized for bit counts less than 127. It is generated and decoded in hardware, making it a very fast error checking method for the CAN frame. Following the CRC is a single recessive bit (CRC delimiter) as well as an ACK bit and an ACK delimiter.
Both the ACK bit and its delimiter are sent as a recessive bit by the sending node. The receiving node(s) will overwrite the ACK bit with a dominant state if the message is received properly.
Finally, following the ACK bit and its delimiter is the end-of-frame field, which consists of seven consecutive recessive bits.
Bit Stuffing for Data Synchronization and Error Detection
The bits within the CAN frame are encoded using a method known as non-return to zero (NRZ) with bit stuffing. NRZ simply means that the bit level remains in either the dominant or recessive state for the duration of the bit time, as opposed to an encoding scheme such as pulse width modulation where the bit level always will return to zero at some point during the bit time.
NRZ schemes have a potential synchronization problem if the number of bits sent in the frame is more than ~10 since there may not be any level translation edges for the receiving node to synchronize on. To resolve this issue, if more than five bits are present with the same logic state, the CAN specifies that the transmitting node will stuff a bit of the opposite state into the bit stream. As a result, a synchronization edge will be generated. The receiving node will remove this extra bit, so the stuffed bit has no effect on the resulting message/data being transmitted.
Bit stuffing applies to the majority of the fields in the data and remote frame: start of frame, arbitration, control, data, and CRC.
Bit stuffing also serves as one method for error detection on the bus. If more than five bits are received with the same bit value, the bit-stuffing rule is violated, and an error is immediately detected.
Error Frame
Receiving nodes on the CAN bus may generate an error frame if any one of several error types is detected. The error frame consists of six error flags (bits) followed by a single recessive delimiter bit. The receiving node that detects the error condition may assert its error frame at the instant that an error is detected, even if it is within the middle of the original data frame.
Since the error frame consists of six bits, the error frame will violate the bit-stuffing criteria. As a result, all of the nodes on the bus register an error. All of the nodes will superimpose their error frame on top of the original error frame.
At first, this type of error handling appears to be excessive. However, this approach ensures that either all or none of the nodes receive the data successfully. This characteristic is important in real-time control systems since, in many cases, data throughout the system must be synchronous. Having the original data frame destroyed by the error frame forces the original source node to rebroadcast the data to all destinations.
In the event that a permanent hardware failure occurs at one of the receiving nodes, it is undesirable for that failure to shut down the rest of the bus by continually asserting error frames. To prevent a single corrupt node from disrupting the rest of the bus, CAN 2.0B uses a unique error-counting scheme. The module begins operation in an error active mode where, if an error is detected, it will generate an error frame as using dominant error flag bits.
In the event that the node detects and initiates multiple errors over the course of several messages, it will internally set its mode from the error-active mode to the error- passive mode. In the error-passive mode, the error frame still is detected and generated; however, the error flags are sent in the recessive state instead of the dominant state which will not corrupt the message. In the event that a module develops a permanent fault, communications will not be disrupted for other modules on the bus.
Overload Frame
The overload frame is similar to the error frame because it consists of six overload flags (bits) with a single overload delimiter. The overload frame is only generated within a specific time window known as intermission, which occurs within a period called the interframe space. Intermission is a window of three recessive bits that immediately follow the end-of-frame field.
The overload frame is used by a receiving node to indicate that more time is required to assimilate the data frame as previously received. If sufficient message buffering is used at the receiving node, the overload frame should not be observed very often.
CAN Waveform Example
Figure 4 shows a CAN standard data frame waveform generated by an ISO 11898-compliant interface adapter. This frame has a message ID of 0x177 and a data value of 0xAABBCC. The voltage shown is the differential voltage Vcan(+) – Vcan(-). The idle state of the bus is a recessive state, resulting in a differential voltage of 0 V. When the drivers are set into the dominant state, the voltage on the bus goes to 2.1 V.
Trying to decipher the message content by looking at the waveform with an oscilloscope would be difficult at best. Several companies build interface adapter products that allow you to send and receive CAN communications using your PC. However, keep in mind that the physical layer may differ from CAN application to CAN application. Be sure that the interface adapter you are considering is compatible with the physical layer of your application.
Conclusions and Summary
In large part, the CAN protocol has been widely accepted in automotive applications because of its robust nature of message error detection, handling, and confinement as well as its high-speed capabilities and multicast nature. Due to its popularity, many chipsets for CAN are available from multiple sources. Fortunately, Bosch had the foresight to make the CAN 2.0 document public so that many applications could use this well thought-out protocol.
About the Author
Alan Lesko is a hardware design engineer at the H-P Measurement Systems Division. He is a 1980 graduate of the University of Michigan with a B.S.E.E. Hewlett-Packard, Measurement Systems Division, 815 14th St. S.W., Loveland, CO 80537, (970) 679-3074.
Copyright 1999 Nelson Publishing Inc.
January 1999