TABLE of CONTENTS

II.  Proposal and Response to Petition


    As discussed earlier, in the late-1990s, NHTSA denied two petitions for rulemaking requesting the agency to require the installation of EDRs in new motor vehicles, because the motor vehicle industry was already voluntarily moving in the direction recommended by the petitioners, and because the agency believed "this area presents some issues that are, at least for the present time, best addressed in a non-regulatory context."

    Today, after the completion of the NHTSA-sponsored EDR Working Group’s tasks and after considering the public comments and the petition from Dr. Martinez, we have tentatively concluded that motor vehicle safety can be advanced by a limited regulatory approach. In order to promote safety, we are particularly interested in ensuring that when an EDR is provided in a vehicle, the EDR will record the data necessary for effective crash investigations, analysis of the performance of advanced restraint systems, and ACN systems, and that these data can be easily accessed and used by crash investigators and researchers.

    Given what the motor vehicle industry is already doing voluntarily in this area, we are not at this time proposing to require the installation of EDRs in all motor vehicles. As indicated earlier, we estimate that 65 to 90 percent of model year 2004 passenger cars and other light vehicles have some recording capability, and that more than half record such things as crash pulse data.

    We are proposing a regulation that would specify requirements for light vehicles that are equipped with EDRs, i.e., vehicles that record information about crashes. The proposed regulation would (1) require the EDRs in these vehicles to record a minimum set of specified data elements;  (2) specify requirements for data format; (3) require that the EDRs function during and after the front, side and rear vehicle crash tests specified in several Federal motor vehicle safety standards; (4) require vehicle manufacturers to make publicly available information that would enable crash investigators to retrieve data from the EDR; and (5) require vehicle manufacturers to include a brief standardized statement in the owner’s manual indicating that the vehicle is equipped with an EDR and discussing the purposes of EDRs. A discussion of each of these items is provided in the sections that follow.

    The proposed regulation would apply to the same vehicles that are required by statute and by Standard No. 208 to be equipped with frontal air bags, i.e., passenger cars and trucks, buses and multipurpose passenger vehicles with a GVWR of 3,855 kg (8500 pounds) or less and an unloaded vehicle weight of 2,495 kg (5500 pounds) or less, except for walk-in van-type trucks or vehicles designed to be used exclusively by the U.S. Postal Service. This covers the vast majority of light vehicles. Moreover, these are the vehicles that will generally have advanced restraint systems, since they are the ones subject to the advanced air bag requirements now being phased in under Standard No. 208.

    We are not addressing in this document what future role the agency may take related to the continued development and installation of EDRs in heavy vehicles. We will consider that topic separately. Any action we might take in that area would be done in consultation with the Federal Motor Carrier Safety Administration.

    Similar to our approach in the area of vehicle identification numbers, we are proposing a general regulation rather than a Federal motor vehicle safety standard. Thus, while a failure to meet EDR requirements would be subject to an enforcement action, it would not trigger the recall and remedy provisions of the National Traffic and Motor Vehicle Safety Act, currently codified at 49 U.S.C. Chapter 301.

     

    A.  Data Elements to be Recorded

    As indicated above, we are proposing to require light vehicles that are equipped with EDRs to meet a number of requirements, including one for recording specified data elements.

    Before discussing the proposed set of specified data elements, we will briefly address the issue of the crash recording capability that would trigger application of the regulation’s requirements. We are proposing to apply the regulation to vehicles that record any one or more of the following elements just prior to or during a crash, such that the information can be retrieved after the crash:  the vehicle’s longitudinal acceleration, the vehicle’s change in velocity (delta-V), the vehicle’s indicated travel speed, the vehicle’s engine RPM, the vehicle’s engine throttle position, service brake status, ignition cycle, safety belt status, status of the vehicle’s frontal air bag warning lamp, the driver’s frontal air bag deployment level, the right front passenger’s frontal air bag deployment level, the elapsed time to deployment of the first stage of the driver’s frontal air bag, and the elapsed time to deployment of the first stage of the right front passenger’s frontal air bag. Thus, if a vehicle has a device that records any of the basic items of information typically recorded by EDRs, the proposed regulation would apply to that vehicle.

    In analyzing what minimum set of specified data elements to propose, we focused on the elements that would be most useful for effective crash investigations, analysis of the performance of safety equipment, e.g., advanced restraint systems, and ACN systems. We believe these are the areas where information provided by EDRs can lead to the greatest safety benefits.

    EDRs can improve crash investigations by measuring and recording actual crash parameters. They can also measure and record the operation of vehicle devices whose operation cannot readily be determined using traditional post-crash investigative procedures. For example, EDRs could determine whether the ABS system functioned during the crash.

    EDRs can also directly measure crash severity. Currently, NHTSA estimates crash severity using crash reconstruction tools. One product of these tools is an estimate of the vehicle’s delta-V. With an EDR, delta-V could be directly measured. Another assessment made by the crash investigators is the principal direction of force (PDOF). This is currently estimated based on physical damage. With x-axis and y-axis accelerometers, this could be measured or post-processed for planar (non-rollover) crashes, providing PDOF as a function of time.

    EDRs can be particularly helpful in analyzing the performance of advanced restraint systems. They can record important information that is not measurable by post-crash investigations such as time of deployment of pre-tensioners and the various stages of multi-level air bags, the position of a seat during the crash (a seat is often moved by EMS personnel during their extrication efforts), and whether seat belts were latched.

    Improved data from crash investigations will enable the agency and others to better understand the causes of crashes and injury mechanisms, and make it possible to better define and address safety problems. This information can be used to develop improved safety countermeasures and test procedures, and enhance motor vehicle safety.

    EDRs can also make ACN systems more effective. An important challenge of EMS is to find, treat, and transport to hospitals occupants seriously injured in motor vehicle crashes in time to save lives and prevent disabilities. ACN systems, such as the GM On-Star system, can automatically and almost instantly provide information about serious crashes and their location to EMS personnel, based on air bag deployment or other factors. GM has announced that it will begin equipping vehicles with advanced ACN systems that provide measurements of crash forces for improved EMS decision-making. Data from EDRs can be used as inputs for advanced ACN systems.

    As discussed earlier, vehicle manufacturers have made EDR capability an additional function of vehicles’ air bag control systems. The air bag control systems necessarily process a great deal of vehicle information. EDR capability can be added to a vehicle by designing the air bag control system to capture, in the event of a crash, the relevant data in memory. The costs of EDR capability have thus been minimized, because it involves the capture into memory of data that is already being processed by the vehicle, and not the much higher costs of sensing much of that data in the first place.

    In developing our proposed regulation for EDRs, we have followed a similar approach. That is, we have focused on the recording of the most important crash-related data that -are already being processed by vehicles, and not using this rulemaking to require such things as additional accelerometers. (The addition of an accelerometer to a vehicle could add costs on the order of $20 per vehicle.)

    For a variety of reasons, including the fact that the light vehicles covered by this proposal are subject to Standard No. 208’s requirements for air bags, some of the most important crash-related data we have identified are already being processed (or will soon be processed) by all of these vehicles. Under our proposal, these data elements would be required to be recorded for all vehicles subject to the regulation.

    Other important crash-related data are currently processed by some, but not all vehicles. This reflects the fact that some advanced safety systems are provided on some but not all vehicles. Under our proposal, these data elements would be required to be recorded only if the vehicle is equipped with the relevant advanced safety system or sensing capability.

    The following table identifies the data elements that would be required to be recorded under our proposal. We note that the vast majority of the elements in the table are being considered by SAE and/or IEEE in their ongoing efforts to develop standards for EDRs.


Table I

Data Elements that Must Be Recorded
(R=Required; IE=If Equipped)
Data Element R/IE Recording
Interval / Time
Condition for
Requirement (IE)
Longitudinal acceleration R -0.1 to 0.5 sec n.a.
Maximum delta-V R Computed after event n.a.
Speed, vehicle indicated R -8.0 to 0 sec n.a.
Engine RPM R -8.0 to 0 sec n.a.
Engine throttle, % full R -8.0 to 0 sec n.a.
Service brake, on/off R -8.0 to 0 sec n.a.
Ignition cycle, crash R -1.0 sec n.a.
Ignition cycle, download R At time of download n.a.
Safety belt status, driver R -1.0 sec n.a.
Frontal air bag warning lamp, on/off R -1.0 sec n.a.
Frontal air bag deployment level, driver R Event n.a.
Frontal air bag deployment level, right front passenger R Event n.a.
Frontal air bag deployment, time to deploy, in the case of a single stage air bag, or time to first stage deployment, in the case of a multi-stage air bag, driver R Event n.a.
Frontal air bag deployment, time to deploy, in the case of a single stage air bag, or time to first stage deployment, in the case of a multi-stage air bag, right front passenger R Event n.a.
Multi-event, number of events (1,2,3) R Event n.a.
Time from event 1 to 2 R As needed n.a.
Time from event 1 to 3 R As needed n.a.
Complete file recorded (yes, no) R Following other data n.a.
Lateral acceleration IE -0.1 to 0.5 sec If vehicle is equipped to measure acceleration in the vehicle’s lateral (y) direction
Normal acceleration IE -0.1 to 0.5 sec If vehicle is equipped to measure acceleration in the vehicle’s normal (z) direction
Vehicle roll angle IE -1.0 to 6.0 sec If vehicle is equipped to measure or compute vehicle roll angle
ABS activity (engaged, non-engaged) IE -8.0 to 0 sec If vehicle is equipped with ABS
Stability control status, on, off, engaged IE -8.0 to 0 sec If vehicle is equipped with stability control, ESP, or other yaw control system
Steering input (steering wheel angle) IE -8.0 to 0 sec If vehicle equipped to measure steering wheel steer angle
Safety belt status, right front passenger (buckled, not buckled) IE -1.0 sec If vehicle equipped to measure safety belt buckle latch status for the right front passenger
Frontal air bag suppression switch status, right front passenger (on, off, or auto) IE -1.0 sec If vehicle equipped with a manual switch to suppress the frontal air bag for the right front passenger
Frontal air bag deployment, time to Nth stage, driver * IE Event If vehicle equipped with a driver’s frontal air bag with a second stage inflator
Frontal air bag deployment, time to Nth stage, right front passenger * IE Event If vehicle equipped with a right front passenger’s frontal air bag with a second stage inflator
Frontal air bag deployment, Nth stage disposal, Driver, Y/N (whether the Nth stage deployment was for occupant restraint or propellant disposal purposes) * IE Event If vehicle equipped with a driver’s frontal air bag with a second stage that can be ignited for the sole purpose of disposing of the propellant
Frontal air bag deployment, Nth stage disposal, right front passenger, Y/N (whether the Nth stage deployment was for occupant restraint or propellant disposal purposes) *   Event If vehicle equipped with a right front passenger’s frontal air bag with a second stage that can be ignited for the sole purpose of disposing of the propellant
Side air bag deployment, time to deploy, driver   Event If the vehicle is equipped with a side air bag for the driver
Side air bag deployment, time to deploy, right front passenger   Event If the vehicle is equipped with a side air bag for the right front passenger
Side curtain/tube air bag deployment, time to deploy, driver side   Event If the vehicle is equipped with a side curtain or tube air bag for the driver
Side curtain/tube air bag deployment, time to deploy, right side   Event If the vehicle is equipped with a side curtain or tube air bag for the right front passenger
Pretensioner deployment, time to fire, driver   Event If the vehicle is equipped with a pretensioner for the driver safety belt system
Pretensioner deployment, time to fire, right front passenger   Event If the vehicle is equipped with a pretensioner for the right front passenger safety belt system
Seat position, driver (whether or not the seat is forward of a certain position along the seat track)   -1.0 If the vehicle is equipped to measure the position of the driver’s seat
Seat position, passenger (whether or not the right front passenger seat is forward of a certain position along the seat track)   -1.0 If the vehicle is equipped to measure the position of the right front passenger’s seat
Occupant size classification, driver   -1.0 If the vehicle is equipped to determine the size classification of the driver
Occupant size classification, right front passenger   -1.0 If the vehicle is equipped to determine the size classification of the right front passenger
Occupant position classification, driver   -1.0 If the vehicle is equipped to dynamically determine position of the driver.
Occupant position classification, right front passenger   -1.0 If the vehicle is equipped to dynamically determine position of the right front occupant.

* List this element n-1 times, once for each stage of a multi-stage air bag system.


    As indicated above, in developing this list, we focused on the elements that would be most useful for effective crash investigations, analysis of the performance of safety equipment, e.g., advanced restraint systems, and ACN systems. Some of the data elements will be useful for all three of these purposes; others, for only one or two. The following table shows NHTSA’s assessment of the application for each element.



Table II

Data Elements and Application
Data Element Name Crash
Investigation
Advanced
Restraints
Operation
ACN
Longitudinal acceleration X X X
Maximum delta-V X X X
Speed, vehicle indicated X    
Engine RPM X    
Engine throttle, % full X    
Service brake, on/off X    
Ignition cycle, crash X    
Ignition cycle, download X    
Safety belt status, driver X X X
Frontal air bag warning lamp, on/off X X  
Frontal air bag deployment level, driver X X  
Frontal air bag deployment level, right front passenger X X  
Frontal air bag deployment, time to first stage, driver X X  
Frontal air bag deployment, time to first stage, right front passenger X X  
Frontal air bag deployment, time to second stage, driver X X  
Frontal air bag deployment, time to second stage, right front passenger X X  
Frontal air bag deployment, second stage disposal, driver, Y/N X X  
Frontal air bag deployment, second stage disposal, right front passenger, Y/N X X  
Multi-event, number of events X X  
Time from event 1 to 2 X    
Time from event 1 to 3 X    
Complete file recorded X X X
Lateral acceleration X X X             
Normal acceleration X    
Vehicle roll angle X   X
ABS activity X    
Stability control, on, off, engaged X    
Steering input X    
Safety belt status, right front passenger X X X
Frontal air bag suppression switch status, right front passenger X X  
Side air bag deployment, time to deploy, driver X X  
Side air bag deployment, time to deploy, right front passenger X X  
Side curtain/tube air bag deployment, time to deploy, driver side X X  
Side curtain/tube air bag deployment, time to deploy, right side X X  
Pretensioner deployment, time to fire, driver X X  
Pretensioner deployment, time to fire, right front passenger X X  
Seat position, driver X X  
Seat position, right front passenger X X  
Occupant size classification, driver X X  
Occupant size classification, right front passenger X X  
Occupant position classification, driver X X  
Occupant position classification, right front passenger X X  


    Several of the elements are associated with crash severity. These include longitudinal acceleration, lateral acceleration, normal acceleration, delta-V, and vehicle roll angle. The longitudinal, lateral, and normal accelerations are vehicle crash signatures in the x, y, and z directions. Delta-V represents the overall crash severity. These are important elements used in determining vehicle crash severity. Vehicle roll angle is important to determining crash severity in non-planar (rollover) crashes and useful for advanced ACN systems.

    The service brake on/off and steering input elements are important to understanding the human response to avoiding a pending crash. Several elements cover pre-crash vehicle dynamics and system status:  vehicle speed, engine RPM, engine throttle (% full), ABS activity, and stability control (on, off, or engaged). These elements are helpful in determining crash causation.

    The elements concerning ignition cycle provide data on how many times the ignition has been switched on since its first use. The difference in the two measurements provides the number cycles between the time when the data were captured and when they were downloaded. GM, in its EDRs, currently records these data. They aid investigators in determining the interval between the recorded event and the time when it occurred. Small differences between these data indicate that the event in the EDR was generated recently, while large differences indicate that they are from an earlier event that may not be associated with a current crash.

    Many of the data elements relate to the usage and operation of restraint systems. These elements are important in analyzing advanced restraint operations. For example, without an EDR, it may not be possible after a crash to determine whether a multi-stage air bag deployed at a low or high level.

    As discussed above, we are proposing to require some of the data elements to be recorded only if the vehicle is equipped with the relevant safety system or sensing capability. We note that as manufacturers equip greater numbers of their vehicles with advanced safety systems, a number of these data elements would be required to be recorded on an increasing number of vehicles, or even all vehicles. Of particular note, as manufacturers upgrade the side impact performance of their vehicles it is expected that all light vehicles will measure lateral acceleration.

    We request comments on the data elements listed in Table I, including whether the list sufficiently covers technology that is likely to be on vehicles in the next five to 10 years. NHTSA encourages manufacturers to develop, to the extent possible, additional data elements for inclusion in the EDR as these new technologies emerge.

     

    B.  Data Standardization

    As discussed earlier, one of our goals in this rulemaking is to ensure that data are recorded and can be accessed in a manner that enables crash investigators and researchers to use them easily. One aspect of this is the format of the recorded data. To increase the value of these data in assessing motor vehicle safety, the proposed regulation would require that the data be recorded in a standardized format.

    We believe that data standardization would enable crash investigators and researchers to more easily identify, interpret, and compare data retrieved from vehicles involved in a crash. Currently, the data format of an EDR is established by individual manufacturers and is based on that manufacturer’s specific technical specifications. In the absence of any standardization, there is presently a wide variation among vehicle manufacturers as to the format of data recorded by an EDR. Comparisons between data recorded by different manufacturers are less precise when differences exist between the parameters recorded and the precision and accuracy specified. Such comparisons become even less useful if manufacturers do not rely on a common definition of a given data element.

    To address this issue, the Society of Automotive Engineers (SAE) established a committee to establish a common format for the display and presentation of the data recorded by an EDR. The SAE Vehicle Event Data Interface Committee (J1698-1), which held its first meeting in late February 2003, has been considering common data definitions for specific data elements, as well as other aspects of EDR standardization.

    The Institute of Electrical and Electronics Engineers (IEEE) is also addressing the standardization of EDR data formats. The IEEE Motor Vehicle Event Data Recorder (MVEDR) working group (P1616) is drafting a data dictionary and standards document for EDRs. P1616 is considering specifying the data format with a set of attributes for each defined data element. IEEE stated that it expected to complete a standard to standardize data output and retrieval protocols by March 2004.

    In light of the current lack of adopted industry standards, we are proposing a standardized format that would ensure the usability of EDR data, while still providing manufacturers flexibility in design. The proposed regulation would define each data element and specify the corresponding recording interval/time, unit of measurement, sample rate, data range, data accuracy, data precision, and where appropriate, filter class. The proposed data format would require EDRs to capture crash data of sufficient detail and time duration to ensure the usefulness of the data in crash reconstruction without threatening its integrity. NHTSA crash testing has shown that the typical offset frontal crash may last as long as 250 milliseconds. We are also aware that underride and override crashes may last even longer. Furthermore, rollover crashes can last several seconds, depending on the number of rolls.

    The proposed time periods (set forth in Table I above) would establish a recording duration of 8 seconds prior to beginning of the event to capture relevant pre-crash and event data. Acceleration data would be required to be captured during the event. Finally, only rollover data would be required to be recorded for several seconds after the event. To the extent possible, the specified recording duration is limited to reduce the likelihood of data being corrupted by failure in the vehicle’s electric system resulting from the crash

    The proposed format would not mandate storage or output parameters.

     

    C.  Data Retrieval

    A second aspect of accessibility is the necessity for crash investigators and researchers to have the capability of downloading crash data from the EDR. To ensure the availability of these data, we are proposing to require vehicle manufacturers to submit to the NHTSA docket specifications for accessing and retrieving the recorded EDR data that would be required by this regulation. We are also seeking comment on alternative approaches.

    At the present time, investigators and researchers can access crash data stored by EDRs for only a limited number of vehicles. Prior to 2000, only vehicle manufacturers could access the EDR data for their vehicles. In 2000, Vetronix released its Crash Data Retrieval (CDR) tool for sale to the public. The CDR tool is a software and hardware device that allows someone with a computer to communicate directly with certain EDRs and download the stored data. It is estimated that about 40 million vehicles on the road have EDRs that can be read using the CDR tool, including many late model GM vehicles and some new Ford vehicles.

    However, Vetronix is licensed by only a limited number of vehicle manufacturers to build these devices. Vetronix must presently use proprietary vehicle manufacturer information to develop and configure the hardware and software needed to allow the CDR tool to retrieve data from a vehicle’s EDR. If a vehicle manufacturer declines to license or otherwise provide any proprietary information needed to build a device, tool companies will not be able to produce them.

    Both the SAE Vehicle Event Data Interface Committee (J1698-1) and the IEEE Motor Vehicle Event Data Recorder working group (P1616) discussed above have considered the downloading of EDR data by means of the On Board Diagnostic (OBD) connector developed in conjunction with the Environmental Protection Agency (EPA). EPA has established requirements for onboard diagnostic technologies, which manage and monitor a vehicle’s engine, transmission, and emissions.  The EPA regulations include a new standardized communications protocol for the next generation of onboard diagnostic technology that allows a single common interface between the OBD connector and diagnostic tools used to read and interpret vehicle data and convert them into engineering units.

    The EPA communications protocol utilizes a Controller Area Network (CAN) to provide a standardized interface between the OBD connector and the tools used by service technicians and vehicle emission inspections stations. CAN employs a serial bus for networking computer modules as well as sensors. The standardized interface allows technicians to use a single communications protocol to download data to pinpoint problems and potential problems related to a vehicle’s emissions.

    Full implementation of the CAN protocol is required by 2008. Because it is a universal system, the use of the OBD connector and the CAN serial bus could assure uniform access to EDR data and alleviate concerns that the data would only be accessible through the use of multiple interfaces and different kinds of software, if at all.

    While standardizing the means of downloading EDR data, possibly using the OBD connector, offers potential benefits, we are at this time proposing only to require vehicle manufacturers to submit to the agency docket specifications necessary for building a device for accessing and retrieving recorded EDR data. This approach will help ensure that EDR data can be accessed in a manner readily usable by crash investigators and researchers. It will also allow motor vehicle manufacturers the flexibility to standardize protocols for data extraction.

    We note that the context of NHTSA’s proposal is quite different from the context of EPA’s requirements for collecting, storing, and downloading emissions-related data. The EPA approach is very structured. It needed to be appropriate for facilitating the routine monitoring and servicing of mandated emission control systems on motor vehicles, thus helping to ensure that those systems perform properly over the useful life of those vehicles. Establishing that approach has required many years of effort and the development of numerous industry standards.

    On the other hand, we are proposing a standard for voluntarily installed EDRs, and need to ensure that it is appropriate for the much more limited purpose of crash investigations. We are interested in a simple, flexible approach, while maintaining the ability to extract data efficiently from a motor vehicle’s voluntarily installed EDR. To obtain the desired outcome, NHTSA believes that it need not and should not become involved in managing the interface between the auto industry and the companies that may manufacture EDR download tools. But it is evident that some interface is needed, and to that extent we are proposing that certain information be provided.

    We are proposing to require that each manufacturer of vehicles equipped with EDRs provide information of sufficient detail to permit companies that manufacture diagnostic tools to develop and build devices for accessing and retrieving the data stored in the EDRs. The vehicle manufacturer would be required to specify which makes and models (by model year) of its vehicles utilize the corresponding EDR system and to specify the interface locations. The leadtime we are providing for implementing this proposed regulation (discussed below) would enable vehicle manufacturers to design their EDRs so that the data may be accessed by use of a standardized interface and communications protocol. In the event that SAE, IEEE, or other voluntary standard organization establishes a standard for a protocol to be used in downloading EDR data, manufacturers would be able to reference the industry protocol in their submissions.

    Manufacturers would be required to submit this information in a timely manner to ensure that the specifications were received by NHTSA’s docket not less than 90 days before the start of production of makes and models utilizing EDR systems. This would give tool companies time to develop a tool before an EDR-equipped vehicle is used on public roads.

    We are also seeking comment on alternative approaches to providing access to EDR crash data, such as permitting the vehicle manufacturer to demonstrate that a reasonably priced tool is publicly available for a particular make/model or to offer to licence at a reasonable price any proprietary information needed to build such tools. We note that EPA permits manufacturers to request a reasonable price for provided OBD-related information. See EPA final rule at 68 FR 38427, June 27, 2003. Comments are requested on the similarities and differences between OBD and EDR related information, the uses of that information, and relevant statutory authorities, and on whether this type of approach would be appropriate for EDR information. We note that one difference is that OBD tools are used as part of commercial activity, i.e., routine servicing and repair of motor vehicles, while EDR tools as used in crash investigations. The market for EDR tools would likely be much smaller. If we were to adopt an approach along these lines, what factors should be used for determining a "reasonable price?"

      Commenters supporting any of these or other alternative approaches are encouraged to suggest specific regulatory text and to explain how the recommended approach would ensure that crash investigators and researchers have the capability of downloading data from EDRs. Depending on the comments, we may adopt an alternative approach in the final rule.

     

    D.  Functioning of Event Data Recorders and Crash Survivability

    If an EDR is to provide useful information, it must function properly during a crash, and the data must survive the crash. We are proposing several requirements related to the functioning of the EDR and survivability.

    Performance of EDRs in crash tests. First, we are proposing to require EDRs to meet the requirements for applicable data elements and format in the crash tests specified in Standards No. 208, 214, and 301. These tests are (some have been issued as final rules, but not yet taken effect) a frontal barrier crash test conducted at speeds up to 35 mph, a frontal offset test conducted at 25 mph, a rear-impact crash test conducted at 50 mph, and a side impact test conducted at 33.5 mph. Data would be required to be retrievable by the method specified by the vehicle manufacturer (discussed above) after the crash test.

    This requirement would provide both a check on EDR performance and also ensure a basic level of survivability. Manufacturers are familiar with these crash tests since they are specified in the Federal motor vehicle safety standards.

    As to the issue of survivability, the EDRs of light vehicles are currently part of the air bag module. These modules are located in the occupant compartment of vehicles, providing protection against crush in all but the most severe crashes. Moreover, because EDRs are part of the air bag module, their electronics are designed to operate in a shock environment. However, current EDRs lack protection from fire and immersion in water and motor vehicle fluids.

    While requiring EDRs to function properly during and after the crash tests specified in Standards No. 208, 214, and 301 would ensure a basic level of survivability, it would not ensure that EDR data survive extremely severe crashes or ones involving fire or fluid immersion. While EDR data would be useful to crash investigators and researchers analyzing such crashes, we do not have sufficient information to propose survivability requirements that would address such crashes. Research is needed to develop such requirements, and information on the costs of countermeasures to meet these additional requirements would need to be developed. Countermeasures that would ensure the survivability of EDR data in fires may be costly. For all of these reasons, we are not including such requirements in this proposal.

    Trigger threshold. We are also proposing requirements concerning the level of crashes for which EDRs must capture [10] data. These requirements would ensure that EDRs capture information about crashes of interest to crash investigators and researchers.

    The EDR operates in two modes. One is the steady state monitoring of pre-crash data. EDRs operate continuously in this mode whenever the vehicle is operating. This process allows momentary recording [11] of the pre-crash data. EDRs operate in the second mode when the vehicle is involved in a crash. In this mode, two decisions are made. The first is the determination of the occurrence of a crash and is accomplished by use of a trigger threshold. The second is the decision to capture the recorded data and accomplished using a comparative process. Based on the outcome of this process, the recorded data associated with a crash are captured or deleted.

    In current light-duty vehicle applications, the trigger threshold is associated with the air bag crash severity analyzer. The circumstances that cause the threshold to be met are called an "event." The beginning of the event that causes current EDRs to start capturing data in its permanent memory is sometimes defined as the vehicle’s exceeding a specified deceleration threshold, typically around 2 g’s. After the event is over, and the air bags are deployed, the data are stored in the EDR, if appropriate.

    For determination of the beginning of an event, we are proposing to require the EDR to start recording data when the vehicle’s change in velocity during any 20 millisecond (ms) time interval equals or exceeds 0.8 km/h. That is equivalent to slightly more than 1 g of steady-state deceleration.

    The vehicle’s change in velocity is determined in one of two ways, depending on the data collected by the EDR. In the case of a vehicle that does not record and capture lateral acceleration, the delta-V is based on the longitudinal acceleration only. In the more complex case of a vehicle whose EDR records and captures both longitudinal and lateral acceleration, the delta-V is calculated based on both sets of data, or, simply stated, change in velocity of the vehicle in the horizontal plane.

    Timing of the unique, non-recurrent actions like the deployment of an air bag in an event is very important. The trigger threshold is used to define time zero. Time zero is used to determine many of the parameters required for collection by the EDR, such as the time when the front air bag deploys. Time zero is defined as the beginning of the first 20 ms time interval in which the trigger threshold is met during an event. Time zero is used to determine many of the parameters required for collection by the EDR, such as the time of front air bag deployment.

    Recording multi-event crashes. A crash may encompass several events. For example, a vehicle may sideswipe a guardrail and then hit a car, or a vehicle may hit one vehicle, then another, and finally a tree. In fact, analysis of crash data from NHTSA’s NASS-CDS data system shows that while 54 percent of the crashes involve a single event, 28 percent involve 2 events, and 18 percent involve 3 or more events. [12] Thus, if an EDR captures only a single event as the depiction of a multi-event crash, in nearly one-half of the cases, it could be difficult to determine the event of the crash with which the EDR record was associated.

    Current EDRs vary with respect to the number of events they capture. For example, current Ford systems capture single events. GM systems can capture two events, one non-deployment event and one deployment event. These two events can be linked ones under certain circumstances. If they are linked, the amount of time between events is recorded. Current Toyota EDRs can capture up to three events. These can also be linked to a chain of events making up a single crash sequence.

    We are proposing to require that EDRs be capable of capturing up to 3 events in a multi-event crash. For any given event that generates a change in velocity that equals or exceeds the trigger threshold, the EDR would be required to record and possibly capture that event and any subsequent events, up to a total of three, that begin within a 5 second window from time zero of the first event. Subsequent events are events that meet the trigger threshold more than 500 milliseconds after time zero of the immediately preceding event. We note it is very likely that in a crash, the trigger threshold could be met or exceeded many times Thus, we are requiring that when the EDR is currently recording event data, the exceeding of the trigger threshold be disregarded until 500 milliseconds has elapsed.

    To prevent unassociated events from being captured in the multi-event EDR, we are proposing that the maximum time from the beginning of the first event to the beginning of the third event be limited to 5.0 seconds. To understand the timing between the associated events, we are proposing to require that the number of associated events be included as a data element, and that the time from the first to the second event and the time from the first to the third event also be included as a data element.

    The pre-event data, such as vehicle speed and engine RPM, need to be recorded continuously. Similarly, pre-event acceleration data need to be recorded continuously. Finally, pre-event statuses, such as safety belt usage, determined at –1.0 second, need a similar treatment. The recording of these data is sometimes referred to as a circular buffer; that is, data are continuously updated as they are generated. When the trigger threshold is met, additional types of data are recorded, including acceleration data and rollover angle.

    Capture of EDR data. Once the trigger threshold has been met or exceeded, the data discussed above are recorded by the EDR. The EDR continues to analyze the acceleration signal(s) to determine if a second or third event, determined by the trigger threshold’s being equaled or exceeded more than 500 milliseconds after time zero of the immediately preceding event, will occur in a possible multi-event crash. This continues for 5 seconds after time zero of the first event.

    A decision is then required to determine if these recorded data should be captured in the EDR’s memory bank or discarded in favor of a previously captured data set. This decision is based on the maximum delta-V in the sequence of up to 3 events and air bag deployment status.

    The maximum delta-V for a multi-event crash would be defined as the absolute value of the maximum of the individual delta-Vs from each of the events in the crash. Since events in a multi-event crash may occur from the front, side, or rear, we are proposing that the maximum delta-V be based on the magnitude of the value, that is, irrespective of the direction, or sign of the value.

    We are proposing that the recorded data be captured in the EDR’s memory only if the maximum delta-V for the recorded crash sequence exceeds that of the maximum delta-v associated with the data currently stored in the EDR’s memory. We are making this proposal to prevent the capturing of EDR crash data with data from new events that may occur subsequent to the event of greatest interest. In the absence of such a requirement, the trigger threshold might be exceeded when the vehicle is towed from the scene or moved in a salvage yard, thus capturing a new record and erasing data regarding the event of greatest interest.

    With regard to air bag deployment status, we are proposing that an event that generates information related to an air bag deployment, either frontal or side bag systems, must be captured by the EDRs and cannot be overwritten.

    We note that on current GM systems, the EDR locks the data in memory after a crash that involves an air bag deployment. This results in the air bag control system’s needing replacement as part of the vehicle’s repair after an air bag deployment. On Ford vehicles, the file is not locked when an air bag deploys. However, it is Ford’s current service policy that the control module must be replaced after each deployment event.

    In the case of multi-event crashes, some of the pre-crash data will be common to each event. For example, vehicle speed data would be collected for 8 seconds prior to the first event. If the second event occurs 1 second later, an additional sample of speed data would be recorded before the second event. For these cases, only the additional pre-crash data that occur during and between the events would need to be recorded as part of the subsequent event.

    To prevent confusion between different multi-event crashes, we are proposing that if a crash includes an event that has a maximum delta-V of sufficient magnitude to warrant capturing the data relating to that event, all previously captured data in the EDR memory must be erased and replaced with that new data. We believe that unless this is done, events that occur days or months apart may be mistakenly interpreted as being part of the same crash.

     

    E.  Privacy

    The recording of information by EDRs raises a number of potential privacy issues. [13]  These include the question of who owns the information that has been recorded, the circumstances under which other persons may obtain that information, and the purposes for which those other persons may use that information.

    We recognize the importance of these legal issues. The EDR Working Group, too, recognized their importance and devoted a considerable amount of time to discussing them. It also included a chapter on them in its August 2001 final report. Among other things, the chapter summarizes the positions that various participants in the EDR Working Group took on privacy issues.

    We also recognize the importance of public acceptance of this device, whether voluntarily provided by vehicle manufacturers or required by the government. We note that General Motors informed the EDR Working Group (Docket No. NHTSA-99-5218-9; section 8.3.5) that it believes the risk of private citizens reacting negatively to the "monitoring" function of the EDR can be addressed through honest and open communications to customers by means of statements in owners' manuals informing them that such data are recorded. That company indicated that the recording of these data is more likely to be accepted if the data are used to improve the product or improve the general cause of public safety.

    While we believe that continued attention to privacy issues is important, we observe that, from the standpoint of statutory authority, our role in protecting privacy is a limited one. For example, we do not have authority over such areas as who owns the information that has been recorded. Some of these areas are covered by a variety of Federal and State laws not administered by NHTSA.

    Moreover, we believe that our proposed requirements would not create any privacy problems. We are not proposing to require the recording of any data containing any personal or location identifiers. In addition, given the extremely short duration of the recording of the information and the fact that it is only recorded for crashes, the required information could not be used to determine hours of service of commercial drivers.

    The recorded information would be technical, vehicle-related information covering a very brief period that begins a few seconds before a crash and ends a few seconds afterwards. Many of these same data are routinely collected during crash investigations, but are based on estimations and reconstruction instead of direct data. For example, investigators currently estimate vehicle speed based on a variety of factors such as damage to the vehicle. The proposal would simply help ensure a more accurate determination of these factors by providing direct measurements of vehicle operation during a crash event.

    To help address possible concerns about public knowledge about EDRs, we are proposing to require manufacturers of vehicles equipped with EDRs to include a standardized statement in the owner’s manual indicating that the vehicles are equipped with an EDR and that the data collected in EDRs is used to improve safety. [14]  The proposed statement would read as follows:

    This vehicle is equipped with an event data recorder. In the event of a crash, this device records data related to vehicle dynamics and safety systems for a short period of time, typically 30 seconds or less. These data can help provide a better understanding of the circumstances in which crashes and injuries occur and lead to the designing of safer vehicles. This device does not collect or store personal information.

    Moreover, while access to data in EDRs is generally a matter of state law, we believe that access is and will continue to be possible in only limited situations. While the proposal would require public access to information on the protocol for downloading EDR data, this will not result in public access to EDR data. The interfaces for downloading EDR data will most likely be in a vehicle’s passenger compartment. The interface locations will not be accessible to individuals unless they have access to the passenger compartment.

    Further, in our own use of information from EDRs, we are careful to protect privacy. As part of our crash investigations, including those that utilize EDRs, we often obtain personal information. In handling this information, the agency complies with applicable provisions of the Privacy Act of 1974, the Freedom of Information Act (section (b)(6)), and other statutory requirements that limit the disclosure of personal information by Federal agencies. In order to gain access to EDR data to aid our crash investigations, we obtain a release for the data from the owner of the vehicle. We assure the owner that all personally identifiable information will be held confidential.

     

    F.  Leadtime

    We are proposing an effective date of September 1, 2008. This would enable manufacturers to make design changes to their EDRs as they make other design changes to their vehicles, thereby minimizing costs.

     

    G.  Response to Petition from Dr. Martinez

    As discussed earlier, in October 2001, the agency received a petition from Dr. Ricardo Martinez, President of Safety Intelligence Systems Corporation, asking us to "mandate the collection and storage of onboard vehicle crash event data, in a standardized data and content format and in a way that is retrievable from the vehicle after the crash." We are granting the petition in part and denying it in part.

    As discussed above, our proposed regulation would specify requirements concerning the collection and storage of onboard vehicle crash event data by EDRs, in a standard data and content format, and in a way that is retrievable from the vehicle after the crash. To that extent, we are granting Dr. Martinez’s petition. We are not proposing to mandate EDRs, however, and to that extent we are denying the petition.

    We believe that the motor vehicle industry is continuing to move voluntarily in the direction of providing EDRs. As indicated earlier, we estimate that 65 to 90 percent of model year 2004 passenger cars and other light vehicles have some recording capability, and that more than half record such things as crash pulse data.

    The trends toward installation of EDRs in greater numbers of motor vehicles, and toward designing EDRs to record greater amounts of crash data, are continuing ones. General Motors (GM) first began installing EDRs in its air bag equipped vehicles in the early 1990’s. In 1994, that company began phasing in upgraded EDRs that record crash pulse information. GM upgraded its EDRs again around 1999-2000 to begin recording pre-crash information such as vehicle speed, engine RPM, throttle position, and brake status.

    Also around 1999-2000, Ford began equipping the Taurus with EDRs that recorded both longitudinal and lateral acceleration and several parameters associated with the restraint systems, including safety belt use, pretensioner deployment, air bag firing, and others. Also in the past few years, Toyota began installing EDRs in its vehicles.

    As of now, GM, Ford and Toyota record what would be considered a large amount of crash data. Honda, BMW and some other vehicle manufacturers record small amounts of crash data.

    Given these trends, we do not believe it is necessary for us to propose to require EDRs at this time. [15]  Moreover, we believe that as manufacturers provide advanced restraint systems in their vehicles, such as advanced air bags, they will have increased incentives to equip their vehicles with EDRs. Vehicle manufacturers will want to understand the real world performance of the advanced restraint systems they provide. EDRs will provide important data to help them understand that performance.

    We believe our focus should be on helping to ensure that when an EDR is provided in a vehicle, it will record appropriate data in a consistent format and will be accessible in a manner that makes it possible for crash investigators and researchers to use them easily.

    We note that we believe our proposed regulation would not adversely affect the numbers of EDRs provided in motor vehicles. [16] We recognize that, if a regulation made EDRs costly, it could act as a disincentive to manufacturers’ providing EDRs. However, as discussed earlier, vehicle manufacturers have minimized the costs of adding EDR capability by designing the air bag control system to capture into memory data that are already being processed by the vehicle. Similarly, in developing our proposal, we focused on the recording of the most important crash-related data that are already being processed by vehicles, and not using the rulemaking to require such things as additional accelerometers. The additional costs associated with an EDR meeting the proposed requirements, compared with those currently being provided voluntarily by the vehicle manufacturers, would therefore be small.



    [10] Capturing is the process of saving recorded data.

    [11] Recording is the process of storing data into volatile memory for later use

    [12] Gabler and Roston, "Estimating Crash Severity: Can Event Data Recorders Replace Crash Reconstruction," ESV Paper 490, 2003, http://www-nrd.nhtsa.dot.gov/pdf/nrd-01/esv/esv18/CD/Files/18ESV-000490.pdf

    [13] We note that, in some press articles and op-ed pieces, persons have cited privacy issues as a reason for opposing the basic concept of EDRs.

    [14] On September 20, 2003, the Governor of California approved a law requiring that manufacturers of new motor vehicles that are manufactured on or after July 1, 2004 and are equipped with EDRs must disclose the existence of the EDRs in the vehicle owner’s manual.

    [15] If our expectations prove incorrect, we may revisit this issue.

    [16] See the immediately previous footnote.


TABLE of CONTENTS