Use of Event Data Recorder (EDR) Technology for Highway Crash Data Analysis (2005)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

97 4. EDR Retrieval and Archival Methods: Current Methods, Limitations, and Issues 4.1 Introduction This objective of this section is to discuss current methods for retrieval and storage of EDR crash data for highway crash safety analysis. The discussion will also identify key issues and problems associated with these methods. Finally, this chapter provides recommendations for improved retrieval and archival methods. 4.2 EDR Data Retrieval Methods and Issues Currently, there is no standardized method to download data from EDRs. As a step towards resolving this issue, some manufacturers have teamed with Vetronix Corporation, a third party vendor, to produce a publicly available EDR reader. The automakers that have not made arrangements with Vetronix retrieve data from their EDRs or airbag control modules through proprietary devices of their own design. Another optional, but less frequent, practice used by some automakers is to physically remove the EDR or airbag control module from the car, and send the unit back to the supplier for data retrieval. 4.2.1 Vetronix Crash Data Retrieval System As shown in Figure 4-1, the Vetronix CDR system allows a user to directly connect to and read an EDR from a laptop computer. The laptop computer connects to a CDR interface box which connects to the EDR through a cable. The CDR system provides two methods for connecting to the EDR: (a) through the Onboard Diagnostic connector, and (b) through direct cable connection with the EDR itself. In 1999, GM awarded the Vetronix Corporation with an exclusive contract to develop the Crash Data Retrieval (CDR) system. The CDR System became available to the public in March 2000 [Kerr, 2002]. In spring 2003, Vetronix, under a similar agreement with Ford, released version 2.0 of their software which could decode EDRs from some Ford models. We are also aware that additional automakers are currently in negotiation with Vetronix to allow the decoding of their EDRs. The Vetronix CDR system is available for public purchase for $2500 per unit.

98 Figure 4-1. Rowan University Research Assistant downloads an EDR removed from a Saturn passenger car using the Vetronix Crash Data Retrieval System The preferred method is to connect to the Onboard Diagnostic connector (OBD-II) located in the occupant compartment under the instrument panel. The OBD-II connector shown in Figure 4-2 has been EPA-mandated equipment on all U.S. passenger cars and light trucks manufactured since model year 1996. Although the primary purpose of the OBD-II connector is to allow access to engine and emissions diagnostics data, the OBD- II connector is also increasingly used as an access point to the other on-vehicle computers including the EDR or airbag control module. Specifications for the OBD-II connector are standardized under SAE J1962. Figure 4-2. OBD-II Connectors are located under the Driver Instrument Panel If the OBD-II connector cannot be used due to crash damage, the Vetronix system allows the user to directly connect to the EDR for downloading as shown in Figure 4-3.

99 Vetronix provides a selection of cables to allow direct connection with different types of EDRs. Figure 4-3. GM EDR shown connected to Vetronix CDR download cable [Kerr 2002, used with permission of the Vetronix Corporation] This downloading method has two disadvantages over the OBD-II method. First, the EDR is frequently located in a difficult to access location. GM EDRs are typically installed under one of the front seats as shown in Figure 4-4 or embedded behind the center console. Accident investigators have told us that in many cases, the car must be partially dismantled to gain access to the EDR. This process is time consuming and may be unacceptable to the owner who seeks to prevent further damage to their car. Second, this method is only successful if the field investigator has a cable which matches the particular EDR of interest. Because there is no standard for the EDR connector, the field investigator must carry a large number of cables having different connectors. The current Vetronix system comes with a dozen different cables corresponding to different EDR designs. Accident investigators have told us that they have attempted to directly download the EDR in some cars only to find that they did not have a matching cable to allow the download to proceed. After successfully establishing a connection using either download method, the Vetronix system retrieves and saves the EDR information in hexadecimal format as a Vetronix CDR file. The CDR file can be opened at any later date by the Vetronix CDR software to view the downloaded EDR information.

100 Figure 4-4. EDRs are frequently located in difficult to access locations [Kerr 2002, used with permission of the Vetronix Corporation] Standards Groups Activities in Retrieval Methods The SAE J1698 Standards Working Group on Vehicle Event Data Interfaces is actively developing proposals for standardized retrieval methods. The SAE J1698 group appears to be leaning toward leveraging the OBD-II connector standard as a standardized access point [Kreeb, 2003]. 4.2.2 NHTSA Experience with EDR Data Retrieval In the field, NHTSA has found that it is not always possible to download data from the EDR [Gabler et al, 2003; Hinch et al, 2004]. As shown in Figure 4-5, NASS investigators could not recover data in approximately one-third of all attempts to download an EDR-equipped vehicle. While this rate was consistent in both NASS 2002 and 2003, the reasons for unsuccessful downloads in 2002 were quite different from those reasons noted in 2003.

101 62% 38% 65% 35% 0% 10% 20% 30% 40% 50% 60% 70% EDR Successfully Downloaded EDR Information Not Obtained NASS 2002 NASS 2003 Figure 4-5. NHTSA Success Rate in Downloading Event Data Recorders in NASS/CDS 2002-2003 crash investigations (adapted from Hinch et al, 2004) The reasons for the inability to obtain the EDR data were culled from case comments entered by NASS/CDS researchers, and grouped into the categories shown in Figure 4-6. 23% 5% 62% 10% 18% 9% 25% 48% 0% 10% 20% 30% 40% 50% 60% 70% Vehicle damage prevented downloading EDR data Data Collection Failed / No Recording Permission refused to access/read EDR Technical/Training Issues NASS 2002 NASS 2003 Figure 4-6. Reasons for Unsuccessful Downloads in NASS/CDS 2002-2003 (Adapted from Hinch et al, 2004) The categories are discussed below: 1. Technical/Training Issues. Technical / training problems were the leading cause of unsuccessful downloads in 2002 (48%), but after an aggressive training program in late 2002, training problems resulted in only 10% of the unsuccessful downloads in

102 2003. This category included circumstances where the crash data was not available due to technical issues such as, inability to access the data-recording device without causing undue damage to the vehicle, partial inspections of vehicles, time constraints as well as a lack of problem solving and technical assistance at the time of the vehicle inspection. 2. No Permission. NHTSA requires owner permission prior to interrogating the vehicle EDR. In 2003, failure to obtain the owner’s permission accounted for nearly two- thirds of the unsuccessful EDR downloads – a dramatic upsurge from 2002 in which this reason accounted for only 25% of unsuccessful downloads. This category included situations when permission was not given to perform any vehicle inspection as well as situations in which permission was given to perform a full vehicle inspection less the EDR interrogation. 3. Data Collection Failed / No Recording. Data collection failed in only 5-9% of the EDRs investigated for this study. This category included situations where the recording device did not record any or all of the expected data or the criteria to record data were not met in the crash. Compromise of the vehicle’s electrical system during the crash was believed to be the most frequent cause of failed recordings. The air bag control modules are equipped with capacitors to deploy the occupant protection systems. These capacitors do not always have the sufficient power to also record crash data. 4. Crash Damage Prevented Access. Crash damage accounted for approximately 20% of all unsuccessful EDR downloads. This category includes situations where the EDR data could not be accessed due to crash induced deformation. This includes situations where the actual recording-device could not physically be accessed or the interior of the vehicle itself could not be accessed due to crash damage. This category included those situations where it was impossible to interrogate the EDR via the OBD-II vehicle diagnostic connector, and the case annotation mentioned no attempt to directly connect to the EDR. Proper training of crash investigators in the use of EDRs is essential. In November 2002 NHTSA’s National Center for Statistics and Analysis’, Crash Investigation Division produced a NASS Event Data Recorder Data Collection Guideline (Roston, 2002). This Guideline was provided to all NASS, SCI and CIREN personnel and will be provided to new researchers as they attend NASS Basic Training. Additionally, the NASS Basic Training EDR curriculum was reviewed and updated. This additional training in EDR download protocol appears to have had a positive impact on EDR download success rates. In 2002, training/technical problems accounted for nearly half of all unsuccessful downloads. In 2003, after NHTSA initiated its EDR training program, technical / training problems were listed as the reason for only 10% of the unsuccessful downloads. Of concern to all users of EDR data is the frequency with which the OBD-II diagnostic connector was listed as inoperable. This phenomenon should be considered before recommending that the OBD-II diagnostic connector also serve as a universal connection

103 to EDRs. Use of the OBD-II connector requires vehicle power. Generally, vehicles that are involved in a crash of significant severity will be without vehicle power. This can be due to either crash-induced damage or due to actions taken by first responders to render the vehicle safe. Without vehicle power the OBD-II plug is basically useless, and connections must be made to the EDR directly. When one considers the requirement that at least one vehicle in a NASS selected case must be towed due to damage, the need for a crashworthy OBD-II connection becomes very apparent. 4.2.3 Interviews with NASS Field Accident Investigators NHTSA has reported that approximately one-third of all EDR download attempts in 2002 and 2003 by NASS/CDS investigators were unsuccessful [Gabler et al, 2003; Hinch et al, 2004]. To examine the reasons for this lack of success, the research team, with permission from NHTSA, interviewed two NASS/CDS teams about their perceptions of the EDR download process in the field. The first team was located in Ocean County, New Jersey [Sarnecky, 2003 and Parkinson, 2004]. The second team was located in Philadelphia, PA [Zyck, 2003 and Zyck, 2004]. In our interviews, we asked the field investigators to comment on their experiences with EDR data retrieval and specifically on any problems or issues they had encountered during EDR data retrieval. Our findings are summarized below: EDR Access and Connection. The preferred method for accessing EDRs is via connection to the vehicle’s On-Board Diagnostics (OBD-II) port usually located somewhere under the driver’s side dash panel. The OBD-II port was readily accessible to the NASS investigators as it would be to any service personnel that need access to it for other diagnostic purposes. However, downloading an EDR from this location was not always possible. The Ocean County NASS team originally estimated that only one in eight of their EDR download attempts were successful through the OBD-II port [Sarnecky, 2003]. A more recent interview suggested a much higher download rate through the OBD-II port, approximately four out of five vehicles [Parkinson, 2004]. Parkinson noted, however, that this higher rate may simply be the result of investigating less severe crashes since the previous interview. He explained that the vehicle’s electrical system must be intact in order to download the EDR data from the OBD-II port. The Philadelphia NASS team reported that less than half of the EDRs were read through the OBD-II port [Zyck, 2004]. When OBD-II access fails, the Vetronix CDR tool will report the error: “Unable to connect to Module”. In these instances, the NASS investigator must physically locate the EDR in the vehicle and plug directly into it via the cables provided with the Vetronix CDR tool. With OBD-II download impossible in a significant number of cases, direct connection to the EDR is the only other option. Since most EDR boxes are located under one of the front seats, under the carpet, or in the center dash panel depending on make / model, both accident investigation teams originally reported that getting access to the EDR is their

104 greatest challenge. With the EDRs located in these places, the accident investigator must cut through carpet under the front seat or directly into the central dash panel to obtain access to the EDR. It is understandable that a vehicle owner who intends on having their vehicle fixed or salvaged would not want an investigator cutting their carpet or dash panel. Although EDR access is still a major issue, both NASS teams indicated that automobile manufacturers are improving EDR access in newer vehicle models. Examples of access improvements include placement of the EDR in the center console/tunnel as well as pre- cut carpet to allow for access to EDRs located underneath a seat [Zyck, 2004]. In particular, Zyck noted the accessible EDR placement in newer Saturn models. The module is located in the center console and can be accessed by removing a mere three screws and detaching the center console cover. Although the pre-cut carpet aids access, Zyck indicated that under-seat mounted EDRs are sometimes difficult to access in collisions where the seat track is damaged (usually in high severity side impacts). In this case, the entire seat assembly has to be removed to gain access to the EDR; a task that may be avoided if the EDR is located in the center console. For vehicles that are salvageable but have experienced an airbag deployment event, the EDR must be replaced before the vehicle’s safety systems can operate properly due to the permanent storage of deployment in an EDR’s memory. The problem that arises here is that often by the time accident investigators get to a vehicle, the vehicle has already been in for repairs or the repair personal have already serviced the area of the vehicle that entails the EDR. Since this repair is usually done days before accident investigators arrive, the EDR that was in the subject vehicle is discarded and cannot be recovered for download. In addition, the Philadelphia NASS team has found that repair shop owners frequently do not want accident investigators plugging into any diagnostics or other electronics just before or while they are working on the vehicle. EDR Download Failure. EDR durability is another concern for crash investigators and researchers. An EDR can be designed to record many different types of data, but if it cannot withstand the rigors of the crash pulse then it is of little use. The Ocean County team originally estimated that up to one in five of the EDRs that fail could not be downloaded due to some other internal malfunction. This was true whether the EDR was accessed through either the OBD-II port or by direct connection with the access cables. They reported no correlation between EDR download failure and crash severity. This means that a crash investigation of a vehicle that collided with a curb at less than five mph is as likely or unlikely to fail at download as a vehicle that collided head on into a bridge abutment at 30 mph. Although still a concern, both NASS teams indicate that EDR download failure is not typically a significant issue. Of the recent cases investigated by the Philadelphia NASS team, the only instance of internal EDR malfunction occurred because the vehicle was submerged in water [Zyck, 2004].

105 Lack of Correct Cables for Direct Connection. Another requirement, and one particularly important to downloading the EDRs though direct connection, is having the correct cables readily available for the Vetronix CDR tool. Both teams reported that if they had the correct cables for the EDR in question, finding the correct one and plugging into the EDR was straightforward. However, since automakers are constantly upgrading and updating their systems, the cables that are required for downloading certain boxes are not always available to the NASS investigation teams at the time of investigation. Although this has previously been observed to be a problem with some of the latest model GM vehicles and the more recently added Ford vehicles and still continues to be an issue, both teams agreed that improvements have been made in this area. Zyck indicated recently acquiring three new Ford cables and that the team is confident that it can download data from most GM and Ford modules [Zyck, 2004]. Both NASS teams believed that a seemingly trivial solution to this problem would be to have a standard universal cable for all types of EDRs including all manufacturers’ makes and models. The standard cable interface would take the same shape and contain all the pins that could be used in an EDR box. Different makes and models may not use all of the pins however. This solution is very similar to the idea employed by the OBD-II standard in that all manufacturers’ makes and models must conform to the standard. This would allow anyone with a tool for reading the information from one manufacturers’ EDR the ability plug in and view data from any other manufacturer. Overall Perception of Vetronix Data Retrieval. Use of the actual Vetronix CDR tool was reported as simple, provided that the accident investigators have access to the EDR and the correct cables to download the data. The Ocean County team reported that the downloading process was one of the fastest procedures completed by the investigation team. Other EDR Downloading Concerns. Assuming that the accident investigation teams are able to download the EDR from the OBD-II port, they need to obtain the vehicles keys to operate the ignition. Contrary to overall NHTSA findings, the Ocean County team reported that obtaining the vehicles keys was not a problem, making this method of download a simple process when OBD-II download functions correctly. Another concern was the vehicle’s owner’s rights. Currently, the NASS investigation teams obtain permission from the vehicle’s owner when they download an EDR. If the vehicles’ owner cannot be contacted at the time of the investigation, then the data is not downloaded. In cases where the vehicle is totaled, permission is obtained from the salvage yard (the current owner of the car) at the time when the vehicles’ keys are obtained and the data is downloaded. The investigators get the box, download the information and go about the rest of the investigation. Conclusions. Although the percentage of EDR downloads possible through the OBD-II port appears to be improving, there are still a significant number of instances where direct

106 access to the EDR is required. This has important repercussions for the standards groups who are considering future EDR retrieval methods. GM Experience with EDR Data Retrieval The research team followed up these interviews with a phone interview with a subject EDR expert at GM [Floyd, 2003]. GM reports significantly higher success rates at downloading their EDRs through the OBD-II connector. GM uses a technique of externally powering the airbag control module through the fusebox when the car has lost power or no key is available. GM reports that this technique works unless there is significant intrusion or unless the OBD-II connection has been grounded. It should be noted that this technique is not however part of the currently recommended practice when using the Vetronix CDR tool. Using techniques such as these, however, GM estimates that their EDRs can be downloaded through the OBD-II connector 80% of the time. Only an estimated 20% of the attempted downloads require direct connection with cables. In an estimated 5% of all cases, no data can be recovered for reasons including water immersion, fire, or severe crash damage. 4.3 Exporting EDR Data to Accident Databases: Issues and Recommendations 4.3.1 Need for Automated Method to Export EDR Data to Accident Databases The Vetronix CDR software is designed to read and display information for a single EDR case. There is currently no provision for exporting EDR data either to a database or a spreadsheet. The Vetronix CDR software does provide the option to write a report in PDF format, but this format is also not compatible with any databases. While the current form of the Vetronix software is acceptable for individual cases, this design places a huge and growing burden on data collection agencies such as NHTSA or state DOTs which must store thousands of cases. Currently, all EDR data entered into large databases such as the NHTSA NASS/CDS must be manually transcribed from the Vetronix screens into the database. This is a tedious and very error-prone process. NHTSA requires each of their 27 NASS teams to manually transcribe the data as part of their submission for each case. This process requires a significant amount of time to accomplish. Under a separate NHTSA contact to analyze NASS/CDS EDR data, the research team has gained first-hand experience in this tedious process [Gabler et al, 2003]. During the last three years, Rowan University has developed an EDR database of over 1000 cases. For each of these cases, a research assistant has carefully transcribed the EDR data from the Vetronix screens into our database format. Because we were concerned that this process was error-prone, a second research assistant then re-examined each case to ensure that it had been properly entered into our database, and made any necessary corrections.

107 While the process is currently merely burdensome, the rapidly growing number of EDR datasets collected by NHTSA threatens to overwhelm the NASS teams data entry capabilities unless EDR data can be loaded into the accident databases electronically. As can be seen in Table 4-1, the number of EDR datasets retrieved by NHTSA each year is growing rapidly. Table 4-1. Contents of Rowan University EDR Database by Source Source Total Number of Cases NASS/CDS 2000 21 NASS/CDS 2001 192 NASS/CDS 2002 314 NASS/CDS 2003 500+ Total 1000+ 4.3.2 Recommendation Adding an option in the Vetronix software to export the contents of each EDR in an electronic form could eliminate this cumbersome manual data entry process. As part of this study, we contacted Vetronix to determine if there are any plans to add an option to the CDR software to improve the method of data export. Vetronix reports that the bulk of their CDR users are crash investigators who download and analyze single EDR cases. However, the company is developing a CDR-to-XML converter for applications such as NASS/CDS. NHTSA plans to use CDR-to-XML conversion to automatically populate their NASS/CDS database beginning in 2005. Vetronix has provided the research team with a beta version of this promising CDR-to- XML converter for evaluation purposes. To date, we have used the program to convert a Ford case, and a GM case with a Deployment and Deployment Level event. An example of the GM output in XML format is contained in the appendices. As the program is not officially supported by Vetronix, there is no documentation. To support the use of this program by other Vetronix users, we have written a guide to installing and running the converter which is also provided in the appendices.

108 4.4 EDR Data Archival Methods Use of EDR data for highway crash research and policy studies requires the collection, storage, and analysis of large numbers of accident cases. These EDR records are most useful when linked with existing databases, e.g. state or national accident databases, which describe other aspects of the traffic accident. This section discusses current methods for archiving EDR data. The next section provides a recommended format for a standardized EDR database. 4.4.1 Current EDR Data Archival Methods To date, there is no standardized format for storing EDR data in a database to support highway crash safety studies. Most current users of EDR data are accident investigators and store their EDR data in a simple ad hoc fashion on a personal computer. A few groups discussed below have developed rudimentary database formats tailored to their specific needs for the EDR data. Automakers Storage Methods None of the automakers interviewed as part of this project maintains a database of their EDR downloads in the context of a classic relational database. A typical approach is that undertaken by GM which maintains a central repository of information on its accident investigations. In the GM database, the CDR file for each case is stored electronically with other electronic documents which are part of the database. The individual data elements of each CDR file however are not decoded. The rationale is that since both the EDR format and the Vetronix CDR tool are continuously being upgraded, any database format designed with a fixed format would be quickly made obsolete. The belief is that if EDR information needs to be recovered for a particular case, it is better to interpret it each time with the most up to date software. It should be noted however, that while this approach may be appropriate for single cases, it makes database queries based upon this information very difficult. NHTSA Archival of EDR Files When NHTSA initially began to collect EDR data in 1999, the agency stored screen shots of Vetronix screens in BMP format in their Electronic Data Collection System (EDCS). EDCS is an Oracle database which maintains all data associated with NASS/CDS, SCI, and CIREN accident investigation cases. Beginning in 2002, NHTSA expanded the EDCS to allow data entry of all EDR measurements associated with NASS/CDS. EDR data is no longer being entered as BMP format files. In 2005, NHTSA will begin to store the Vetronix CDR files as part of the EDCS database. NHTSA’s current practice is to publicly release the NASS/CDS database as a collection of eleven SAS tables which are populated with data extracted from the EDCS database. The current SAS tables do not contain provision for distributing EDR data. NHTSA

109 however is currently developing a revamped format for the NASS/CDS SAS tables which will include the EDR data. NHTSA is expanding NASS/CDS from the current number of eleven (11) SAS tables to an extended set of twenty-six (26) SAS tables. At the time of this report, NHTSA has released NASS/CDS 2002 and 2003 only in the original eleven table format. NHTSA is expected to release NASS/CDS 2002 and 2003 in the expanded twenty-six table format, containing EDR data, in spring 2005. The proposed SAS format for NASS/CDS EDR data is provided in the appendices. EDR data is stored in three (3) tables – (1) EDR Data table, (2) EDR Crash data table, and (3) the EDR Precrash data table. At the time of this report, the proposed NASS/CDS format did not support multiple events and did not store any of the airbag performance parameters contained in the Vetronix CDR files. Rowan University EDR Database Under sponsorship from NHTSA, Rowan University has developed a database of the NHTSA EDR cases collected to date from NASS/CDS. Currently, the database contains the records of approximately 1000 EDR downloads. Because the formats of the GM and Ford EDRs are so different, Rowan maintains a separate database format for each automaker’s EDR. The GM cases are stored in a spreadsheet consisting of the six (5) tables below. The data elements contained in each of these tables are presented in the appendices. • NASS case description • Non-Deployment Event – Crash Parameters • Deployment Event – Crash Parameters • Non-Deployment Event – Pre-crash parameters • Deployment Event – Pre-crash parameters The Ford cases are stored in a spreadsheet consisting of the five (5) tables listed below: • NASS case description • Ford EDR Model 1FA Parameters • Ford EDR Model 2FA Parameters • Ford EDR Model 1FA Crash Pulse • Ford EDR Model 2FA Crash Pulse The Ford database contains records from two different EDR designs. The approach for the Ford data was to store data from each different EDR model in a separate table, rather than agglomerate the data from each EDR into a common database format. The structure of the Rowan database is regularly modified to accommodate new EDR versions. For ease of numerical analysis, the database is currently stored in the format of a spreadsheet. Both characteristics are acceptable for a research database of modest size,

110 but are not expected to scale well to large databases containing hundred of thousands of records, e.g. state accident databases, which require a standardized database format. 4.5 Recommendations for a Standardized EDR Database This section provides the recommended format for storing EDR data for highway crash data analysis. The EDR database was designed to meet three objectives: (1) the database should accommodate data from diverse existing EDR download formats including all publicly released GM and Ford formats, (2) the database should be able to store the future EDR data elements needed to comply with the NHTSA NRPM on EDRs, and (3) the database should include the recommended list of data elements for Highway Crash Data analysis developed by this research program. 4.5.1 Recommended EDR Database Format The recommended EDR database format stores EDR data in five tables – (1) an EDR Accident table, (2) an EDR Event data table, (3) an EDR Time History data table, (4) an EDR Occupant data table, and (5) an EDR Occupant Restraint data table. The summary which follows lists the contents of each of the database tables. A schematic of the database layout is presented in the figure below: Figure 4-7. Recommended EDR Database Structure EDR Accident Table EDR Event Data Table EDR Time History Table EDR Occupant Table EDR Occupant Restraint Table

111 EDR Accident Record This is the master record for each EDR download. Each EDR download will have exactly one EDR accident record. Name Description Data Type CaseID Case Identification for Linkage with Existing Accident Database Alphanumeric Vehno Vehicle Number for Linkage with Existing Accident Database Integer VIN Vehicle Identification Number Alphanumeric EDRMod EDR Model Alphanumeric IgCrash Ignition Cycles at Crash Integer IgDown Ignition Cycles at Download Integer ABLamp Frontal air bag warning lamp On/Off ABSupp Frontal air bag suppression switch status - right front passenger On/Off NEvents Number of Events (1,2,3) Integer EDRStat Complete File Recorded (yes/no) Extended Boolean Extended Boolean Codes 0 = No 1 = Yes -9 = Not specified / Unknown On/Off Codes 0 = Off 1 = On -9 = Not specified / Unknown

112 EDR Event Record This record is repeated for each event recorded by the EDR. Name Description Data Type CaseID Case Identification for Linkage with Existing Accident Database Alphanumeric Vehno Vehicle Number for Linkage with Existing Accident Database Integer Eventno Event Number Integer Maxdvx Maximum Delta-V, Longitudinal Floating Point Maxdvy Maximum Delta-V, Lateral Floating Point Units Units for Delta-V measurements Coded Tevent Time from Event 1 (seconds) Floating Point DepLvl Deployment level of event Coded DepLvl Deployment Level of Event 0 = Non-deployment 1 = Deployment 2 = Deployment-Level Units Description 0 none 1 G’s 2 Miles/hour 3 Kilometers/hour 4 Degrees 5 Degrees/second 6 Revolutions / Minute (RPM)

113 EDR Time History Record A number of EDR data elements are time histories. One example is delta-V vs. time. This record is repeated for each data element time history. Name Description Data Type CaseID Case Identification for Linkage with Existing Accident Database Alphanumeric Vehno Vehicle Number for Linkage with Existing Accident Database Integer Occno Occupant Number for Linkage with Existing Accident Database Integer ElementID Code for Time History Data Element Coded TimeHistID Sequential code for multiple instances of Element ID Integer Units Units of measure Coded Tstart Seconds from beginning of event Eventno (may be negative to capture pre-impact data) Floating Point Tinterval Time (in seconds) between data samples Floating Point Npoints Number of Points in DataArray Integer DataArray Array of Data Points Array ElementID Description 1 Acceleration, Longitudinal 2 Acceleration, Lateral 3 Acceleration, Normal 4 Delta-V, Longitudinal 5 Delta-V, Lateral 6 Delta-V, Normal 7 Speed, Vehicle indicated 8 Engine Speed (RPM) 9 Engine Throttle (% full) 10 Service Brake (on/off) 11 Vehicle Roll Angle 12 Vehicle Roll Rate 13 Vehicle Pitch Rate 14 Vehicle Yaw Rate 15 ABS activity (engaged / non-engaged) 16 Stability control (on / off / engaged) 17 Steering Input (steering wheel angle) Units Description 0 none 1 G’s 2 Miles/hour 3 Kilometers/hour 4 Degrees 5 Degrees/second 6 Revolutions / Minute (RPM)

114 EDR Occupant Record This record is repeated for each occupant sensed and recorded by EDR. Name Description Data Type CaseID Case Identification for Linkage with Existing Accident Database Alphanumeric Vehno Vehicle Number for Linkage with Existing Accident Database Integer Occno Occupant Number for Linkage with Existing Accident Database Integer Occloc Occupant Location (using NASS Seat Position Code ) Coded SeatBelt Safety belt buckled? Extended boolean SeatPos Seat position, (Is the seat is in a forward seat position?) Extended boolean OccSize Occupant Size Classification Coded OccOOP Occupant Position, (is occupant out of position? yes/no) Extended boolean OccLoc Seat Position * 11 = Driver 12 = Front Seat, Center 13 = Front Seat, Right 21 = Driver 22 = Front Seat, Center 23 = Front Seat, Right * Other Seating position follow the NHTSA NASS/CDS coding convention for occupant location. OccSize Occupant Size Classification 0 = Not Specified 1 = Female, 5th percentile 2 = Not a 5th percentile female 3 = Child 4 = Not a Child Extended Boolean Codes 0 = No 1 = Yes -9 = Not specified / Unknown

115 EDR Occupant Restraint Record This record is repeated for the deployment of each occupant restraint device. Name Description Data Type CaseID Case Identification for Linkage with Existing Accident Database Alphanumeric Vehno Vehicle Number for Linkage with Existing Accident Database Integer Occno Occupant Number for Linkage with Existing Accident Database Integer RestCode Code for Occupant Restraint Coded Eventno Event Number during which restraint deployed Integer DepTime Time of deployment w.r.t. event (seconds) Floating point Disposal Was the device deployed for disposal rather than occupant restraint? Extended Boolean RestCode Description 1 Frontal Air bag, Stage 1 (or only stage, if single stage bag) 2 Frontal Air bag, Stage 2 (or only stage, if single stage bag) 10 Side air bag 11 Side curtain/tube 12 Pretensioner Extended Boolean Codes 0 = No 1 = Yes -9 = Not specified / Unknown

116 4.5.2 Standalone EDR File Archive We recommend that transportation agencies maintain a separate backup copy of each Vetronix CDR file. Both the EDR format and the Vetronix CDR tool are continuously being upgraded. Changes to the CDR tool are occasionally made which may require that the CDR files be decoded again for a more accurate interpretation of the EDR data. As an example, the first 200 cases in the Rowan database were initially decoded using version 1.2 of the Vetronix CDR tool. When v2.0 was released, we decoded these initial 200 cases again and found changes, sometimes dramatic, in the reinterpreted data. Saving the CDR files separately of the database allows the database to be regenerated at any time in the future if this becomes necessary. We recommend that each CDR file should be identified by using the VIN as the file name. 4.6 Conclusions This section has discussed current methods for retrieval and storage of EDR crash data for roadside safety analysis. The discussion has identified several key issues, problems, and recommendations for improvement of these methods. Our conclusions are as follows: 1. Need for a standardized EDR retrieval method. Currently, there is no standardized method to download data from EDRs. Two automakers have awarded an exclusive license to the Vetronix Corporation to market an EDR retrieval tool for their EDRs. The remaining automakers use proprietary tools for EDR data retrieval. 2. Needed for an Automated Method to Export EDR Data. The Vetronix Crash Data Retrieval software does not have any feature which allows electronic export of EDR data to Accident Databases such as NASS/CDS. Currently, all EDR data must be manually transcribed from Vetronix CDR screens into a database – a tedious and error-prone process. Vetronix is however developing a CDR-to-XML conversion program which has promise for federal and state DOTs with existing or planned EDR databases. Follow-on projects should evaluate the use of this EDR data export tool to ease data entry costs for federal and state DOTs. 3. Need for a Reliable, Universal EDR Download Connector. NHTSA has found that in a significant fraction of crashes, accident investigators were unable to use the OBD-II port, the primary Vetronix access point, to access the EDR data. Investigators have the option to directly connect to the EDR. Direct connection however is plagued by the need to partially dismantle the crashed vehicle and the fact that there is no universal EDR connector. We recommend that NHTSA either require a crashworthy OBD-II connection to the EDR, or that NHTSA mandate a universal connector for direct connection to the EDR. 4. Recommended EDR Database Format. Prior to this project, there was no standardized method or recommended practice for archiving EDR data to support

117 roadside or vehicle crashworthiness studies. This project has developed a recommended format for EDR data storage for state or federal transportation agencies wishing to archive EDR data. 5. Need for Training. NHTSA has found that, when its accident investigators were unable to download EDR data, a large fraction of these retrieval failures were because of insufficient training. NHTSA’s rate of successful EDR downloads was greatly improved after the agency established a specialized training program on EDR data retrieval for its investigators. State DOTs who wish to extract EDR data, for applications such as accident databases, should anticipate and plan for this need for specialized training in EDR data retrieval.

118 4.7 References Floyd, D., General Motors subject expert on Event Data Recorders, Interview, (June 2003) Gabler, H.C., Hampton, C., and Roston, T., “Estimating Crash Severity: Can Event Data Recorders Replace Crash Reconstruction?” Proceedings of the Eighteenth International Conference on Enhanced Safety of Vehicles, Paper No. 490, Nagoya, Japan. (May 2003) Hinch, J., Chidester, A., Brophy, J., and Roston, T. “The Use of EDR Technology to Support NHTSA’s Crash Investigation Programs”, Presentation at the SAE Highway Vehicle Event Data Recorder Symposium, Ashburn, VA, (June 2004) Kerr, James, “Vetronix Crash Data Retrieval System”, Presentation at the IEEE P1616 Meeting (September 24, 2002) Kreeb, Robert, “SAE Vehicle Event Data Interface Committee (VEDI): Status Report”, presented to the IEEE P1616 Standards Group, Washington, DC, (May 6, 2003) Parkinson, R., Ocean County NASS Investigation Team, Lakewood, NJ. Interview (November 2, 2004) Roston, T., “NASS Event Data Recorder Data Collection Guideline”, National Highway Traffic Safety Administration (November 2002) Sarnecky, J., Ocean County NASS Investigation Team, Lakewood, NJ. Interview (June 25, 2003) Zyck, M., Philadelphia NASS Investigation Team, Philadelphia, PA., Interview (June 26, 2003) Zyck, M., Philadelphia NASS Investigation Team, Philadelphia, PA., Interview (November 2, 2004)