wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

Controller Area Network 31-13
TABLE 31.2
Estimated Rates of IMO per Hour in CAN, TTCAN, and FTT-CAN
CAN
FTT-CAN
Δt = 5.ms TTCAN
ρ = 0.5
Bit Error Rate IMD/h IMO/h IMO/h IMD/h IMO/h
2.6 × 10 −7 7.59 1.05 × 10 −9 7.59 3.79 3.79
3.1 × 10 −9 8.93 × 10 −2 1.24 × 10 −11 8.93 × 10 −2 4.46 × 10 −2 4.46 × 10 −2
3.0 × 10 −11 8.75 × 10 −4 1.22 × 10 −13 8.75 × 10 −4 4.37 × 10 −4 4.37 × 10 −4
Inconsistent message reception scenarios are much more frequent in the case of TTCAN than in
native CAN and their frequency depends on the BER of the CAN bus. The assumptions concerning the
BER made by Rufino et al., although realistic in other networks, seemed somewhat pessimistic considering
the specific case of CAN and specially the characteristics of the CAN physical layer. This led to the
design of an experimental setup to measure real values of CAN BER [20]. Experimental results from a
set of experiments showed that BER was 2.6 × 10 −7 in an aggressive environment (CAN network placed
near a high-frequency arc-welding machine), 3.1 × 10 −9 in a normal environment (CAN network at an
industrial production line), and 3.0 × 10 −11 at a benign environment (CAN network at the university
laboratory). Please refer to [17] for a detailed analysis and discussion of these issues.
Table 31.2 presents the probability of inconsistencies both for CAN (including CANopen and
DeviceNet), using the same assumptions as in [40].
Observing Table 31.2, one may conclude that in native CAN the occurrence of IMO has a lower probability
than previously assumed, at least in the environments considered in the experiments. In fact, it
is below the 10 −9 threshold usually accepted for safety-critical applications. However, the probability of
IMD (messages are eventually delivered but they could be out of order) is still high enough to be taken
into account.
Concerning both TTCAN and FTT-CAN, one cannot neglect IMO because they are rather frequent.
However, it should be stressed that this does not mean that native CAN is more dependable than
TTCAN or FTT-CAN since native CAN does not bound automatic retransmissions that may origin
deadline losses. That is, the probability of IMO is lower in native CAN, but the probability of a message
miss its deadline is higher.
31.4.1 Consequences of Faults at the Node Level
CAN protocol does not restrict the failure semantics of the nodes, so that they may fail in arbitrary ways.
Some of these failures are automatically handled by CAN’s native implementation of error detection
capabilities and automatic fail-silence enforcement, described previously, leading the erroneous node
to a state, the bus-off state, where it is unable to interfere with other nodes. However, in some specific
situations, these mechanisms do not fully contain the errors within the nodes.
Specifically, a CAN node only reaches the bus-off state (fail silence) after a relatively long period of
time (when the TEC reaches 255). Moreover, a CAN node running an erroneous application can also
compromise most of the legitimate traffic scheduled according to a higher layer protocol implemented
in software in a standard CAN controller, simply by accessing the network at arbitrary points in time
(babbling idiot failure mode). Notice that a faulty application running in a node with a CAN controller
may transmit high-priority messages at any time without causing any network errors, and consequently
the CAN controller will never reach the bus-off state. An uncontrolled application transmitting at arbitrary
points in time via a non-faulty CAN controller is a much severe situation than a faulty CAN controller
also transmitting at arbitrary points in time because, in the first case, a non-faulty CAN controller
has no means to detect an erroneous application transmitting legitimate traffic. In the second case, the CAN
controller would enter bus-off state after a while and the error would be eventually confined.
© 2011 by Taylor and Francis Group, LLC