Most testing is done in a clean or static environment. The electrical power is connected to a constant voltage power supply. This is not very representative of the automotive environment. Electrically the automobile is very noisy, has dynamic behavior, and can be difficult to model and emulate.
Microprocessors can make mistakes at a rate of 1 million mistakes per second. If we can't test the software 100%, we need methods that will give us some level of confidence that the product is of high quality and will satisfy the customer. The test methods detailed in this paper can help gauge the robustness of the software.
These extraordinary tests are not part of standard test methods. Standard test methods use traceability of the functional requirements to develop the test. Each function is tested once per test cycle. Most of these tests are “Happy Path”. [3] Occasionally, failure modes and the effects are included in the test plan.
Most of the tests defined in this document are either based on lessons learned or are trying to find ways to expose non-robust software designs. These tests may also exacerbate software and hardware signal race conditions.
The background of the author is in the realm of body module controller behavior; therefore examples detailed in this document are related to body module controllers. There is no reason the methods can't be applied to other ECUs (Electronic Control Unit) on the vehicle.
This paper discusses the evolution and development of a method and process to stress automotive embedded software. The intended process will look for abnormal or undesired operation in the ECU.