Controller Area Network (CAN Bus) - Error Detection And Fault Confinement

The following is an excerpt from  A Comprehensible Controller Area Network by Wilfried Voss.

The CAN standard utilizes a series of error detection mechanisms, which contribute to its high level of reliability and error resistance (see following Chapter - Error Detection).

 The reliability of CAN has been calculated in a mathematical model. Here is an example using the following parameters and conditions:

• 1 Bit error every 0.7 sec
• Baud rate of 500 kBit/sec
• Operation of 8 hours/day and 365 days/year
• According to this model the Residual Error Probability will be 1 undetected error in 1000 years.

Fault Confinement guarantees proper network functionality and a continued availability of the data transportation system by adjusting the behavior of defective nodes, even up to a point where a node may remove itself from the network (self-retirement).

Error Detection

CAN provides the following procedures to detect errors during a frame transmission:

• Bit monitoring

Transmitters compare the transmitted level bit by bit with the corresponding level on the bus.

• Checksum Check

Each CAN data or remote frame includes a 15 bit CRC.

• Variable bit stuffing with a stuff width of 5

A violation of the bit stuffing rule is considered a “bit stuffing” error.

• Frame Check

Each transmitting node as well as any receiving node operating within the established specifications will check the consistency of the transmitted frame.

• Acknowledge Check

All receiving nodes in a CAN network will check the consistency of the received frame and acknowledge a consistent frame or renounce an inconsistent frame. It is the responsibility of the transmitting node to check the acknowledgment (or lack thereof) and send an error frame in case the frame is reported to be corrupt.

Bit Monitoring

CAN nodes transmitting a message to the bus also monitor the bus and compare the transmitted level bit by bit with the corresponding level on the bus. A bit error is detected when the transmitted bit level differs from the monitored bus level.

However, there are exceptions:

• A dominant bit on the bus will not lead to a bit error when a recessive bit is transmitted during arbitration.
• A dominant bit on the bus will not lead to a bit error when a recessive bit is transmitted during the ACK slot.
• A node sending a passive error frame (6 consecutive recessive bits) and detecting a dominant bit will not interpret this as a bit error (see also Chapter 8.3 - Fault Confinement).

Bit monitoring not only allows global error detection within the network, but also allows the location of the error source (local error detection).

Checksum Check

The 15 bit CRC Segment (CRC = Cyclic Redundancy Code) in a data or remote frame contains the frame check sequence spanning from SOF (Start of Frame), through the arbitration field, control field and data field. Stuffing Bits are not included.

The frame check sequence is derived from a CRC (BCH = Bose-Chaudhuri-Hocquenghem code) best suited for frame lengths of less than 127 bits.

Bit Stuffing Error

A Bit Stuffing error can only occur between SOF (Start Of Frame) bit and (including) the CRC Sequence, since bit stuffing is only applied in these fields.

A bit sequence of more than 5 consecutive bits of the same level in a data or remote frame is considered a bit stuffing error.

An error frame intentionally violates the bit stuffing rule, which in turn assures that faulty data or remote frames are destroyed.

Another exception to the bit stuffing rule is the overload frame, which uses the same format as the error frame.

Frame Check Error

The following components of a CAN data or remote frame are considered static fields, since their data level is static (recessive).

• CRC Delimiter
• ACK Delimiter
• End of Frame Field
• Intermission Field

These components are also used to check the consistency of a data or remote frame. A form error is detected when either of these components contains one or more dominant bits

However, the exceptions are:

• When a receiver monitors a dominant level at the last bit of EOF (End of Frame field)
• When any node monitors a dominant level at the last bit of the error delimiter
• When any node monitors a dominant level at the last bit of the overload delimiter

No error will be reported, i.e. no frame error detected, when any of these exceptions occurs.

Acknowledgment Error

The acknowledgement field serves as a confirmation of a successful CRC (checksum) check by the receiving nodes in the network. The message transmitting node monitors the bus and expects a dominant level during the ACK slot. This will be the case when either one of the receiving CAN nodes outputs a dominant level, i.e. acknowledging a successful CRC check. An ACK Error is detected by a transmitting node in case it does not monitor a dominant bit during the ACK slot.

Dual CAN Bus Interface For Arduino Due With Extended Power Range

The jCOM.CAN.DUE-X, a dual CAN bus interface for the Arduino Due, is not an Arduino shield in the common sense. 

The board incorporates dual CAN transceivers required by the two integrated CAN ports on the Arduino Due while allowing the operation with any Arduino-compatible shield that supports the necessary 3.3 VDC power requirements.

By combining our dual CAN port interface, the Arduino DUE microcontroller, an OBD2 or SAE J1939 cable, and open-source software libraries you are ready to go with powerful a turn-key Arduino-based dual CAN bus solution. 

Leverage the 32-bit processing capability of the Arduino DUE plus the built-in CAN ports for your next prototype.

In order to more efficiently serve automotive and industrial applications, the jCOM.CAN.DUE-X board supports an extended input power range of 7 to 36 VDC to power the entire system, i.e. including the Arduino Due itself.

More Information...