Event Data Recorders, 2168-2184 [E8-407]

Agencies

• National Highway Traffic Safety Administration
• DEPARTMENT OF TRANSPORTATION

[Federal Register Volume 73, Number 9 (Monday, January 14, 2008)]
[Rules and Regulations]
[Pages 2168-2184]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: E8-407]


=======================================================================
-----------------------------------------------------------------------

DEPARTMENT OF TRANSPORTATION

National Highway Traffic Safety Administration

49 CFR Part 563

[Docket No. NHTSA-2008-0004]
RIN 2127-AK12


Event Data Recorders

AGENCY: National Highway Traffic Safety Administration (NHTSA), 
Department of Transportation.

ACTION: Final rule; response to petitions for reconsideration.

-----------------------------------------------------------------------

[[Page 2169]]

SUMMARY: In August 2006, NHTSA published a final rule specifying 
uniform requirements for the accuracy, collection, storage, 
survivability, and retrievability of onboard motor vehicle crash event 
data in passenger cars and other light vehicles voluntarily equipped 
with event data recorders (EDRs). The final rule was intended to 
standardize the data collected through EDRs so that it could be put to 
the most effective future use. This document responds to several 
petitions for reconsideration of the August 2006 rule. After carefully 
considering the issues raised, the agency is granting some aspects of 
the petitions, and denying some aspects. This document amends the final 
rule accordingly.

DATES: Effective Date: The amendments in this rule are effective March 
14, 2008.
    Compliance Dates: Except as provided below, light vehicles 
manufactured on or after September 1, 2012 that are equipped with an 
EDR and manufacturers of those vehicles must comply with this rule. 
However, vehicles that are manufactured in two or more stages or that 
are altered are not required to comply with the rule until September 1, 
2013. Voluntary compliance is permitted before that date.
    Petitions: If you wish to submit a petition for reconsideration of 
this rule, your petition must be received by February 28, 2008.

ADDRESSES: Petitions for reconsideration should refer to the docket 
number and be submitted to: Administrator, National Highway Traffic 
Safety Administration, 1200 New Jersey Avenue, SE., West Building, 4th 
Floor, Washington, DC 20590. Please see the Privacy Act heading under 
Regulatory Notices.

FOR FURTHER INFORMATION CONTACT: For technical and policy issues, 
contact David Sutula, Office of Crashworthiness Standards, by telephone 
at (202) 366-1740, or by fax at (202) 493-2739.
    For legal issues, contact Rebecca Schade, Office of the Chief 
Counsel, by telephone at (202) 366-2992, or by fax at (202) 366-3820.
    Both persons may be reached by mail at the following address: 
National Highway Traffic Safety Administration, U.S. Department of 
Transportation, 1200 New Jersey Avenue, SE., Washington, DC 20590.

SUPPLEMENTARY INFORMATION: 

Table of Contents

I. Summary of Final Rule; Responses to Petitions for Reconsideration
II. EDR Background
III. Discussion and Analysis of Responses to Petitions for 
Reconsideration
    A. Event Data Storage
    1. Storage of Multiple Events
    2. Event Recording Intervals
    3. Reusability of EDRs
    B. Data Format
    C. Sensor Accuracy and Range
    1. Sensor Accuracy
    2. Sensor Range
    D. Data Survivability and Retrievability
    E. Required Data Elements
    1. Peripheral Sensors
    2. Steering Input and Wheel Angle
    3. Vehicle Roll Angle Accuracy
    4. Data Element Definitions
    (a) Definition of Time to Maximum Delta-V Resultant
    (b) Clarification of Engine RPM Definitions
    (c) Clarification of Readiness Indicator Lamp
    5. Whether the Suppression Switch ``Auto'' Data Element in Table 
II Should be Retained
    6. Whether the ``Vehicle Speed Indicated'' Data Element in Table 
III Is Feasible
    7. Whether Additional Data Elements Should Be Included
    F. Lead Time
    G. Whether NHTSA Should Mandate EDRs
    H. Public Privacy and Consumer Notification of EDRs
    1. Whether NHTSA Should Require a Mechanical Lockout on EDRs
    2. Whether NHTSA Should Require EDR Download Tools To Be 
Standardized at This Time
    3. Whether NHTSA Should Require Additional Consumer Notification
    4. Whether EDR Data Should Be Included in the FARS System
    I. Other Technical Revisions
    J. Summary of Other Letters to the Docket
    IV. Rulemaking Analyses and Notices
    V. Regulatory Text

I. Summary of the Final Rule; Responses to Petitions for 
Reconsideration

    In this document, NHTSA responds to petitions for reconsideration 
of its August 2006 final rule concerning EDRs. That rule specified 
uniform requirements for the accuracy, collection, storage, 
survivability, and retrievability of onboard motor vehicle crash event 
data in passenger cars and other light vehicles voluntarily equipped 
with event data recorders (EDRs).
    We are granting a number of the petitions in part. In granting 
these petitions, today's final rule makes several changes to the 
regulatory text of 49 CFR part 563, Event Data Recorders. These are 
largely technical changes, all of which are consistent with agency's 
goal in the original final rule of limiting the requirements to those 
necessary to achieve our stated purposes, reflecting current EDR 
technology, and avoiding unnecessary costs. Changes to the regulatory 
text are summarized below.
    We are denying a petition from Public Citizen asking that we 
require EDRs, include requirements for additional data elements, and 
increase the stringency of the data survivability requirements. We are 
also denying a request from Mr. Thomas Kowalick that we require 
inclusion of a mechanical lockout port to prevent EDR data tampering.

Summary of Changes

    1. In order to avoid vehicle manufacturers incurring significant 
additional costs, unintended by the final rule, to redevelop EDR system 
architectures outside the normal product cycle, Sec.  563.3 is being 
amended to include a later compliance date. Specifically, the 
compliance date will generally be September 1, 2012, but September 1, 
2013 for vehicles that are manufactured in two or more stages or that 
are altered after having been previously certified to the FMVSS. This 
change will also allow the agency to continue to collect data from 
vehicles with EDRs that do not meet the full requirements of the final 
rule.
    2. To avoid EDR data being filtered beyond usefulness, the agency 
is removing the Society of Automotive Engineers (SAE) J211-1 filter 
class from Table III of Sec.  563.8 and from incorporation by reference 
in Sec.  563.4. The agency agrees, based on additional information, 
that current technology EDRs on the market are able to filter data 
internally, and an additional filtering step is usually unnecessary if 
not unhelpful.
    3. To clarify the final rule more fully, the agency is adding 
definitions in Sec.  563.5 for ``maximum delta-V, resultant'' and 
``time, maximum delta-V, resultant,'' and amending the definitions for 
``end of event time,'' ``engine RPM,'' ``event,'' and ``time zero.''
    4. To clarify the definition and permissible uses of the frontal 
air bag warning lamp, and to clarify that the ignition cycle at time of 
download need only be reported during the download process, footnotes 
are being added to Table I in Sec.  563.7.
    5. As petitioners pointed out to the agency, the SAE standard on 
which Part 563 was originally based contained standards for reporting 
rather than recording data elements. To avoid requiring EDRs to 
function at levels well beyond those necessary for the purposes of the 
final rule, Sec.  563.8 and Table III are being amended to clarify that 
the format specified is for reported, not recorded, data elements.
    6. As written in the final rule, Sec.  563.9 required EDRs to erase 
recorded data before beginning to record new data of an air bag 
deployment. This consumes EDR system resources and time, which may be 
needed to record a closely-

[[Page 2170]]

following second deployment event, and in long events, the EDR may 
inappropriately process and prioritize event data. We are amending 
Sec.  563.9 to allow the EDR to ``overwrite'' rather than erase 
previous event data contained in the EDR memory buffers, and to clarify 
how the EDR should prioritize multiple events and events involving 
deployable restraint systems other than air bags.

II. EDR Background

    Event data recorders are a rapidly developing technology used in a 
variety of transportation modes to collect crash information. In motor 
vehicles, that information aids NHTSA in improving our understanding of 
crash events and safety system performance. Ideally, it can help 
manufacturers to develop future safer vehicle designs and NHTSA to 
develop more effective safety regulations. EDR data will also likely 
play an increasing role in advancing developing networks for providing 
emergency medical services, like automatic crash notification (ACN) and 
electronic 9-1-1 (e-911).
    As a technology, EDRs have experienced dramatic changes in the past 
decade, both in terms of their technical capabilities and their 
penetration into vehicle fleets. EDRs today demonstrate a range of 
features: Some systems collect only vehicle acceleration and 
deceleration data, but others collect these plus additional 
complementary data, such as driver inputs (like braking and steering) 
and vehicle system status. NHTSA's challenge has been to encourage 
broad application of EDR technologies in motor vehicles and maximize 
the usefulness of EDR data for vehicle designers, researchers, and the 
medical community, without imposing unnecessary burdens or deterring 
future improvements to EDRs that have been voluntarily installed.
    For much more background information on EDR technologies, please 
see the NPRM and the final rule, at 69 FR 32932 (June 14, 2004) \1\ and 
71 FR 50998 (August 28, 2006),\2\ respectively.
---------------------------------------------------------------------------

    \1\ Docket No. NHTSA-2004-18029.
    \2\ Docket No. NHTSA-2006-25666.
---------------------------------------------------------------------------

III. Discussion and Analysis of Responses to Petitions for 
Reconsideration

    The agency received eight petitions for reconsideration in response 
to the final rule. Petitions were received from two vehicle 
manufacturer associations, the Alliance of Automobile Manufacturers 
(Alliance) and the Association of International Automobile 
Manufacturers (AIAM); two individual vehicle manufacturers, Nissan and 
Toyota; a manufacturer of EDR components, Delphi Corporation; the 
Automotive Occupant Restraints Council (AORC); Public Citizen; and one 
private citizen, Mr. Thomas M. Kowalick. We note that letters were also 
received from the American Automobile Association (AAA) and 433 private 
citizens.
    In addition, the agency held ex parte meetings with AORC, the 
Alliance, Toyota, GM, Hyundai, and Mr. Kowalick.\3\ AORC, the Alliance, 
Toyota, GM, and Mr. Kowalick each explained their concerns and outlined 
their petitions for reconsideration. Hyundai asked for clarification of 
the provisions of the rule, but did not submit any information or 
requests for the agency to consider.
---------------------------------------------------------------------------

    \3\ NHTSA's records of these meetings are available at Docket 
No. NHTSA-2006-25666.
---------------------------------------------------------------------------

    The petitions and comments expressed concerns with the following 
general areas of the rule: event storage, data format, sensor accuracy 
and range, data survivability and retrievability, required data 
elements, lead time, and public privacy and notification. The sections 
below examine each topic in turn, discussing the petitions and 
explaining the agency's response.

A. Event Data Storage

    Petitioners' requests on storage of crash event data in EDRs 
involved three topics: Data storage in the case of multiple event 
scenarios, event recording intervals, and reusability of EDRs with 
``locked'' data.
1. Storage of Multiple Events
    AORC \4\ petitioned NHTSA to clarify the ``end of event'' criteria, 
arguing that as the final rule was written, the definition of multiple 
event storage and delta-V ``trigger threshold'' would allow the EDR to 
record overlapping or incomplete event data. It further argued that 
once the end of event criteria is reached, there is no further useful 
data to obtain. AORC also petitioned NHTSA to redefine the trigger 
threshold to limit the start of an event to ``a 150 ms interval, or the 
time since the most recent time zero, whichever is shorter,'' in order 
to avoid the EDR capturing non-events. Allowing the EDR to cease 
recording once the criteria is reached will conserve microprocessor 
resources, and prevent incomplete recording of subsequent significant 
events. AORC suggested that this would prevent the accumulation of 
multiple insignificant events (such as pothole events) that may have a 
net cumulative delta-V in excess of 8 km/h.
---------------------------------------------------------------------------

    \4\ Docket No. NHTSA-2006-25666-436.
---------------------------------------------------------------------------

    The Alliance \5\ petitioned NHTSA to rewrite Sec.  563.9 to clarify 
the criteria for overwriting data and to address the event data storage 
criteria for multiple events. The Alliance mentioned three specific 
concerns with Part 563's data capture provisions. First, the Alliance 
stated that the language contradicts itself by stating that air bag 
deployment data must be locked to prevent overwriting by a future 
event, while also requiring that all previous data be removed from the 
EDR with the occurrence of either a deployment or a non-deployment 
event. Second, the Alliance argued that the erasure requirement is not 
needed--if an EDR has two non-volatile buffers,\6\ only one of which is 
occupied with data from a previous event, the erasure requirement would 
reduce the amount of useful information held by the EDR and consume 
crucial processing time to perform. And third, the Alliance requested 
clarification as to what NHTSA meant by ``an air bag deployment 
crash,'' given the existence of other deployable restraints with lower 
deployment thresholds.
---------------------------------------------------------------------------

    \5\ Docket No. NHTSA-2006-25666-441.
    \6\ A non-volatile buffer temporarily stores data until the EDR 
is ready to receive or process it into semi-permanent memory. Many 
current technology EDRs do have two non-volatile buffers.
---------------------------------------------------------------------------

    The Alliance recommended that Sec.  563.9 be re-written as follows:

    ``The EDR must capture and record the data elements for events 
in accordance with the following conditions and circumstances:
    (a) In a frontal or side air bag deployment crash, capture and 
record the current deployment data, up to two events.
    (b) In a deployment event that involves another type of 
deployable restraint (e.g., pretensioners, knee bolsters, pedestrian 
protection, etc.), or in a non-deployment event that meets the 
trigger threshold, capture and record the current non-deployment 
data, up to two events, subject to the following conditions:
    (1) If an EDR non-volatile memory buffer void of previous-event 
data is available, the current non-deployment event data is recorded 
in the buffer.
    (2) If an EDR non-volatile memory buffer void of previous event 
data is not available, the manufacturer may choose to either 
overwrite the previous non-deployment event data with the current 
non-deployment event data, or to not record the current non-
deployment data.
    (3) EDR buffers containing previous deployment-event data must 
not be overwritten by the current non-deployment event data.''

The Alliance argued that this rewrite would clarify the apparent 
contradiction and ensure that NHTSA would receive the highest-interest 
event data.

[[Page 2171]]

Additionally, according to that petition, manufacturers would be able 
to prioritize the significance of non-deployment event data based on 
the varying deployment level thresholds for other restraint systems. 
Toyota \7\ supported the Alliance petition.
---------------------------------------------------------------------------

    \7\ Docket Nos. NHTSA-2006-25666-439 and -447.
---------------------------------------------------------------------------

    AIAM \8\ argued that although EDRs may be capable of recording 
multiple events, they may only do so if the external power source and 
sensors are not damaged in the first event, and petitioned the agency 
to clarify this. Nissan \9\ supported the AIAM petition.
---------------------------------------------------------------------------

    \8\ Docket No. NHTSA-2006-25666-442.
    \9\ Docket No. NHTSA-2006-25666-448.
---------------------------------------------------------------------------

    Agency response: We are granting the Alliance's petition to clarify 
Sec.  563.9, but we are not adopting its definition verbatim. The final 
rule required EDRs to record only two events. To ensure that air bag 
deployment events were properly recorded, the agency required that 
previous data be erased from memory buffers prior to recording the 
deployment event. The agency adopted the ``end of event'' definition in 
SAE J1698-1, Vehicle Event Data Interface--Output Data Definition 
(March 2005) to provide a distinction between when the first event had 
ended and the second event began.
    However, the erasure process consumes EDR system resources and 
time, which may be needed to record a closely-following second 
deployment event. In addition, during some multiple events, the timing 
of event triggers may appear to the EDR as one long event. This may 
cause the EDR to process and prioritize event data inappropriately.
    To address this problem, we are adopting most of the Alliance's 
recommended rewrite of Sec.  563.9. The EDR will be permitted to 
``overwrite'' rather than erase previous event data contained in the 
EDR memory buffers. The revised Sec.  563.9 will also clarify how the 
EDR must prioritize multiple events and events involving deployable 
restraint systems other than air bags. Finally, by allowing the EDR to 
overwrite data, the revision will also address the AORC concerns about 
multiple event timing and the potential for double buffering 
(unintentionally recording the same event twice) or recording of 
insignificant data. We are including a requirement that the data from 
an air bag deployment event remain locked,\10\ in order to discourage 
tampering. Thus, we are changing Sec.  563.9(a), to read:
---------------------------------------------------------------------------

    \10\ The meaning of ``locked'' is discussed below in section A3.

    (a) In a frontal or side air bag deployment crash, capture and 
record the current deployment data, up to two events. The memory for 
each air bag deployment event must be locked to prevent any future 
---------------------------------------------------------------------------
overwriting of these data.

    The revision also addresses AORC's concern about the trigger 
threshold, because the revised regulatory text permits the EDR 
algorithm to define on its own when the end of event has occurred. 
Thus, the EDR could capture the 150 ms pre-event interval in a new 
memory buffer, while ceasing to record the previous event. In this 
case, the full set of data from the deployment event would be captured, 
and the data from the prior event would be contained in a second memory 
buffer.
    We agree with AIAM that subsequent events need not be recorded if 
the external power source and sensors are damaged in the first event, 
but we do not believe that a change to the regulatory text is 
necessary. The regulation does not contain test requirements to 
determine if an EDR could survive two consecutive severe crashes. For 
the test requirements which are included, if an event is severe enough 
to interrupt the power source to the EDR, the EDR must be able to 
finish capturing that event, but is not required to be in a condition 
such that it could capture subsequent events.
2. Event Recording Intervals
    AORC petitioned NHTSA to clarify that an air bag deployment is 
itself a trigger, even in the absence of a delta-V trigger. AORC 
recommended modifying the definition for ``time zero'' to account for 
this, and to modify the definition of ``end of event'' to allow for 
both a delta-V end of event and air bag control unit reset.
    The Alliance also petitioned NHTSA to clarify that an air bag 
deployment is itself a trigger, and recommended modifying the 
definition of ``time zero'' and ``event'' accordingly. The Alliance 
argued that a strict reading of the existing ``event'' definition could 
preclude a manufacturer from recording cases in which an air bag 
deploys (due to shock to the vehicle) even though the trigger threshold 
was not exceeded. In these cases, it would be important to have EDR 
data to evaluate air bag performance.
    Toyota supported the Alliance petition and petitioned for 
clarification of the ``end of event'' definition. Toyota argued for a 
``judgment period'' of 30 ms to identify the actual end of the event in 
the case of a crash where the cumulative delta-V hovers near 0.8 km/h. 
The judgment period would enable the EDR to determine whether a true 
end of event has occurred, or whether the previous event has simply 
continued.
    AIAM stated that the delta-V recording intervals specified in 
Tables I and II do not agree with the final rule preamble. The maximum 
delta-V recording intervals in the tables are specified as 0-300 ms, 
but the preamble stated that NHTSA believed that a 250 ms recording 
time would be sufficient for 95 percent of the event cases. AIAM urged 
the agency to reconcile the language. Nissan supported the AIAM 
petition.
    Agency response: We are granting the petitions to clarify that an 
air bag deployment may be considered an event trigger by itself. In the 
final rule, the agency had decided not to adopt a recommendation to tie 
the trigger threshold to an air bag deployment because we believed that 
using a set delta-V trigger would better collect the type of 
information that the agency was most interested in, namely high delta-V 
crashes irrespective of air bag deployment. We were concerned that 
tying the trigger threshold to air bag deployment could result in 
different thresholds depending on manufacturer deployment strategies 
and vehicle platforms.
    We agree, however, that EDR data would be valuable in the case of 
events where an air bag was deployed and the trigger threshold was not 
met or exceeded. Including a reference to air bag deployment as a 
trigger by itself, while maintaining the delta-V trigger, is consistent 
with the agency's intent in the final rule. We are therefore modifying 
the definitions of ``event'' and ``time zero'' as follows:

    Event means a crash or other physical occurrence that causes the 
trigger threshold to be met or exceeded, or an air bag to be 
deployed, whichever occurs first.
    Time zero means whichever of the following occurs first:
    (a) For systems with ``wake-up'' air bag control systems, the 
time at which the occupant restraint control algorithm is activated; 
or
    (b) For continuously running algorithms,
    (i) The first point in the interval where a longitudinal 
cumulative delta-V of over 0.8 km/h (0.5 mph) is reached within a 20 
ms time period; or
    (ii) For vehicles that record ``delta-V, lateral,'' the first 
point in the interval where a lateral cumulative delta-V of over 0.8 
km/h (0.5 mph) is reached within a 5 ms time period; or
    (c) An air bag deployment.

Further, we are granting the petitions to clarify the ``end of event'' 
definition to allow the EDR to determine if an actual end of event has 
occurred. To address

[[Page 2172]]

the AORC and Toyota requests, we are modifying the definition as 
follows:

    End of event time means the moment at which the cumulative 
delta-V within a 20 ms time period becomes 0.8 km/h (0.5 mph) or 
less, or the moment at which the crash detection algorithm of the 
air bag control unit resets.
3. Reusability of EDRs
    AORC petitioned NHTSA to define the term ``locked'' so that the EDR 
itself could not overwrite event data, but so that external means could 
be used to erase data after download. They argued that in some cases, 
the EDR may be reusable after a deployment event, and allowing data to 
be erased would facilitate reuse.
    Agency response: We are denying this petition. We do not believe 
that reuse of the EDR is a sufficient reason to allow its erasure by 
external means. If we allowed the EDR to be erased by external means, 
it could encourage development of tools to erase EDR data potentially 
beneficial to our programs, and would make it difficult to ensure that 
this feature was not being misused. Although the final rule did not 
define the term ``locked,'' we consider it to mean to protect EDR data 
from changes or deletion. This would include by external means.

B. Data Format

``Recording'' versus ``Reporting'' data:

    Several petitioners argued that the title of Table III should be 
changed from ``Recorded Data Format'' to ``Reported Data Format,'' 
essentially because differences in EDRs may cause them to record data 
differently, and requiring identical recording capabilities could be 
more onerous than the agency likely intended. AORC argued that it 
appears that post processing of data collected from an EDR is 
allowable, and that the title of Table III should be changed to 
``Reported Data Format'' to clarify this point. Along those lines, AORC 
petitioned that the ``resolution'' column in Table III be changed to 
``Reported Format,'' and that NHTSA clarify that the actual sensor 
resolution may differ from the reported format.
    The Alliance stated that SAE J1698 and J1698-1 provide guidelines 
for reporting EDR data, not recording EDR data. In support, the 
Alliance cited the scope of SAE J1698, which states:

    This recommended practice aims to establish a common output 
format of crash-related data recorded and stored within certain 
electronic components currently installed in many light-duty 
vehicles. This recommended practice pertains only to the post-
download format of such data and is not intended to standardize the 
format of the data stored within any on-board storage unit, or to 
standardize the method of data recording, storage, or extraction.''

Therefore, the Alliance petitioned that Sec.  563.8(a) be revised to 
read ``The data elements listed in Tables I and II, as applicable, must 
be reported in accordance with the range, accuracy, resolution, and 
filter class specified in Table III.'' It further requested that the 
title of Table III be changed to ``Reporting Data Element Format.'' 
Toyota supported the Alliance petition.
    Agency response: We are granting these petitions. In the final 
rule, the agency expressed its intent to specify recording requirements 
identical to or less stringent than those found in SAE J1698. As the 
Alliance noted, that standard was intended for the purpose of 
``reporting'' EDR data, not ``recording'' it. To remedy this oversight 
in the final rule, we are revising the title of Table III to ``Reported 
Data Element Format,'' and revising Sec.  563.8(a) as follows:

    (a) The data elements listed in Tables I and II, as applicable, 
must be reported in accordance with the range, accuracy, and 
resolution specified in Table III.

We are not changing the ``resolution'' column title as requested by 
AORC, because the revised Table III title should sufficiently address 
their concerns.
SAE J211-1 Filter Class
    The AORC petitioned NHTSA to remove the SAE J211-1 Class 60 filter 
class from the final rule, because it applies to vehicle 
instrumentation in laboratory tests and may be inconsistent with some 
of the data collected by EDRs. The Alliance also petitioned to remove 
the SAE J211-1 filter class from Table III, because component suppliers 
typically incorporate their own filtering techniques into the 
acceleration data acquisition hardware, and an additional filtering 
requirement may cause data processing issues for EDRs.
    Agency response: We are granting these petitions. NHTSA included 
the SAE J211-1 filter class in the final rule to ease comparison of 
data collected from EDRs with data collected during agency crash tests. 
Data filters are used to eliminate noise from sensor signals and 
extract the useful data. We believed that by specifying the same filter 
class used during agency crash tests, EDRs would provide information 
more readily comparable to the data collected by instruments used 
during our crash tests. It also allowed comparison amongst EDRs from 
different manufacturers. However, in ex parte meetings with AORC, the 
Alliance, AIAM, and Toyota,\11\ the petitioners presented additional 
material indicating that current EDRs contain internal filtering 
capability. Additional filtering of the already-filtered data could 
remove useful signal content, and could result in attenuation or phase 
shifting of the data. Based on this information, we are removing the 
SAE J211-1 filter class requirement from Sec.  563.8(a) and the 
corresponding column from Table III.
---------------------------------------------------------------------------

    \11\ See Docket No. NHTSA 2006-25666 for the records of these 
meetings.
---------------------------------------------------------------------------

Requirements for Particular Data Elements
    The Alliance petitioned NHTSA to revise the resolution requirement 
in Table III for acceleration data to ``the range of the sensor divided 
by the number of available states in one byte.'' In this manner, a 100 
g sensor ( 50 g) would have a resolution of 0.39 g (100 g/
255).\12\ The Alliance argued that the accelerometers required in crash 
testing (capable of measuring at a 0.01 g resolution) are not of the 
type employed in EDRs. Such accelerometers would double the EDR memory 
requirements and increase sensor cost, with no apparent benefit.
---------------------------------------------------------------------------

    \12\ There are 255 states in one byte of memory. One byte is 
equal to 2\8\ (256) bits. The number of states in each byte is equal 
to the number of bits minus 1 (256-1 = 255).
---------------------------------------------------------------------------

    The Alliance also petitioned NHTSA to revise the recording interval 
from 250 to 70 ms from time zero, and allow a range of sampling rates 
from 100 to 500 Hz, to prevent the need for upgraded accelerometers and 
requisite memory with no added benefit. It argued that some 
accelerometers sample at rates as low as 100 Hz, compared to the 500 Hz 
rate specified in Table II, and that many EDRs record acceleration data 
for only 50-70 ms from time zero, compared to the 250 ms requirement in 
the final rule.
    Toyota also recommended that the agency change the time interval 
for delta-V data to ``0-250 ms or 0-End of Event Time plus 30 ms, 
whichever is shorter.'' Likewise, Toyota recommended changing the time 
interval for maximum delta-V to ``0-300 ms or 0-End of Event Time plus 
30 ms, whichever is shorter.''
    AIAM also addressed the issue of the time interval for maximum 
delta-V data. It argued that the time interval specified in Table III 
was not in agreement with the preamble, and petitioned that the agency 
specify in Table III that the maximum delta-V time interval was 0-250 
ms.
    AIAM also stated that the final rule did not provide a method for 
verifying the format of the data elements, and that it was therefore 
unclear how the agency

[[Page 2173]]

intended the accuracy criterion to be applied. AIAM requested that the 
agency provide a procedure for determining Table III data element 
accuracy, range, and resolution verification.
    Nissan \13\ supported the AIAM petition with regard to recorded 
data format, and also recommended that the agency revise the 
acceleration data element resolution from 0.01 g to 0.5 g.
---------------------------------------------------------------------------

    \13\ Docket No. NHTSA-2006-25666-448.
---------------------------------------------------------------------------

    Agency response: We are granting the petitions regarding the 
resolution capability required for accelerometers in the final rule, 
because we recognize that current technology accelerometers used in 
EDRs are not, in fact, able to meet the resolution requirement in Table 
III. As discussed above, this stems in part from the agency's 
substituting ``Recording'' for ``Reporting'' format in our attempts to 
align the EDR regulation with the standard industry practice of SAE 
J1698. The 0.01 g acceleration data resolution specified in Table III 
would require manufacturers to add additional memory to the EDR and 
upgrade the accelerometers to laboratory-grade reference 
accelerometers.\14\ Data submitted by the Alliance,\15\ AORC,\16\ and 
Toyota\17\ indicate that there would be no significant loss in 
acceleration data quality if accelerometer accuracy and resolution were 
revised to 0.5 g. Since the agency intended for the EDR rule to have a 
low cost impact, and since the data quality will not be significantly 
reduced, we are changing the resolution for acceleration data elements 
in Table III to 0.5 g.
---------------------------------------------------------------------------

    \14\ The AORC reported that current air bag control units use 8-
10 bit acceleration data resolution, whereas laboratory-grade 
reference accelerometers use 14-16 bit resolution to achieve a 0.01 
g resolution. See Docket No. NHTSA-2006-25666-436.
    \15\ See Docket No. NHTSA-2006-25666-441.
    \16\ See Docket No. NHTSA-2006-25666-436.
    \17\ See Docket No. NHTSA-2006-25666-447.
---------------------------------------------------------------------------

    For similar reasons, we are granting the petitions to amend the 
minimum output for the accelerometer ranges. If acceleration is 
recorded, it must be included in the EDR output and reported in the 
minimum format specified in Table III. In meetings with the agency, the 
Alliance and Toyota argued that the sampling rate was too high for many 
accelerometers, and would raise EDR manufacturing costs by requiring up 
to five times the memory storage capacity currently common for EDRs. 
NHTSA intended to maintain a low cost impact as part of the final rule, 
but also intended to standardize EDR output data. Consequently, we are 
amending the minimum data sampling requirements for EDR accelerometer 
data from 500 Hz to 100 Hz, and are also amending the accelerometer 
data minimum formats in Table III to reflect the typical acceleration 
ranges recorded by the accelerometer components.
    Regarding the issue of maximum delta-V interval times, we are 
granting the petition to change the data format in Table III to reflect 
the new time interval changes. NHTSA is adopting Toyota's suggestion of 
setting the time interval for the delta-V elements as ``0-250 ms or 0-
End of Event Time plus 30 ms, whichever is shorter,'' and for maximum 
delta-V, ``0-300 ms or 0-End of Event Time plus 30 ms, whichever is 
shorter.'' This will also partially address the AIAM concern about the 
maximum delta-V interval times in Table III. We do not agree that the 
maximum delta-V interval time need match that of the other delta-V 
elements, because in some cases, the resultant maximum delta-V may be 
achieved after the initial 250 ms time interval. However, the revisions 
allow a shorter time interval for maximum delta-V if the EDR decides 
that the event has ended and seeks to reset the event time clock.
    We are denying AIAM's request for a verification method for Table 
III data elements. The agency will verify the data based on the above 
revisions to Table III and standard laboratory procedures. Standard 
laboratory procedures would include instrumentation that is traceable 
to a standard reference and calibrated to a degree of accuracy that is 
better than the device being tested to verify that the test device is 
measuring properly. Therefore, when the EDR data is downloaded, the 
data from the reference accelerometer would verify that the EDR 
measured the crash pulse accurately.

C. Sensor Accuracy and Range

1. Sensor Accuracy
    AORC petitioned the agency to widen the tolerance for recorded 
delta-V and the underlying accelerometers from 5% to 8%. It argued that standard accuracy for accelerometers currently 
utilized for air bag control units ranges from 5% to 10%. They further argued that factors such as misalignment and 
digitization errors contribute to sensor inaccuracy and necessitate the 
wider sensor tolerance. AIAM also petitioned for a wider tolerance of 
10% for the accelerometer and delta-V data elements.
    The Alliance and Toyota petitioned the agency to remove the 
acceleration data elements entirely from the final rule, arguing that 
such data can be derived from the delta-V and event time data elements. 
If the agency decided to retain the acceleration data elements, 
however, the Alliance and Toyota requested that the tolerance for 
acceleration data and delta-V data be increased to 10%. 
Delphi petitioned the agency to eliminate the range and accuracy 
requirements on all inertially-sensed data elements (e.g., acceleration 
and angular rate), recommending that the agency instead add data 
elements that indicate the actual range and accuracy characteristics of 
the inertial parameters included in the record.
    The Alliance also petitioned the agency to clarify that 
accelerometer accuracy is calibrated in comparison with a laboratory 
grade sensor, and that decreased accelerometer accuracy is allowed in 
the event of sensor saturation, arguing that accelerometers can lose 
signal accuracy in certain cases when they experience forces beyond 
their capability to measure. AORC petitioned that NHTSA specify the 
temperature conditions when measuring accelerometer accuracy, and that 
the tolerances apply only within the range of the sensors used in the 
application and data derived from those signals. Like the Alliance, 
AORC stated that signals that exceed the range of the sensor may result 
in clipping of the data, which can affect the overall accuracy of the 
delta-V calculation.
    Agency response: We are granting the petitions to widen the 
tolerance on accelerometer and delta-V accuracy, but denying the 
petitions to remove acceleration data elements from the final rule. In 
the final rule, the agency noted that acceleration is a common data 
element collected in engineering studies and crash tests to determine 
crash severity and the shape of the crash pulse in frontal and rear 
crashes. Therefore, we believe it is appropriate to standardize 
acceleration data captured by EDRs. However, error source data 
submitted after the final rule by the Alliance, AORC, and Toyota \18\ 
indicate that current technology EDR accelerometers have lower 
accuracies than NHTSA previously believed, near 10%. If we 
maintain the requirement in the final rule, costs would be imposed 
beyond what we had analyzed and intended. For these reasons, we are 
revising the tolerance for accelerometer accuracy to 10% in 
order to accommodate current technology EDR accelerometers. Similarly, 
because delta-V data is derived from acceleration data, it cannot be 
more accurate than the acceleration measurements, so we are revising 
the delta-V tolerance to 10% as well.
---------------------------------------------------------------------------

    \18\ See supra notes 17-19.

---------------------------------------------------------------------------

[[Page 2174]]

    We are denying the petitions to modify the final rule to allow 
additional EDR inaccuracy due to sensor saturation or data clipping. 
NHTSA recognizes that in certain rare extreme crash scenarios, the 
crash pulse may exceed the sensor detection capacity and result in data 
saturation, even in sensors that have been optimized for their given 
purpose. In these situations, the crash pulse may cause additional 
reported data inaccuracy or clipping; however, by doubling the 
tolerance on the accelerometer data, we believe this has been 
sufficiently addressed.
    We also believe it is unnecessary to specify how accelerometers 
should be calibrated. To a certain extent, accelerometers will be 
calibrated when NHTSA crash tests the vehicle. The reference 
accelerometer used during the test will indicate whether the 
accelerations reported by the EDR are within 10% of the 
reference accelerometer. Additionally, we believe that the 
manufacturers' interest in guaranteeing that the delta-V calculation 
made by the vehicle is accurate will ensure that accelerometers are 
properly calibrated in the first place. If the acceleration is off by 
too much, the delta-V calculated may be off and the air bag may not 
fire at the appropriate time in the crash test. However, because each 
manufacturer may have a different strategy for placement of sensors and 
for normalization of the data from those sensors to make a deployment 
decision, there may be many different ways to achieve that necessary 
accuracy, and we have no interest in requiring a single method simply 
for purposes of this rulemaking.
2. Sensor Range
    AORC petitioned NHTSA to clarify that the 50 g 
accelerometer range is a minimum range for post-download data output 
format only, and to add a footnote to the ``Range'' column in Table III 
denoting that actual sensor range may differ from table values for 
crash performance reasons. It argued that the 50 g range is 
too wide for lateral and vertical sensors and too narrow for 
longitudinal sensors, and requested that NHTSA allow higher range 
longitudinal accelerometers and narrower range lateral and vertical 
accelerometers provided that the output format is 50 g at a 
minimum. The Alliance also argued that lateral accelerometers used for 
rollover mitigation and electronic stability control systems do not 
have the same range as frontal crash accelerometers, and are more 
likely to be 2 to 5 g full-scale than 50 g.
    AIAM petitioned NHTSA to allow delta-V calculation errors due to 
accelerometer data truncation to the 50 g range, and to 
specify that the acceleration data element ranges in Table III are 
minimum ranges. AIAM argued that in certain severe crashes, the 
longitudinal acceleration component may be higher than the 50 g range specified in Table III. Thus, in those cases, the 
acceleration value recorded by the EDR would be truncated at 50 g and 
the resultant delta-V calculation might not meet the accuracy specified 
in section 563.
    AIAM also stated that current EDR designs could include 
accelerometers with ranges as low as 30 g to measure some 
longitudinal and lateral acceleration components, and as low as 1 g to measure normal (vertical) acceleration components. AIAM 
petitioned NHTSA to modify the acceleration ranges specified in the 
final rule to accommodate current EDR designs, and to allow alternative 
ranges for lateral and vertical accelerometers. Nissan supported the 
AIAM petition.
    Agency response: As discussed in Section III.B above, we are 
modifying the specified accelerometer ranges to be ``reported'' and not 
``recorded.'' We believe this will resolve the concerns expressed by 
the petitioners. Additionally, based on the comments and agency 
research, we recognize that the ranges specified for acceleration data 
elements may not be appropriate for sensors optimized for specific 
roles. Whereas longitudinal accelerometers may well measure data over 
the full range of 50 g, lateral and normal accelerometers 
might be optimized to measure data over only a fraction of that range, 
because vehicles simply do not typically experience the kinds of 
lateral and normal acceleration as they do longitudinal acceleration. 
To clarify the issue, we are granting the petition to specify that the 
ranges are reported minimums such that alternative sensing ranges are 
permitted, and we are specifying minimum reporting ranges of 5 g for the lateral and normal accelerometer data elements 
consistent with current technology practices.

D. Data Survivability and Retrievability

    The Alliance argued that for the purpose of determining compliance, 
NHTSA should clarify in the regulatory text that the EDR is restored to 
and stabilized at the conditions during the FMVSS No. 208 crash test 
procedure. Thus, it petitioned the agency to specify environmental 
conditions for the time period prior to data download for compliance 
purposes; namely, that the vehicles be kept dry and at a temperature 
during download that has been maintained at 66--78 [deg]F prior to any 
read-out being used to assess compliance.
    AIAM also petitioned that NHTSA specify that vehicles must be 
stored and protected from extreme environmental conditions (temperature 
or precipitation) prior to data download during EDR compliance 
assessment. AIAM argued that although a 10-day data storage requirement 
is reasonable, a crash test vehicle left unprotected from severe 
elements for 10 days could experience data loss. Nissan supported the 
AIAM petition.
    Public Citizen, on the other hand, reiterated the position it 
stated in its comments to the NPRM that the agency should specify more 
extreme survivability requirements for EDR data. It argued that fatal 
crashes include ones resulting in fires and fluid immersion, and that 
EDR data from those crashes are essential to NHTSA researchers in fully 
reconstructing crashes and developing more comprehensive safety 
standards. Public Citizen also petitioned that NHTSA require EDRs to 
meet survivability standards for crash events at speeds higher than 50 
mph. It argued that the final rule as written neglects higher speed, 
rear impact, and rollover crash tests.
    Agency response: We are denying the petitions to shelter crashed 
vehicles to protect them from environmental conditions for the 10-day 
survivability period, or to stabilize them at room temperature for 24 
hours prior to data download for compliance purposes. NHTSA's 
experience does not indicate that this should be a problem for 
compliance. We recognize that during the compliance tests, the vehicle 
glazing components may become damaged and could expose EDR modules to 
precipitation. However, this routinely happens to vehicles in the real 
world. Crashed vehicles stored in a tow yard are typically only 
minimally protected from environmental conditions, yet NHTSA has been 
successful in downloading data from nearly 5,000 vehicles to date. We 
believe that the vast majority of EDRs available today can maintain 
crash data for 10 days after the event despite adverse weather 
conditions, and are therefore denying these requests.
    Additionally, we are denying the petitions to increase the 
survivability requirements to include data retrievability after high-
speed (above 50 mph) and extreme fire and fluid immersion crashes. As 
we stated regarding fire and fluid immersion crashes in the final rule,


[[Page 2175]]


    In the NPRM,\19\ we stated that EDR data from such crashes might 
be useful, but we do not have sufficient information to propose 
survivability requirements that would address such crashes. We also 
stated that countermeasures that would ensure the survivability of 
EDR data in fires might be costly. We have not engaged in research 
to promulgate survivability requirements for EDR data in these 
extreme cases. Moreover, we reiterate that the most important 
benefits of EDR data comes from enabling ACN and composite analysis, 
and we believe that this final rule will allow researchers to gather 
sufficient EDR data of statistical significance. We believe that we 
can meet the objectives of this rulemaking without requiring EDR 
survivability in extreme crashes.\20\
---------------------------------------------------------------------------

    \19\ 69 FR 32943 (Jun. 14, 2004).
    \20\ 71 FR 51024 (Aug. 28, 2006).

Public Citizen provided no additional data in its petition to 
contradict our continued belief that the rule as written will allow 
researchers to gather enough EDR data of statistical significance. As 
explained, we believe that requiring such extreme survivability is 
---------------------------------------------------------------------------
unnecessary given the objectives of this rulemaking.

    As for high speed crashes, the agency has specified that compliance 
tests will be conducted in conjunction with FMVSS Nos. 208 and 214, 
which ensures that reliable information about severe crashes will be 
preserved while minimizing the rule's potential cost impact. We note 
that the FMVSS No. 208 crash tests are now performed at speeds of up to 
56 km/h (35 mph), which represent the cumulative delta-V for 99% of 
frontal crashes.\21\
---------------------------------------------------------------------------

    \21\ See Docket No. NHTSA-2006-26555-1, at 60.
---------------------------------------------------------------------------

    We disagree that the final rule neglects rear impact or rollover 
crashes. The final rule standardizes lateral acceleration, longitudinal 
acceleration, and vehicle roll angle data elements recorded by EDRs. We 
note that many manufacturers are already utilizing rollover sensors as 
part of their side curtain air bag systems. However, not all 
manufacturers have rollover systems installed in their fleets, or 
capture rollover data. Therefore, NHTSA does not believe that it is 
necessary at this time to require EDRs to record, for example, lateral 
acceleration or vehicle roll angle, at the risk of increasing the costs 
associated with installing EDRs in vehicles.
    As for rear impact crashes, the final rule's definition of trigger 
threshold uses an absolute value, rather than specifying that 
deceleration or acceleration should be a trigger.\22\ Through vehicle 
symmetry, longitudinal accelerometers will capture rear impact data the 
same as frontal impact data. Therefore, we believe that rear impact 
crashes will be covered just as well as frontal impact crashes.
---------------------------------------------------------------------------

    \22\ A vehicle will decelerate rapidly in a frontal crash, and 
accelerate rapidly in a rear-impact crash.
---------------------------------------------------------------------------

E. Required Data Elements

1. Peripheral Sensors
    AORC petitioned to exclude peripheral sensors from the scope of the 
final rule. It argued that state-of-the-art EDRs utilize peripheral 
sensors which may be positioned in the crushable zone of a vehicle and 
may not survive the entire crash. AORC further argued that it believes 
the agency intended EDRs to capture ``rigid body'' data for event 
reconstruction, and that sensors located in the crushable zones of 
vehicles may not meet the requirements of the final rule.
    The Alliance also petitioned to exclude satellite sensors from the 
scope of the final rule. It stated that satellite sensors may be 
optimized for functions unrelated to EDRs and crash investigations, and 
have ranges and tolerances that are radically different than those 
specified in the final rule. The Alliance argued that accelerometers 
located in the air bag control modules, closer to the vehicle center of 
gravity, provide a more accurate indication of actual rigid-body 
acceleration.
    Delphi expressed concern that some data elements in Table I \23\ 
may not be available to the EDR in vehicles with functionally 
independent, non-interconnected subsystems in severe crash scenarios. 
Delphi suggested that manufacturers may not include EDRs in vehicles if 
they are required to record these data elements. Therefore, Delphi 
petitioned NHTSA to consider an exception to certain Table I elements 
if those data sets are not available to the EDR.
---------------------------------------------------------------------------

    \23\ E.g., vehicle speed indicated, % engine throttle, and 
service brake indicator.
---------------------------------------------------------------------------

    Agency response: We are granting the petitions with regard to 
satellite or peripheral sensors, although we believe it is unnecessary 
to change the regulatory text to make this clarification. In the final 
rule, the agency expressed its intent for the EDR to capture the rigid 
body motion of vehicles in crashes. As the petitioners noted, the rigid 
body motion is best captured by collecting data centrally located in 
the occupant compartment of the vehicle. Data from satellite or 
peripheral sensors are not used for these purposes, but rather help the 
air bag control module and other occupant protection systems to perform 
optimally. We recognize that sensors located in vehicles' crushable 
zones may not meet the survivability standards set forth in the final 
rule, and therefore exclude them from those standards.
    However, we are denying Delphi's petition to exempt data elements 
from Table I if those data sets are not available to the EDR. While 
NHTSA recognizes that it may save EDR development costs to utilize 
sensor systems currently in place, we believe that the EDR should be 
capable of recording data from these systems for the interval times 
specified in the final rule. The sensor systems identified by Delphi as 
examples of ``functionally independent, non-interconnected subsystems'' 
are all data elements of primary interest to NHTSA in determining the 
pre-crash conditions, and therefore would likely still be available to 
the EDR. Further, the agency believes that the crash scenarios in which 
these systems may become disconnected, and thus no longer available to 
the EDR, would involve extremely severe or rare conditions that are not 
of interest to the agency at this time for practical reasons. The 
compliance test procedures specified in the final rule do not recreate 
such extreme conditions, so data from these subsystems would still be 
available for compliance purposes.
2. Steering Input and Wheel Angle
    AORC stated that the ``steering input'' data element in Table II 
appears to be equivalent to the ``steering wheel angle'' data element 
in Table III. AORC additionally petitioned that NHTSA specify that 
Table II steering input and wheel angle tolerance values are minimums, 
and that there is no need to truncate the data to fit the Table III 
format. AORC also requested that the Table III accuracy for steering 
wheel angle be changed to a percent of the full scale rather than a 
fixed angle tolerance.
    Agency response: We are granting these requests as technical 
amendments. When the final rule was drafted, NHTSA believed that the 
steering angle during an event would rarely exceed 250 
degrees from the normal position. AORC explained in subsequent meetings 
that state-of-the-art EDRs in fact report steering wheel accuracy in 
terms of a percent of the full scale, and that there is therefore no 
need to limit the steering input data element to the 250 
degree range. Changing the format of how the steering input data is 
reported is simply a technical change, and will not substantively 
change the type of data collected for the agency's research purposes. 
This response to petitions changes the steering wheel angle accuracy in 
Table III from 5 degrees to 5 percent, and 
changes the resolution from 5 degrees to 1 percent.

[[Page 2176]]

The steering input data element of Table II has also been specified 
under minimum conditions. Additionally, we agree that the terms 
steering input and steering wheel angle refer to the same thing, and 
are changing ``steering wheel angle'' in Table III to ``steering 
input'' for purposes of consistency.
3. Vehicle Roll Angle Accuracy
    AORC argued that the typical accuracy for state-of-the-art roll 
angle sensors is about 7%, and petitioned that the agency measure that 
accuracy as a percent of the full sensor range rather than as a fixed 
roll angle. AORC further requested that the EDR should only be required 
to store the roll angle data element up to the deployment of the air 
bag, and that the accuracy requirement only apply within the range of 
the sensors used in the application and at room temperature.
    Agency response: We are granting the petition with regard to roll 
angle accuracy being measured as a percent of the full sensor range, 
but denying the request that the EDR should only be required to store 
roll angle data up to the deployment of the air bag and that the 
accuracy need only apply at room temperature. As discussed above, we 
are revising the acceleration accuracies in Table III to 10%. We believe that the inertial sensors utilized in roll angle 
sensor systems will exhibit similar accuracy traits, and should be 
measured as a percent of the full range of the sensor.
    We believe there is no need to limit collection of roll angle 
sensor data to the time interval prior to air bag deployment. As 
footnoted in Table II, the recording interval is a suggested period 
only. This is because the agency recognized the potential for 
misalignment of sensors and consequent loss of accuracy due to vehicle 
damage during a rollover event. NHTSA would not consider it non-
compliant if an EDR was unable to collect roll angle sensor data for 
the full recording interval; therefore, an additional limit to the 
recording interval is not necessary.
4. Data Element Definitions
(a) Definition of Time to Maximum Delta-V Resultant
    AORC stated that it believes that the ``resultant'' maximum delta-V 
means the magnitude of the vector-added longitudinal and lateral 
maximum delta-V, and that this value can be processed during the data 
downloading procedure. AORC petitioned NHTSA to define ``Time, Max 
Delta-V Resultant'' in Sec.  563.5.
    Agency response: We are granting the petition to define ``Time, 
Maximum Delta-V Resultant,'' and are also defining ``Maximum Delta-V 
Resultant'' for clarification. These changes clarify the regulatory 
text and are technical in nature, having no effect on the substantive 
requirements of the rule. The new definitions will be added to Sec.  
563.5 as follows:

    Maximum delta-V, resultant means the time-correlated maximum 
value of the cumulative change in velocity, as recorded by the EDR 
or processed during data download, along the vector-added 
longitudinal and lateral axes.
    Time, maximum delta-V resultant means the time from crash time 
zero to the point where the maximum delta-V resultant occurs, as 
recorded by the EDR or processed during data download.
(b) Clarification of Engine RPM Definitions
    The Alliance petitioned the agency to revise the Engine RPM 
definition to include hybrid vehicles with one or more drive systems. 
It recommended that the measurement point be moved to the point of 
entry to the transmission gearbox.
    Agency response: We are granting this petition for clarity's sake. 
For hybrid and other vehicles not entirely powered by internal 
combustion engines, when the vehicle is running on a power system other 
than the internal combustion engine, the engine RPM data element would 
not be utilized. However, as the Alliance noted, the operating speed of 
the engine or motor of a hybrid vehicle could be measured from the 
transmission. This clarification is technical in nature and will have 
no effect on the substantive requirements of the final rule. NHTSA is 
redefining engine RPM as follows:

    Engine RPM means, for vehicles powered by internal combustion 
engines, the number of revolutions per minute of the main crankshaft 
of the vehicle's engine, and for vehicles not entirely powered by 
internal combustion engines, the number of revolutions per minute of 
the motor shaft at the point at which it enters the vehicle 
transmission gearbox.

Additionally, since some electric and fuel cell vehicles may not have 
transmissions at all, for these vehicles, we believe it would be 
appropriate for the EDR to record output of the vehicle power plant. We 
do not plan to address this in the regulatory text until a significant 
number of these vehicles are produced.
(c) Clarification of Readiness Indicator Lamp
    The Alliance petitioned NHTSA to either delete the Table I data 
element ``frontal air bag warning lamp'' or change that data element to 
``Readiness Indicator Lamp.'' It suggested that the readiness indicator 
lamp as described in FMVSS No. 208 (S4.5.2) is the data element that 
NHTSA intended for EDRs to record. The Alliance argued that the name 
should be changed for accuracy's sake, since the readiness indicator 
may illuminate to indicate a malfunction in many parts of the restraint 
system besides the frontal air bag, including the seat belt 
pretensioners, the passenger seat weight sensors, the side impact 
sensors, the curtain air bag modules, and so forth.
    AIAM also petitioned to clarify that the ``readiness indicator'' 
referred to the indicator specified in S4.5.2 of FMVSS No. 208. It 
recommended that the EDR record the status of the safety system as a 
whole, and not simply whether or not the readiness indicator lamp is 
illuminated. AIAM further petitioned that NHTSA confirm that the EDR 
may record additional safety system readiness information, such as the 
state of side air bag systems. Nissan supported the AIAM petition.
    Agency response: We are granting the petitions on this issue in 
part. In its meeting with the agency, the Alliance reported that the 
readiness indicator may also illuminate to indicate a malfunction in 
the restraint system other than a frontal air bag. For example, the 
indicator may illuminate if a malfunction is detected in a side curtain 
air bag, or in a deployable seat belt pretensioner. The agency did not 
intend to require by the final rule that readiness indicator lamps be 
used only for the frontal air bag; we agree that it may also indicate 
malfunctions in other parts of the restraint system.\24\ We are adding 
a clarifying footnote to Table I corresponding to ``Frontal air bag 
warning lamp, on/off'' as follows:
---------------------------------------------------------------------------

    \24\ We have previously confirmed this by interpretation. See 
Letter to Michael Love, Porsche Cars North America, Inc., Jul. 30, 
1996. Available at https://isearch.nhtsa.gov/files/PORSCH3.wpd.html 
(last accessed Oct. 5, 2007).

    \2\ The frontal air bag warning lamp is the readiness indicator 
specified in S4.5.2 of FMVSS No. 208.
5. Whether the Suppression Switch ``Auto'' Data Element in Table II 
Should Be Retained
    The Alliance petitioned NHTSA to remove the frontal air bag 
suppression switch ``auto'' data element from Table II. It argued that 
the air bag system can be deactivated through numerous methods, and is 
either on or off at the time of the event (i.e., it would not be 
``auto''). The Alliance stated that an EDR that records ``auto'' would 
not seem to answer an end-user inquiry as to why an air bag did or did 
not deploy.

[[Page 2177]]

    Agency response: We are denying this petition. Recording the 
position of the air bag suppression switch, even if it is in the 
``auto'' position, may help the agency in determining whether advanced 
air bag systems with automatic suppression systems are performing 
properly. Given that this falls within the scope of the rulemaking's 
intent, we are not granting this petition. For clarity, we are also 
making a technical correction to Table III to reflect that the ``auto'' 
option in the reported data element format be for the frontal air bag 
suppression switch status.
6. Whether the ``Vehicle Speed Indicated'' Data Element in Table III Is 
Feasible
    AIAM petitioned NHTSA to revise the vehicle speed data element 
accuracy to 10 km/h, arguing that the listed accuracy 
requirement in Table III of the final rule is not feasible. However, 
AIAM suggested that if the agency's intent was to specify a 1 km/h resolution for data reporting purposes only, the data 
element would not be problematic. Nissan supported the AIAM petition.
    Agency response: We are denying this petition. While variations in 
tire and rim sizes may introduce additional inac