4
CAN Newsletter 1/2015
D
uring the standardization processes of CAN FD, a CRC
issue was discovered in the ISO/CD 11898-1 version
from 2014-08-12. The ISO Task Force decided to solve this
issue by changing the FD frame format. This solution has al-
ready been included into ISO/CD 11898-1 version from 2014-
10-15.
Classical CAN has a known Cyclic Redundancy Check
(CRC) weakness. More specifically, in Classical CAN a pair
of bit errors in a frame generating/eliminating stuff conditions
may reduce the Hamming Distance (HD) to 2. This means
that a receiving node may accept a frame and give a posi-
tive acknowledge even if this frame has two bit flips. This
case was first reported in a paper by Bosch for the ISO task
force on CAN (1989) and first published in the SAE paper
900699 by Unruh et al. It is also explained in 1999, “Multi-Bit
Error Vulnerabilities in the Controller Area Network Proto-
col”, a thesis paper by Eushian Tran at the Carnegie Mellon
University.
In order to prevent CAN FD from inheriting the de-
scribed CRC weakness, the CRC calculation in CAN FD in-
cludes the dynamic stuff bits. However, this change made
the CRC calculation more vulnerable to the fault type “short-
ening or lengthening of the bit sequence” under specific con-
ditions. Cases can be constructed where the receiving node
accepts a frame that was falsified by just a single error. This
vulnerability in the ISO/CD11898-1 version from 2014-08-
12 was detected and solved. The version from 2014-10-15
contains the solution and therefore has a slightly modified
FD frame format, which is also robust against shortening or
lengthening of the bit sequence. To clearly outline which fault
types might occur, we take a look at a fault model. The two
considered fault types are fault type A and fault type B.
Fault type A: Bit flip
Fault type B: Shortening or lengthening of the
bit sequence
A receiving node synchronizes on a glitch. Due to this syn-
chronization, in a bit sequence the receiving node may sam-
ple one bit less or one bit more than was actually trans-
mitted by the transmitting node. From the receiving node’s
CAN FD and the CRC issue
During ISO standardization the original CAN FD protocol needed to be modified, in
order to maintain the high level of reliability of Classical CAN. This article illustrates
the root cause for this issue as discussed during ISO standardization, shows
examples, and describes the solution.
point of view this is a shortening (one bit less) or lengthen-
ing (one bit more) of the bit sequence. Fault type B can also
occur in connection with stuff bits. The shortening and/or
lengthening may happen several times per frame. Inside one
frame either shortening or lengthening is likely to happen.
Which one is more likely is determined by the relation be-
tween the transmitter’s and the receiver’s clock rates.
Figure 2 shows an example where the receiving node
resynchronizes into the wrong direction due to a falsified bus
signal. As a consequence the receiving node samples the bit
sequence “100000i” as “100001”.
Figure 3 shows an example where the receiving node
resynchronizes into the wrong direction due to a falsified bus
signal. As a consequence the receiving node samples the bit
sequence “100001” as “100000i”.
Root cause for the CRC issue
The receiving node compares the calculated and received
CRC bit sequence to decide if a frame can be accepted or
not, i.e. if it was received correctly or not. The CRC result is
reliable if the CRC-algorithm is applied exactly to the same
number of bits (frame length) on sender and receiver side. In
this case, the term Hamming Distance can be used. A Ham-
ming Distance of n expresses that frames with up to n-1 fal-
sified bits are detected by the CRC-algorithm as erroneous.
The CRC algorithm may or may not detect frames with n or
more falsified bits as erroneous.
If the receiving node applies the CRC-algorithm to a
different number of bits (less or more) than the transmitting
node, the result of the CRC-algorithm has to be regarded as
corrupted. This means that a corrupted frame could lead to a
positive CRC result too.
Figure 1: A receiving node samples a bit with the
inverse value
Figure 2: Example for a shortening of the bit sequence
Figure 3: Example for a lengthening of the bit sequence
CAN FD