The Controller Area Network (CAN) protocol incorporates a powerful means of seamlessly preventing data corruption during message collision. This arbitration process and its relationship to the electrical layer variables are explained. Techniques to force message collision and test arbitration are demonstrated with strategies to leverage arbitration as a quantitative benchmark in safety-critical systems. The benchmark is then applied to several example systems and results provided for comparison.
The ability of a Controller Area Network to manage message collision provides a unique proving ground for protocol compliance in any application. A means of determining a benchmark for a system’s performance by measuring a network’s ability to execute proper arbitration is developed in this example. It is demonstrated that while a CAN bus appears to be functioning normally, many arbitration errors may be unnoticed by system operators.
In CAN there are two main Hardware Implementations, they are Basic CAN and Full CAN.
Basic CAN: Basic CAN has only one Message buffer for Receive and Transmit messages. The received message is accepted or ignored after acceptance filtering. The decision to process a message or to ignore it is also achieved by acceptance filtering. This acceptance filtering of the node is done by software in Basic CAN. To reduce the software load at the nodes, there is a possibility to ignore some messages by ignoring specific identifiers. This is realized by bit mask for the message identifiers.
Full CAN: In Full CAN, there are 8 to 16 memory buffers for every transmitted or received message. Here the acceptance filtering is done by hardware and not by the software. Every buffer can be configured to accept messages with specific ID’s.
Since the acceptance filtering is done by hardware, the software load is greatly reduced. With different buffers for different messages ensures more time for the processing of the received messages and the transmitted message can be handled according to the priority levels. Configuring each buffer for every message ensures also the data consistency in Full CAN.
Since any CAN node may begin to transmit when the bus is free, two or more nodes may begin to transmit simultaneously. Arbitration is the process by which these nodes battle for control of the bus. Proper arbitration is critical to CAN performance because this is the mechanism that guarantees that message collisions do not reduce bandwidth or cause messages to be lost. Each data or remote frame begins with an identifier, which assigns the priority and content of the message. As the identifier is broadcast, each transmitting node compares the value received on the bus to the value being broadcast. The higher priority message during a collision has a dominant bit earlier in the identifier. Therefore, if a transmitting node senses a dominant bit on the bus in place of the recessive bit it transmitted, it interprets this as another message with higher priority transmitting simultaneously. This node suspends transmission before the next bit and automatically retransmits when the bus is idle. The result of proper arbitration is that a high-priority message transmitted without interruption is followed immediately by a low-priority message, unless of course, another high-priority message attempts to broadcast immediately following the same message. Since no messages are lost or corrupted in the collision, data and bandwidth are not compromised.
Electrical-Layer Variables (bit timing requirements)
Each CAN bit is divided into four segments (see Figure 1). The first segment, the synchronization segment (SYNC_SEG), is the time that a recessive-to-dominant or dominant-to-recessive transition is expected to occur. The second segment, the propagation time segment (PROP_SEG), is designed to compensate for the physical delay times of the network as shown in Figure 2, and should be twice the sum of the propagation delay of the bus, the input comparator delay, and the output driver delay. The third and fourth segments, both phase buffer segments (PHASE_SEG1 & PHASE_SEG2), are used for resynchronization. The bit value is sampled immediately following PHASE_SEG1.
bit rate may be changed by either changing the oscillator frequency, which is
usually restricted by the processor requirements, or by specifying the length
of the bit segments in “time quantum” and the prescaler value. The prescaler
value is multiplied by the minimum time quantum, which is the reciprocal of the
system clock frequency, 1/f sys , to determine the length of a working time
quantum. Bit time may then be calculated as the sum of each bit segment, and
the bit rate may be calculated as the reciprocal of this sum.
Each node must perform a hard synchronization upon every recessive-to-dominant edge after a bus idle or received start of frame. Hard synchronization is a restarting of the internal bit timing to force the edge into the SYNC_SEG, where edges are expected to occur. Resynchronization is performed on all other recessive-to-dominant edges of other received bits by lengthening or shortening the PHASE_SEG1 or PHASE_SEG2 by one to four time quanta as specified by the resynchronization jump width. If the difference between the edge causing resynchronization and the SYNC_SEG exceeds the resynchronization jump width, the effective result is the same as a hard synchronization.
CAN Network Errors
CAN protocol specifies five different types of network errors. A transmitting node detects a bit error when it monitors a bit value different than it is transmitting; the reaction to this condition varies with the nature of the error. A stuff error occurs when the bit-stuffing rule is violated – a bit of opposite value must be inserted immediately following any series of five consecutive bits of the same value in a message. A cyclic redundancy check (CRC) error occurs when a receiving node receives a different CRC sequence than anticipated. (Note that all nodes independently calculate the CRC sequence from the data field). A form error occurs when a field contains an illegal bit value. Finally, an acknowledgement (ACK) error occurs when the transmitter does not monitor a dominant bit in the ACK slot to signify that the message had been received properly by another node as shown in Figure 2. When a node detects a bus error, it transmits an error frame consisting of six dominant bits followed by eight recessive bits. Multiple nodes transmitting an error frame will not cause a problem because the first recessive bits will be overwritten. The result will remain six dominant bits followed by eight recessive bits, and cause the bus to be safely reset before normal communications recommence.
The CAN protocol provides a means of fault confinement by requiring each node to maintain separate receive and transmit error counters. Either counter will be incremented by 1 or 8, depending on the type of error and conditions surrounding the error. The receive error counter is incremented for errors during message reception, and the transmit error counter is incremented for errors during message transmission (for further details, see reference 1). When either of these counters exceed 127, the node is declared “error-passive,” which limits the node from sending any further dominant error frames. When the transmitted error count exceeds 255, the node is declared “bus-off,” which restricts the node from sending any further transmissions. The receive and transmit error counters are also decremented by 1 each time a message is received or transmitted without error, respectively. This allows a node to return from error-passive mode to error-active mode (normal transmission mode) when both counters are less than 128. The node may also return to error-active mode from bus-off mode after having received 128 occurrences of 11 consecutive recessive bits. Overall, a network maintains constant transmit and receive error counters if it averages eight properly transmitted or received messages for each error that occurs during transmission or reception, respectively.
Controller Area Network (CAN) started life in 1983 at Robert Bosch GmbH as a serial data bus standard for the interconnection of microcontrollers in vehicles. Although originally designed specifically for automotive applications, it is now also used in other applications. The protocol was officially released in 1986, and the first CAN controller chips, produced by Intel and Phillips, were available commercially in 1987. The CAN 2.0 specification was published by Bosch in 1991. The data link and physical layers of CAN for data rates of up to 125 kbps (described as “low-speed serial data communication” were defined in part two of the original ISO standard published in 1994 (ISO 11519). Part 1 of a later ISO standard published in 2003 (ISO 11898) covers the data link and physical layers of CAN, but for data rates of up to 1 Mbps. There are also a number of other related standards. The higher layer protocols used with CAN depend on the application. A number of microcontrollers (for example, Microchip Technology’s PIC Microcontrollers) now have CAN support built-in.
A modern car will typically have in the order of fifty (and sometimes a lot more) electronic control units (ECUs) controlling various automotive sub-systems. The largest microprocessor unit in a car is usually the engine control unit (also, confusingly, commonly abbreviated to ECU). Other microprocessors control elements ranging from the transmission system and braking system, right down to cosmetic elements such in-car audio systems, and driving mirror adjustment. Some of these subsystems operate independently, but others need to communicate with each other and process and respond to data received from sensors. The CAN bus in a vehicle control system will typically connect the engine control unit with the transmission control system, for example. It is also highly suited to use as a fieldbus in general automation environments, and has become widely used for such applications, in part because of the low cost, small size and availability of many CAN controllers and processors. In automotive systems, they are an ideal alternative to expensive, cumbersome and unreliable wiring looms and connectors.
A CAN network interconnects control devices, sensors and actuators (collectively referred to here as nodes). Every node attached to a CAN bus can send and receive data, but not at the same time. A message consists primarily of an identifier that identifies the type and sender of the message, and up to eight bytes of actual data. The physical medium in a CAN network is a differential two-wire bus (usually either unshielded or shielded twisted pair), and the signaling scheme used is Non-Return to Zero (NRZ) with bit stuffing. Because CAN is essentially a broadcast network, messages will be received by all nodes. The messages do not reach the devices directly, but via each node?s host-processor and CAN Controller. These elements sit between the node itself and the data bus. Any node may transmit a message providing the bus is free. If two or more nodes transmit at the same time, the system of arbitration is simply to give priority based on message ID number. The message with the higher priority ID will overwrite all other messages, and any nodes responsible for the lower priority messages will back off and wait before retransmitting.
Each node will have a host-processor that interprets incoming messages and determines when it needs to send outgoing messages, sensors, actuators and control devices, which can be connected to the host-processor as required, and a CAN Controller which is implemented in hardware and has a synchronous clock. The CAN controller buffers incoming messages until they can be retrieved by the host-processor, generating an interrupt to let the host processor know that a message is waiting. The CAN Controller is also the buffer for outgoing messages, which it receives from the host-processor and then transmits via the bus. A transceiver handles message processing, and is usually integrated into the CAN Controller. The data rates possible are dependent on the length of the bus. Data rates of up to 1 Mbps are possible at network lengths below 40 metres. Decreasing the data rate to 125 kbps would allow a network length of up to 500 metres.
Transmission of messages in a CAN is based on the producer-consumer (broadcast) principle. A message transmitted by one node (the producer) is received by all other nodes (the consumers). Messages do not have a destination address, but a Message ID. Messages in the standard format have an 11-bit Message ID, enabling 2,048 different messages to be defined for any one system – more than sufficient for most applications. For applications that require a larger number of messages, an extended message format with a 29-bit Message ID may be used, allowing over five hundred million different messages to be defined. Only certain messages will apply to each node on the network, so a node receiving a message must apply acceptance filtering (usually implemented in hardware, and based on the Message ID). If the message received by a node is relevant to it, it will be processed, otherwise it will be ignored. CAN networks may be expanded without modification to existing hardware or software if the devices to be added are purely receivers, and if they only require messages that are already generated by the network.