Beware the black box

The automotive black box data recorder is not infallible and its data is subject to interpretation.

2013 July

Starting in the late 1990s; certain airbag-equipped vehicles were equipped with event data recorders (EDRs). Dubbed “Black Boxes,” after the devices used on airplanes to record in-flight data for post crash analysis, these data recorders were included to help vehicle manufacturers track the performance of their airbag systems in the field.

Now recognized by law enforcement agencies, experts and even courts as reliable sources of data relative to vehicle speed, brake application, seat-belt use, throttle position, etc., the use of this data should nonetheless be approached with caution as its reliability is far from guaranteed.

The purpose of this article is to acquaint the practitioner with the limitations of this data.

What is a “black box”?

In general, the airbag in a car deploys in response to vehicle decelerations which fit a certain pre-set profile. These profiles are developed using data gathered from crash tests. However, understanding that crash tests cannot replicate every real world event, several vehicle manufacturers determined to track the performance of their systems in the field by monitoring selected vehicle parameters of data during crash events. To help them monitor the performance of their airbag systems in the field, a number of manufacturers installed Event Data Recorders, “Black Boxes,” in some of their vehicles. However, these “Black Boxes” were not originally intended to record data, and the idea of actually capturing and preserving the data was an afterthought. More importantly, the data was never intended to be used to reconstruct accidents. In fact when questioned during trial about that very issue, one of GM’s airbag design engineers testified that GM’s in-house attorneys asked that the Event Data Recorders not be installed because of concerns about the use of the data in litigation.

How they work

In general, the system that fires a car’s airbags includes three components, a Sensing and Diagnostic Module (SDM) an Event Data Recorder (EDR) and an Electronic Control Unit (ECU). The Event Data Recorder (EDR) records pre-crash and crash event parameters. Depending upon the vehicle manufacturer, an EDR can be designed to capture a variety of vehicle parameters including pre-crash vehicle speed, seat-belt status, brake application, throttle position, fault codes, airbag deployment timing, crash duration and velocity change. This data, in the form of electrical signals, is transmitted to discrete addresses in EDR from a number of different sources where it is converted into hexadecimal code. Figure 1

In order to interpret the data, one must be able to translate this code. Cur-rently, there is only one commercially available translation tool. Manufactured by Bosch, this tool is widely used by law enforcement and accident reconstruction engineers. However, the tool has serious limitations which should be considered before translated data is relied upon or admitted into evidence. Here it is important to recognize that simply because an expert is trained in the use of the translation tool does not establish the reliability of the data being downloaded and translated.

Common misconceptions about “black box data”

Courts, in admitting “black box” data, and counsel in relying on it, do so based on three common misconceptions.

• The first misconception: All EDRs are identical

The first misconception is that all EDRs are identical. They are not. EDRs differ from manufacturer to manufacturer. EDRs also differ in terms of the type and amount of data recorded, the timing of data collection, the reliability of data, the amount of space to store data, and whether stored data can be corrupted, erased, or overwritten.

• The second misconception:
The downloading process is impartial

The second misconception is that the process of downloading information from the EDR is impartial and that the data cannot be corrupted as part of the downloading process. Such is not the case. For this reason the parties should agree on a protocol before allowing any download to occur. Counsel should also make a record of the fact that by agreeing to a protocol they are not stipulating to the reliability or admissibility of the data downloaded.

A download is accomplished by connecting a laptop computer with translation software to a data port. EDR data can be accessed from several different ports. Data can be accessed by connecting directly to the SDM/EDR or by connection to a data port in the center console or under the driver’s seat, depending upon the vehicle. The port selected can impact what data is retrieved. The type of connector used to link the computer to the data port can also affect what information is received. Figure 2 shows data being downloaded using the data port under the vehicle’s seat using an external power source.

Next, conducting a download requires electrical power. Generally there are two ways to “power-up” the system. The first is through the vehicle electrical system, and the second is by applying power from an outside source to the SDM/EDR. Using an outside power source can sometimes create artifacts in the download which are completely unreliable. Figure 3 is an example of a printout from a download using an external power source. At the time the download was conducted, the driver’s seat belt was not buckled and yet the system reported the belt as latched.

• The third misconception

When an EDR is downloaded using the Bosch translation tool, it generates a written report called a Crash Data Report (CDR). This report can include pre-crash speed, throttle position, brake pedal position, seat-belt status and the speed change experienced by the car during the collision or Delta V. The third misconception is that the CDR contains impartial and infallible pre-crash and crash information. It does not. Figures 4 and 5 are examples of CDR reports generated from data downloaded from EDR data that is clearly incorrect. In Figure 4, the system reported a velocity change in this frontal crash of .23 mph. In Figure 5, the reported velocity change was 1.9 mph notwithstanding the massive front-end damage.

As a threshold matter, it is important to understand that no commercially available translation tool can establish the accuracy of the data being reported or downloaded. This is because the commercially available tools cannot download or translate all of the data on the EDR. Only the data specified for retrieval by the manufacturer is shown in the download report. Figure 6 is a printout of the hexadecimal data downloaded during a typical data retrieval using commercially available software. Only the highlighted portions (5 lines of data) were translated by commercial software to create the CDR.

Hidden within this untranslated code is information about the status of the system at the time of the crash, including what components of the system were reporting and which components may have failed and were not reporting. When a system has failed or is failing, it will send a fault code to the EDR. However, most fault codes are not read or translated by the commercial translation tool.

A second concern relative to the accuracy of the information in Crash Data Reports, is the source of the data. By way of example, vehicle speed is derived from one of two sources, wheel speed sensors, or the transmission. In the case of wheel speed sensors, the accuracy of the speed reported is dependent on the diameter of the tires. The wheel speed system is calibrated using the diameter of the tires sold when the vehicle is new. If during the life of the vehicle the tires are replaced with a different size tire, and the system is not recalibrated, then vehicle speed data cannot be relied upon. Similarly, if work has been done to the transmission and the speed sensor is not recalibrated and/or not reconnected properly, then speed data from the transmission sensor is not reliable.

There can also be reliability issues related to how the data is sent to the EDR. In some vehicles data is transmitted directly from the source to the EDR. In others it is transmitted first to a Body Control Module and then relayed to the EDR. In those systems where the data is relayed, unless the integrity of the relay can be verified, the data is questionable.

A third concern relative to the accuracy of the data involves whether the data saved in the EDR is from the accident being investigated or some other event. The issue here involves how the data is stored and under what conditions it can be erased. In general, data is received by the EDR whenever the vehicle is on. When certain conditions are met, the EDR will start to record data and depending upon what occurs, store that data in either erasable or non-erasable memory. If the data is in erasable memory, then it will simply be overwritten by the next event or erased the next time the car’s ignition is turned on. Depending upon the
circumstances of an accident, data recorded during a collision may not have been locked such that when the EDR is downloaded what one is seeing is data from some other event.

In general, anytime a vehicle senses a sudden deceleration such as when a driver jams on the brakes to avoid a collision, the airbag system will wake up and the EDR will start to record data. It will save that data once the event is over and the system has completed writing. If, however, the vehicle is involved in a second event which results in a crash during which the vehicle loses electrical power before the system has had a chance to save the data, then what you might see when you perform a download is data from the previous event. Because the data is not date or time stamped, you will not necessarily be aware of the fact that the data you are looking at is not related to the accident at issue.

Downloads are commonly offered to show that a plaintiff was not wearing a seat belt. However, there are serious issues with the reliability of seat-belt use data. Again each manufacturer has a different system for reporting seat-belt status. Some manufacturers use a switch, and some measure voltage. Some systems monitor seat-belt status periodically; some monitor it only at the time the ignition switch is turned on. Some systems stop monitoring seat-belt status at the start of a collision event, and some do not monitor seat-belt status unless the airbag system is awakened. It is important to identify those systems that only monitor belt status when the airbag system is awakened because some airbag systems do not respond to rollover, side impact or rear impact collisions, such that what is reported is a default setting and not actual seat-belt status.

To help understand this issue, consider the following; in those systems designed to sample seat-belt status only at the time the ignition is turned on, a person who starts her car and then puts on her seat belt, will be reported as unbelted. In some systems the default position at vehicle power-on is buckled. Thus, when the ignition is turned on, the driver is reported as belted whether that is accurate or not. In still other systems the seat-belt circuit is not diagnosed which means there is no way to tell whether the seat-belt status is being accurately reported or not. In those systems that use voltage to determine if a seat belt is buckled and the wires leading to the seat-belt switch are damaged, seat-belt status will not be accurately reported. And finally, in some cars if electrical power is interrupted during a crash, as for example when the battery is damaged, then the report of seat-belt status will be in error.

The final concern relative to the accuracy of download data is the limitations on the data articulated by the manufacturers themselves. Consider the following disclaimers issued by various vehicle manufacturers:

In unusual circumstances deceleration data stored in the module may be from a crash other that the one you are currently analyzing.

Or

The module will record data from some non-deployment events. If, after the module has recorded data from a non-deployment event, and there is a subsequent event in which there is a loss of power, and no new recording is made for that subsequent event, the deceleration data in the module memory may be from the prior event.

And

The ECU memory was designed for the purpose of internal research and development. Any information which may be contained in the ECU’s memory… was not designed to be used as
an accident reconstruction tool. Additionally, memory of diagnostic codes was not designed as a means for determining the status or condition of the airbag system prior to an accident in which the airbags deployed. Data obtained during the readout of the ECU [EDR] could be misleading if used for those purposes.

Finally

The data is used to assess the performance of the vehicle and is not meant nor is it suitable for the reconstruction of an accident.

The limitations of the
translation tool

Bosch/Vetronix in cooperation with most vehicle manufacturers has developed a tool that is capable of downloading data from EDRs and translating the hexadecimal code into words, graphs and numbers. However, the tool translates only a small amount of the data. It does not, for example, translate system diagnostics, or fault codes and so cannot determine whether the system was working properly when the data was received. For example, the Bosch tool cannot tell if the wheel sensors were calibrated, whether the seat-belt switch wires were damaged, or whether the power was interrupted. It cannot verify that the data downloaded was from the accident at issue. And, most importantly, it cannot determine whether what is in the data represents what occurred in the accident at issue. Like the Rosetta Stone, it is simply a translation tool. And while the Rosetta Stone allowed scholars to translate ancient texts, it did not tell them whether what they were translating was fact or fiction.

The only way to obtain a complete translation of data downloaded from the EDR, is to obtain a printout of all of the stored hexadecimal data and then manually, using code books written by the designers of the system, translate each line of data. Unfortunately, the code books are considered proprietary and are not available unless the manufacturer is a party to the lawsuit. However, even with the code, an expert in airbag design and performance will be needed to complete the translation.

The take-away

In sum, “Black Box” data is not what it seems, and should be approached with caution. To avoid issues with the data at trial consider the following:

• Do not assume the download is accurate.

• Agree on a protocol before allowing any download.

• Understand the limitations of the data.

• Make a record of the limitations before agreeing to go forward with the download.

• Do not stipulate to its admissibility unless you are confident that the data is reliable.

• Be sure your reconstruction expert compares the data to the physical evidence.

• Consider making a motion to exclude the data if the party offering the download cannot establish, based upon physical evidence, that the data is accurate and represents the conditions at the time of the accident.