
My Maker Space - Nathan Edwards
When commercial-off-the-shelf does not offer everything you need: BUILD YOUR OWN.
In order extend existing research and develop a supplemental architecture that adds to the fault tolerance of an automotive Controller Area Network (CAN) sensor node to handle faults like the “babbling idiot” or transceiver electrical faults, it is important to first understand the existing fault tolerance of a CAN 2.0 specification system. This is performed using fault injection on prototype systems utilizing actual interactions between hardware and software offer a more realistic characterization and are necessary to validate the implementation. The core of our project then focuses on injecting faults at one node and studying the propagation to the rest of the system which has hard real-time constraints.
At the time of this project there were not any commercially available tools to allow for mixed mode fault injection (physical and software) – so we had to custom design hardware, firmware and software for the faults to be injected. We wanted to include skewing the electrical characteristics of the bus load resistance or capacitance, and address the issue of faulty nodes ignoring the arbitration mechanisms and transmitting a bit or several bits. The system also includes electrical short-based faults, flipped-bits and more. There are also LED indicators for which type of fault has been activated. Although the project and results are not complete (and has been through several revisions of hardware), we successfully collected several observations from our initial experimentation.
The Fault injection testbench hardware is controlled with an ATmega 2561 microcontroller, NXP SJA1000 CAN controller via an Intel mode external memory interface, and two CAN transceivers for connection directly to the CAN bus as well as a future FPGA implementation of a bus sniffer and fault protection architecture and additional fault injection capability. Communication with a host computer is done through either a RS-232 or USB connection.
To interface with the proprietary protocol developed for use with the test bench board, a PERL script was written to send a desired randomly generated fault sequence at a given interval. Using the fault-activated acknowledgement message returned by the board, the script is able to log the time and type of fault activated. Using this data in conjunction with the receiving node’s log, the time between activation and detection of the fault can be found.
Below are more detailed papers on this initial design (by N. Edwards) and initial attempt to capture experimentation data. The design was modified/corrected in later years by a colleague and friend who continued in this research area at UIUC.
Understanding Fault Tolerance on CAN Automotive Systems
Proposal for Extending Fault Tolerance on CAN Bus Automotive Systems
Software Faults:
-
WRONG_STREAM
-
WRONG_DATA_LENGTH
-
NON_VALID_DATA_FIELD
-
WRONG_SPORADIC_BEHAVIOR
-
BABBLING_IDIOT
Hardware Faults:
-
LOW_POWER (MCU, CTRL, TXCVR)
-
SHORT_TO_VCC (TX, RX, CANH, CANL)
-
SHORT_TO_GND (TX, RX, CANH, CANL)
-
TX_SHORT_RX
-
SHORT_CAN_H_TO_L
-
CAN_LOAD
-
CAN_CAP
-
CAN_TXSILENT
-
FLIP_CAN_TX
-
FLIP_CAN_RX
-
NOISE