NHTSA calls for black boxes in all cars

Automotive Black Box Data Recovery Systems
By Don Gilman

Introduction
For years, airplane crash investigators have had the benefit of retrieving data from the flight-data recorder, or “black box.” This data has proven invaluable for helping to determine what happened in the seconds before a crash. Now, in order to improve vehicle safety, General Motors is using similar technology in about 40% of its Model Year 1999 vehicles.
Background- Evolving Toward the Current State of the Automotive Art
In the 1970s, electronic sensors gained wide use in production automobiles. This proliferation was largely driven by the industry’s move toward electronically controlled fuel injected engines. The computer, or Engine Control Module (ECM), used sensors to gather information about the current state of engine operation. Though it differed by manufacturer, sensors typically gathered information about Throttle Position, Engine RPM and Airflow. The ECM analyzed the information gathered from the sensors. Then, based on programming in the ECM, instructions were sent to actuators that could vary the length of time a fuel injector pulsed, or specify the amount of spark advance the engine received. These electronic systems were much more efficient than their mechanical predecessors and contributed to significant gains in fuel economy.
Efficiency notwithstanding, many mechanics found these new systems difficult to service. Enter onboard diagnostics. Onboard diagnostics increased the capabilities of the ECM and allowed it to check its well being as well as the condition of its associated sensors. Coupled with this diagnostic capability was a feature that allowed the ECM to store problems that it detected. This ability to store information aided the repair technician, and formed the foundation for the current data
recovery technology.
As vehicles became more sophisticated, new electronic systems found their way into the automobile. Each of these systems required new sensors. Acceleration sensors were required for airbag modules. Wheel Speed sensors were required for ABS and Traction Control. Vehicle Yaw Rate sensors were necessary for Stability Control. Along with the new processors and sensors came on board diagnostics, and sometimes a little more. Just as the ECM could store problems, each new module also stored faults that were discovered in that particular system. For example, not only could the Airbag module store a fault, it could (and some do) count the number of times the engine had been started since the fault was generated. This was yet one more step toward storing data andthe idea of data recovery and a “black box.”
Data Recovery Systems (Black Boxes)
In the early 1970s, the National Transportation Safety Board (NTSB) made the recommendation that vehicle manufacturers and the National Highway Traffic Safety Administration work together to gather information on vehicle crashes using on-board collision sensing and recording devices. As a result, General Motors airbag equipped production vehicles have recorded data for impacts that caused a deployment of the airbag since 1974. Many of these systems also recorded data during
impacts that were not severe enough to actually deploy the airbag (“near-deployment” events).
The capability to record pre-crash data originated with some 1999 GM vehicles. While the preceding introduction has been somewhat generic, the remainder of this article will focus specifically on the late model GM vehicles that are equipped with such systems. It is important to note that the extensive use of onboard sensors has made data recording possible. Conceptually,
retaining the data is just a matter of adding memory and the software necessary to sample and capture the existing sensor outputs.
The Details
Airbag equipped vehicles use a crash sensing algorithm to decide when to deploy the airbags. The deployment criteria is based on various calibration data stored in the Sensing and Diagnostic Module (SDM). These criteria reflect that particular vehicle model’s response to a wide variety of impact conditions. It is a predictive algorithm, typically making deployment decisions within 15-50 msec after impact. The SDM algorithm determines not only when to fire the airbag, but also helps to determine when to record the pre-crash data.
The amount of data retained for each crash event is limited by available memory. The combination of sampling rate and memory are insufficient for the SDM to record the actual crash deceleration data. However, the crash pulse can be reasonably well represented by the low-frequency velocity change data, (the information of interest to crash reconstructionists typically does not exceed 60 Hz). The SDM calculates the change in velocity by integrating the average of four 312-microsecond
acceleration samples and stores them at 10 msec increments in RAM. Figure 1 shows the delta velocity values for a fairly high severity crash. The data points represent each 10-msec point with a smooth curve drawn through them.

Late model GM vehicles also contain several other sensors which provide information such as driver seat belt status. If there is a deployment or near-deployment event, the last five seconds of data immediately prior to enabling the algorithm are stored in the module’s memory (EEPROM). All of this stored data is available to the accident reconstructionist by using the proper software, interface hardware, and a PC.

Figure 2 shows how the pre-impact sensor data might appear when downloaded to a PC. Once each second, the module reads the most recent sensor data and stores them in a buffer that is constantly being refreshed, keeping only the most recent five seconds of data. When the SDM algorithm “enables” shortly after impact, buffer refreshing is suspended. It is important to note that the enabling of the algorithm is not synchronized with the buffering of the vehicle data. Therefore, the
data recorded could be skewed in time from the crash by as much as one second.
The SDM is designed so that 150 msec after the deployment algorithm has enabled, all the data stored in memory is permanently written to the EEPROM. Once a deployment record is written, it cannot be erased, cleared, or altered by service or crash investigation personnel.
Near-deployment events are treated differently. The data contained in the record are largely the same, but the criteria used to determine whether an event is stored in EEPROM is based solely on the maximum delta V observed during the event. If the maximum delta V is greater than the previously stored delta V (from a previous event, perhaps), the new near-deployment event is stored along with its corresponding data. This near-deployment event is cleared from memory after 250
ignition cycles, or about 60 days on average.
Implications to the State of the Reconstruction Art
Any technology that allows vehicle safety researchers to collect objective, accurate data on crashes opens the door to a new
generation of understanding and modeling. The available data sources are immense since about 18,000 tow-away crashes occur
daily. An example of how this approach can be of benefit follows.
Currently, one of the primary metrics used to determine crash severity is the change in velocity, or delta V. Many current
computer algorithms rely on stiffness parameters derived from short duration 35 mph rigid barrier impact tests to estimate delta V. This method is often a poor model of real world crashes, typically lasting longer with less than idealized impacts involving yielding fixed and narrow objects, underrides, or multiple impacts. These onboard data recorders can provide accurate delta V measurements for most real world crashes, and can validate the results from the software routines for unyielding rigid body collisions.
The photo at left shows a field crash from the NHTSA crash files involving a 1998 Chevrolet Malibu and a parked truck. As can be seen in the photo, this collision involved a severe underride condition. This crash had a long crash pulse. The software the investigator used estimated the delta V to be 23 mph. The investigator noted that this estimate appeared to be significantly low. A subsequent reading of the Event Data Recovery System indicated a delta V of approximately 50 mph, which appeared much more reasonable to the investigator.
General Availability
General Motors has contracted with Vetronix Corporation of Santa Barbara, California, to develop software and interface cables to allow the event data to be downloaded to commonly used laptop computers (Figure at Right). Data useful to researchers and investigators, such as delta V, driver seat belt usage, and pre-impact data will be stored and displayed in a standard format (see Figures 1 and 2). This new tool will also allow the investigator to input other pertinent information, such as the investigator’s name, and export the data to a remote database. Interface cables and a portable power supply will be available for vehicles that cannot be powered up after a crash.
The Event Data Recovery System is expected to be available in the fall of 1999. Further information is available at the Vetronix web site, Vetronix.com
Don Gilman received a Bachelor’s degree in Engineering Physics from Westmont College in 1989. A second Bachelor’s degree in Nuclear Engineering from the University of California at Santa Barbara followed in 1991. Subsequently, he earned a Master’s degree in Engineering Management from West Coast University in 1997. Following an 8-year career in aerospace, Mr. Gilman joined Vetronix Corporation in Santa Barbara, California, in 1998. Currently, Mr. Gilman is the Vetronix Program Manager for all North American and European automobile manufacturer accounts, including General Motors, Ford and DaimlerChrysler. Vetronix designs and manufactures computerized diagnostic equipment for the automotive industry, and has worked closely with General Motors since Vetronix was founded in 1984. Mr. Gilman can be contacted at DGilman@Vetronix.com
Copyright ©
Download the pdf of this documentation at this link.