Applying good engineering practices to software-intense automotive systems can save automakers millions of dollars in warrantee costs, lost customer loyalty and lawsuits. Carefully crafted development testing could expose non-robust software that fails intermittently when the customer activates the function.
The chances are very good the service technician will replace the ECU when the customer brings the vehicle in for repair of the intermittent behavior. These electronic parts are sent to the supplier for analysis. Upwards of 60% of all ECUs analyzed are TNI (Trouble Not Identified) related.
This paper elaborates on a method of developmental testing that provides these cost savings. This paper continues to build on concepts discussed in the SAE paper, “The Bus Crusher and The Armageddon Device Part I”.  The experiment of subjecting an ECU to several electrical disturbances is explained in detail.
The objective of an embedded system is to have a predictable output for any combination of input sequences. If the operation of the embedded system is viewed as a big state diagram, testing verifies that the embedded system operates in acceptable states and that transitions between states are all known and predictable. The stress-testing concept described in this paper generates sequences of stimuli that can’t normally be planned for (the number of combinations is massive). The embedded system must always remain in a known acceptable state, regardless of the stimulus. The testing techniques described allows for the creation of a stimulus to verify the robustness of the embedded system.
Experiments were conducted on electrical breadboards, which were subjected to RF (Radio Frequency) noise, periodic network initialization, communication bus failures, intermittent ground open, and repeated cycling of the locking function. The hypothesis of the experiment was to stress the ECU’s operating environment by causing events that seldom occur, and make them happen with high regularity.
The electrical noise level is below the ECU design limit, e.g., the task monitoring the ECU voltage range will ignore voltage drops of less than 15 msec (milliseconds). Subjecting the ground circuit to an interruption of less than 15 msec should result in no humanly perceivable behavior change.
Methods to stress the software are the focus of this document. Described are:
Building the RF Blaster
Building the Armageddon Breakout box
Introducing new noise factors; ground lift and periodic network initialization