Because it is one of the most important safety features in modern-day cars, an air bag must perform reliably under very severe operating conditions. In command of this lifesaver is the air-bag control module. It is in charge of a number of functions, including interfacing with the display console, other control modules, crash sensors, and the air-bag assembly.
Since air-bag control modules must be subjected to a number of tests, automating the process is the most repeatable and effective approach. This is why a manufacturer of air-bag control modules chose AVALON, a stand-alone PC-based test system from Dateppli that automates the testing and validation of hardware and software for dedicated control modules.
The test-system software allowed technicians to program test sequences using a simple script language. The test system features 64 high-speed analog inputs for testing as well as two analog outputs and 88 relay outputs for simulating the large number of conditions the air-bag control module might experience in the field. Critical components of the testing included emulation of other control modules, time-to-fire testing, and complete recursion of all tests performed on the air-bag control module.
Automated Testing Provides True Regression Capabilities
The testing processes for electronic modules that control critical safety functions of an automobile are, by necessity, rigorous. Any software changes to the air-bag control module’s firmware require a complete test sequence that involves simulating a large number of conditions the module may experience in the car.
With 35 pins connecting the air-bag control module to power, indicators, sensors, and other control modules, several permutations to the test sequences existed. Running each permutation manually with stand-alone instruments was a time-consuming process.
Most of the test components were simple sequences. For example, one test sequence may involve applying a voltage to a particular pin and a given resistance to another, then querying the air-bag control module for a status bit (Figure 2).
However, running more than 50 simple tests for every software revision became a quality-control concern. Many of the test components were reusable for several tests. With the new software, the technicians were able to program these test components for automatic testing.
The technicians wrote each test component in script language. Because they could save the individual scripts independently and connect them into a sequence for each test plan, they gained exact duplication of the tests, reuse of components, and automated testing. The capability to duplicate previous tests provided true regression testing to ensure that the latest change to the air-bag control module’s firmware did not cause unexpected results.
No Control Module Stands Alone
In the past, windows, door locks, engine control, and other automotive functions used electrical and mechanical control systems. In networked automobiles, individual control modules perform local control and communicate to each other over a serial network such as the J1850. These networks minimize wiring and increase the flexibility of the control systems.
Control modules may interact when their functionality overlaps. For example, engine control modules and air-bag control modules communicate information to the instrument cluster, which displays information to the driver. The Check Engine and Air Bag indicator lights are examples of displays driven in this manner.
As more control modules are added to automobiles, the dependency between control modules and the complexity of simulating an in-vehicle network increases. To accurately simulate the environment in which the air-bag control module would operate, the test system communicates to the unit under test (UUT) using an RS-232-to-J1850 converter.
In the test software, the other control modules on the network are simulated in a separate execution loop using the flow chart-styled test sequencer. This parallel sequence uses test scripts to simulate the other control modules on the network by monitoring the J1850 bus for specific messages and periodically sending status messages.
The separate sequence is required to provide a reliable execution time. In the control software, each parallel test sequence loop runs in a separate operating system thread. This ensures that the loops will maintain a reliable execution time.
Two types of control-module simulations exist. The first type is responsive simulation. A script monitors the J1850 network for particular messages directed toward the simulated control module. For example, the air-bag control module might query the instrumentation control module for its error status. Specifically, the control module is interested in the status of the air-bag indicator light on the dashboard.
When the script simulating a control module receives a message, it sends a standard response to the air-bag control module indicating a good or bad indicator light depending on the test. This simulation of active control modules must respond to the air-bag control module within a time limit, in the millisecond range, for successful simulation.
The second type of simulation is unsolicited. Periodically, the script that is simulating a control module sends a status message over the network in a broadcast. This type of script can emulate a heartbeat of critical control modules. The air-bag control module must perceive that it is in a functioning automobile to properly test it.
Other test sequences program errors into these simulations to verify the performance of the UUT. For example, the module that controls the driver’s display panel (check-engine indicator, air-bag indicator, and oil pressure warning) could have a burned-out bulb for the air-bag indicator. To test how the control module would handle this error, the cluster control module simulation script sends an error code through the J1850 network.
Network emulation is a critical function that makes possible all other testing. Without a proper emulation of a functioning network, the air-bag control module will not perform as it would in an automobile.
Time-to-Fire Testing Is the Most Critical
Perhaps the most critical test sequence for the air-bag control module is the time-to-fire test. This test requires a crash sensor to send a signal to the air-bag control module. The time between the crash sensor’s signal being sent and the control module’s sending the signal to inflate the air bag is critical to the safety of the driver and passenger (Figure 3).
If time-to-fire is too fast, the air bag will be too deflated to help. If it is too slow, the air bag can harm the driver or passenger by inflating when the passenger is too close to the steering wheel. To ensure an air-bag inflation time of 30 to 35 ms, the control module must receive the signal from the crash sensor in 10 to 15 ms.
Normally when an automobile is started, the air-bag control module sends a low voltage across the firing element in the air-bag assembly to test the continuity of the firing element and the air-bag indicator. When a vehicle crash is detected, the current through the firing element is increased to a point where the propellant is ignited, inflating the air bag.
For test purposes, the firing element is simulated using a high-current, low-impedence resistor. Measuring the voltage drop across the load resistor monitors this event. A low current is expected during the continuity test, but any significant current would indicate an air bag firing.
The accelerometer sensors, which are used to detect a crash, can have many different signal characteristics based on the angle of the crash, speed of the vehicle, and even aftermarket additions to the exterior. To simulate the different real-world possibilities, the accelerometer sensor signals are profiled in the software, physically generated by a waveform creation function, and sent over a high-speed analog output to the UUT. A typical simulated accelerometer output may contain 100,000 points and play out at the rate of 10 to 100 kHz.
Due to accelerometer sensor signal variations, various complicated algorithms are used to determine when the air bag should inflate. Each individual algorithm must be subjected to a full set of tests to determine if the algorithm correctly sensed a crash. This provides a means for engineers to test the algorithms against a wide range of simulated inputs and minimizes the need for vehicle crash tests.
Conclusion
Due to the easy-to-use script language, test technicians were able to configure simple scripts that were combined to create the air-bag control module verification procedures. Reusing the scripts for each test plan increased test integrity. The automation decreased the time required to test the air-bag control module.
Simulating other control modules allowed proper emulation of the working environment of the UUT. Errors in the other control modules were simulated to increase the type of tests that could be performed. Some critical tests, like time-to-fire testing, involved high-speed waveform generation and high-speed analog input monitoring.
With AVALON, the manufacturer decreased testing time, reduced the time-to-market, and improved the quality of the verification of the air-bag control module.
About the Author
Chris Megdanoff is the engineering manager at Dateppli’s Southfield branch. He is a graduate of the University of Michigan and a member of Eta Kappa Nu, the electrical engineering honor society. Dateppli, 21314 Melrose Ave., Southfield, MI 48075, (248) 353-5212.
Copyright 1999 Nelson Publishing Inc.
July 1999