Complete Bosch CDR Report

News Flash! In 2015, the Federal government passed what is called by the short name of the FAST Act. Part I, Section 24302, specifies ownership of the data in an airbag control module and the circumstances under which it can be accessed. In short, access to that data can only be obtained by court order or with the written, electronic, or recorded audio consent of the owner or lessee of the motor vehicle.

This page contains a link to a complete Bosch Crash Data Retrieval report from a data image taken from a GMC Yukon. The last letters of the VIN have been deleted to protect the guilty.:-) The link, provided at the bottom of this page, is available in Adobe Portable Document Format to enable universal viewing.

As with all such reports, it opens with a Data Limitations section. This section is specific to the class of module or other component being imaged. The Data Limitations section of this particular report is a page and a half.

The next two pages deal with a deployment record. For this particular vehicle, a deployment event means one or both bags out. For vehicles with seat belt pretensioners and/or other components besides front airbags, a deployment does not necessarily mean that bags will be out--for many newer vehicles, a crash of moderate severity might call for pretensioners to fire but not the airbags. That event is a deployment, even though the bags didn't blow.

"AE" means "algorithm enable." The module in this vehicle continuously monitors its internal accelerometer. When a sudden change in speed occurs, an algorithm (a serious of logical processes, steps, or decisions) begins to evaluate if a deployment is warranted. What typically calls for a deployment is consecutive brief time intervals in which the rate of deceleration continues to increase sharply. (The time rate of change of acceleration is called jerk. It's a real term in physics. Also may apply to some people you know, but with a different connotation.) If the "awakened" algorithm decides to fire the airbags (or pretensioners, if equipped, or both), it becomes a deployment event. Virtually all late-model vehicles from Chrysler, Ford, and GM will try to record a deployment event. The primary purpose of the airbag control module is to fire the airbags/pretensioners; if there is a power interruption during the crash, which is not at all unlikely, the capacitors in the module may not have enough current in them to move the data to permanent storage after the safety equipment gets fired, so there may be no recording or an incomplete recording. In many cases, however, a deployment event will be fully and properly recorded and stored in the module's non-volatile memory. Use of the Bosch CDR Toolkit allows the user to create an image of that data outside the module, then translates the binary code into a written report specific to the module.

If the algorithm "wakes up" but decides not to fire the available device(s), many modules will store the data related to that event as a non-deployment file. A non-deployment file will contain some of the same basic information as a deployment file. A non-deployment file may be erased after a certain number of ignition cycles, and it may be overwritten by a deployment or deployment-level event. A deployment-level event is one in which the deceleration is great enough that airbags would have been fired but for the timing. An example would be a vehicle which is involved in a collision resulting in airbag deployment but is still moving at a significant speed after that first impact. It then moves into another collision in which an airbag would have fired, but the bags were already out. As Rusty Haight, one of the instructors for use of the Bosch CDR Toolkit, likes to say, a deployment-level event means "It sucks to be you." :-)

With very few exceptions, a deployment event will be locked in non-volatile memory if enough power was available to record the data and lock it. Some modules can store more than one event. Many can store one deployment event and one deployment-level event or a non-deployment event. There are a few which can store up to three events, including one deployment, one deployment-level, and one non-deployment or one deployment and two non-deployments. The important aspect to remember is that the deployment event and associated data will (almost always) be locked; that data set cannot be overwritten or modified during interrogation with the Bosch CDR system. Non-deployment events can, in general, be overwritten, but non-deployment events associated with a deployment event may be locked, also, in some modules.

The report available with this Web page contains both a deployment event and a non-deployment event. Often, both can occur in one collision sequence. In this case, however, they are unrelated. The ignition cycle count for the deployment event in this report is 29,253. The ignition cycle count for the non-deployment event is 29,170. A difference of 83 ignition cycles indicates that a significant period of use elapsed between the events. If you use you car to drive to work in the morning and drive home at night, five days a week, and go to church and back on Sunday, you will go through 12 ignitions cycles in a week. Most people use their vehicles more frequently than that.

Looking at the deployment event, we see that three data elements are recorded at five one-second intervals before AE, and the brake switch status (on or off) is recorded for eight one-second increments before AE. Several points need to be made. The first is that the element closest to AE (-1) is not necessarily one second before AE; it is the last data set which was recorded before AE. It may actually have preceded AE by less than half a second. The data which ultimately gets stored is kept in a circular buffer and moved to non-volatile memory after a crash; there is no documentation regarding exactly where in time after the set marked "-1" the AE actually occurred. So all we know for sure is that -1 precedes AE by a second or less.

The next point to be made is that these parameters are not all recorded at the same instant. Each parameter may have been recorded by as much as 200 milliseconds before or after the specified time increment. Also, there is no continuous monitoring. For example, looking at the Brake Switch circuit status for the deployment event, each time increment from -8 through -3 shows OFF, but the switch may have actually been ON briefly between any one of those instants in time when the brake switch reported that it was off, each separated by approximately one second. Each data element is reported at that instant for each time increment. And data elements for a given time increment are not all reported at the same instant.

The last page is the hexadecimal data sheet. This page lists all data stored in the module, expressed in hexadecimal format. (Hexadecimal format lends itself well to being a shorthand for binary--zeros and ones--code. Each binary element is a bit. Eight bits form a byte. Two bytes--16 bits--form a word. Hexadecimal numbers are base-16, where 0 through 9 represent their face values, A represents 10, B represents 11, C represents 12, D represents 13, E represents 14, and F represents 15. In hexadecimal code, "10" is the numerical equivalent of 16 in our base-10 world. "FF" represents 255, the highest number which can be represented by two-element hexadecimal codes. "100" in base-16 is 256 in our base-10 world.) Not all data stored in the module is translated by the Bosch CDR system, nor is it intended to be. The last page is included in the spirit of completeness, not to provide additional mystery or intrigue.

So, now you have a thumbnail explanation of a specific CDR report. Each family of modules produces a different format of report, and the data set in each module within a given class will be unique for each vehicle involved in an event severe enough to awaken the algorithm and/or fire the airbags. The link below will allow you to view (and print, if you like) the complete report. It is intended to be printed in color on standard letter-size paper, but it should print in all black if you don't have a color printer.

Yukon Denali CDR Report

Ralph Cunningham, Inc.

770.918.0973 Fax: 770.918.8076

If you want to return to the home page, you may use this link.