[Federal Register Volume 73, Number 9 (Monday, January 14, 2008)]
[Rules and Regulations]
[Pages 2168-2184]
From the Federal Register Online via the Government Publishing 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 http://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 inaccuracy in the vehicle
speed indicated, we do not believe that the indicated speed will have
an inaccuracy as high as 10 km/h (approximately 6 mph) outside of wheel slippage due to road surface conditions.
However, we agree with the petitioner that the agency's intent was to
specify a 1 km/h resolution for data reporting purposes
only. Since revisions are already being made to the title of Table III
and to Sec. 563.8(a) to specify that the data element formats are
reporting, not recording formats, we are not changing the ``vehicle
speed indicated'' data element.
7. Whether Additional Data Elements Should Be Included
Public Citizen noted that the number of required data elements in
the final rule was reduced from the number in the NPRM, and reiterated
its position stated in its comments to the NPRM that NHTSA should
include more required data elements for EDRs. Specifically, Public
Citizen requested that NHTSA reconsider data elements listed by the
NHTSA-sponsored EDR working group and an IEEE EDR case report. It also
cited VIN, crash location, and a date/time stamp data element as
elements missing from the agency's final rule.
Agency response: We are denying this petition. We note that the
agency discussed at length in the final rule the reasons for its
inclusion/exclusion of various data elements, including the ones cited
by Public Citizen. See 71 FR at 51011-51016. We continue to believe
that the additional elements cited by Public Citizen are not needed for
the agency's basic goals for this rulemaking, including crash
reconstruction purposes.
We note that the vehicle VIN does not need to be a required data
element, since that information is already required to download data
from the EDR.\25\ The crash location, date and time need not be
required elements, since they are included in accident investigation
reports. Also, if crash location was required, installation of global
positioning sensors would be needed, drastically increasing the costs
of EDRs contrary to the agency's intent in this rulemaking. As for our
denial of Public Citizen's petition to include all of the data elements
listed in the IEEE report, Public Citizen provided no new information
or arguments on this subject in its petition for reconsideration than
it provided in its comments to the NPRM. In the final rule, we
explained that the IEEE data element list was more like a ``data
dictionary'' than a list of actually recommended data elements to be
recorded. Requiring all of the IEEE-listed data elements would result
in redundancy and the unnecessary standardization of many data elements
that are unrelated to the purposes of this rulemaking.
---------------------------------------------------------------------------
\25\ Similar EDR architecture may be used for different models
in a manufacturer's line of vehicles. The VIN must be inputted so
that the EDR software can know what vehicle model it is installed
in, so that it can interpret the data it has recorded in light of
the specific parameters of the vehicle model.
---------------------------------------------------------------------------
F. Lead Time
The Alliance petitioned NHTSA to change the compliance date set of
the final rule. It argued that the final rule will likely require
manufacturers to redesign EDRs and electrical architectures in
virtually all vehicles covered by the regulation, and that it is
impractical to implement these product changes across the entire fleet
of vehicles by the September 1, 2010 compliance date. The Alliance
instead recommended that the agency either delay the effective date or
implement a phase-in schedule. It recommended a phase-in schedule of
25% for MY 2011, 50% for MY 2012, 75% for MY 2013, and 100% compliance
thereafter.
AIAM also argued that significant redesigns may be required for
manufacturers to comply with the final rule, and requested a later
compliance date. It recommended a phase-in schedule of 50% for MY 2011,
80% for MY 2012, and 100% for MY 2013, with advance credits for early
adoption.
Agency response: At the time of the final rule, we believed that
the September 1, 2010 effective date would have little impact on the
manufacturers. We note that much of the EDR data available to the
agency has been from GM vehicles, and that there are few differences
between the data sets collected from those vehicles and the minimum
requirements of the final rule.
However, in connection with the petitions for reconsideration,
manufacturers have submitted information that even with the reduced
number of required data elements included in the final rule, industry
will still need to make architecture changes that will extend the lead
time beyond September 1, 2010 for new EDRs that comply with the final
rule.\26\ Because of supply chain constraints, and the three to four
year development times needed to install EDRs in a vehicle model
production run,\27\ the EDRs for vehicle model years 2007 through 2010
have already been finalized and cannot be changed without incurring
major redevelopment costs. Specifically, significant changes will be
needed to EDR data bus architecture for the industry to be able to
comply with the final rule. Some manufacturers reported that they may
need to redesign the air bag control module, while some reported that
new EDR hardware architectures needed to be developed. We believe that
these changes, if necessary, would require manufacturers to recertify
their air bag systems, which would require them to invest in
development and testing outside of the normal vehicle model run.
---------------------------------------------------------------------------
\26\ Specifically, AORC, the Alliance, Toyota, and GM.
\27\ During the May 15, 2007 SAE Government/Industry Workshop,
Ford representatives indicated that development times for EDRs
precede vehicle model introductions by at least 3 years.
---------------------------------------------------------------------------
We agree that a delay in the rule is needed to prevent
manufacturers from incurring significant redesign costs for EDRs. We do
not want the final rule to inhibit manufacturers from continuing to
include EDRs (in whatever form) in their vehicles between now and the
effective date of the final rule. Therefore, we are granting the
petitions to delay the effective date until September 1, 2012. We are
not granting the petitions with respect to the requests for a phase-in,
because we believe that a fixed date of 2012 will be sufficient for
manufacturers' needs. For the same reason, and because manufacturers
indicated that 2012 would be sufficient,
[[Page 2178]]
we are not granting the petition for an effective date of September 1,
2013.
NHTSA believes that the additional two years will both allow the
manufacturers time to implement the necessary EDR and air bag
architecture changes during the normal model development cycles, and
the agency to continue to collect data from vehicles with EDRs that do
not meet the full requirements of the final rule, specifically, from
manufacturers who are farther from meeting the rule than GM. Moreover,
by delaying the effective date of the final rule, the agency will have
a better chance of collecting more complete data from EDRs installed in
vehicles, since manufacturers can implement some minor changes to the
EDR functions in preparation for compliance with the final rule.
G. Whether NHTSA Should Mandate EDRs
Public Citizen reiterated its position from its comments to the
NPRM and petitioned NHTSA to mandate EDR installation for all vehicles
instead of establishing requirements for voluntarily installed EDRs. It
argued that the safety benefits of EDRs far outweigh the financial
burden manufacturers would incur with a fleet-wide mandate, and that
manufacturers will seek relief from the requirements by not equipping
their vehicles with EDRs. Public Citizen further stated that gaps in
accident reconstruction knowledge would compromise the agency's ability
to draw conclusions from EDR data, and that a mandate for EDRs on all
vehicles would avoid those gaps.
Agency Response: NHTSA carefully considered Public Citizen's
petition that we mandate installation of EDRs. Public Citizen provided
no new information in their petition for reconsideration of the final
rule that had not already been provided in their comments to the NPRM.
We did not mandate installation of EDRs in new motor vehicles in the
final rule, and discussed extensively our reasoning for our decision
not to mandate the installation of EDRs in motor vehicles at this time.
See 71 FR 51010-11 (Aug. 28, 2006) for a complete discussion of this
issue. In summary, although we chose not to mandate EDRs, we recognize
the benefits of EDRs in vehicles, and the final rule intends to capture
those benefits by helping the agency gather EDR information and
building the foundation for ACN. As explained in the final rule, given
the current level of voluntary EDR installation, and the expected
increases in the extent of voluntary installation, we continue to
believe that EDRs will yield data of statistical significance even
without being mandated.
Further, manufacturers benefit from having EDRs in their vehicles
as well--they collect information on how their vehicles and equipment
are performing just as NHTSA does. We believe that this benefit to
manufacturers will help keep EDRs in vehicles, as evidenced by the fact
that the marketplace appears to be adopting more, not fewer, EDRs.
Therefore, we are denying Public Citizen's petition to mandate
installation of EDRs in all new vehicles.
H. Public Privacy and Consumer Notification of EDRs
1. Whether NHTSA Should Require a Mechanical Lockout on EDRs
Mr. Thomas Kowalick petitioned NHTSA to require a mechanical
lockout on the on-board diagnostic (OBD2) port \28\ for the sole use/
control of the owner or operator of the vehicle equipped with an EDR.
Mr. Kowalick argued that it is possible to protect consumer privacy
rights by use of a mechanical lockout system on this port, which is
used to download EDR data. In a March 1, 2007 meeting with NHTSA, Mr.
Kowalick expressed an additional concern that aftermarket devices are
being developed to erase or tamper with EDR data.\29\ He noted that the
preamble to the final rule stated that if tampering became apparent,
NHTSA would reconsider its position on this issue.
---------------------------------------------------------------------------
\28\ See 61 FR 40940. The OBD2 port standard specifies the type
of diagnostic connector and its output pin locations used for
monitoring vehicle parameters measured by the on-board computer(s)
such as emissions controls. It is typically located on the driver's
side of the passenger compartment near the center console.
\29\ Docket No. NHTSA-2006-25666-457.
---------------------------------------------------------------------------
Agency response: We are denying this petition. Mr. Kowalick
provided information that devices may exist to erase or tamper with EDR
data, but he did not provide information that they were actually being
used. There are several other ways that EDR tampering will be
prevented. First, the EDR download port is installed inside the
vehicle, on which the door locks act as a first line of defense to
prevent access to the data port. Second, if the vehicle glazing is
missing, either due to an accident or forceful entry (assuming a person
wants to tamper with someone else's EDR data), the vehicle key is
needed to power the vehicle to access the EDR data through the
diagnostic port. And third, the final rule requires that event data
from crashes in which an air bag has been deployed must be locked and
cannot be overwritten. As stated in the final rule, the agency may
revisit the issue if EDR tampering indeed becomes a problem.
2. Whether NHTSA Should Require EDR Download Tools To Be Standardized
at This Time
Public Citizen petitioned NHTSA to require manufacturers to produce
a standardized tool for downloading of EDR data by first responders. It
argued that requiring a standardized download tool, rather than simply
making a tool available within 90 days of the first sale of vehicles
equipped with EDRs, will help reduce costs for emergency personnel and
law enforcement officials and prevent manufacturers from providing
tools that only download the bare minimum of EDR data. It further
argued that without a standardized download tool, manufacturers will be
able to maintain sole ownership of the only tools that gain access to
all of an EDR's recorded data and ``cover up'' data on defect trends by
preventing NHTSA, first responders, crash investigators, and other
safety researchers from gaining access to valuable safety data.
Agency response: We are denying this petition. NHTSA has carefully
considered the petitioner's comments, and believes that there is not a
need to require a single standardized tool at this time. As we stated
in the final rule, we expect that tools would be available for several
years after the vehicle has been sold, and that newer versions of the
download tools would be ``backward-compatible.'' We note that this
trend has held true, but believe that the download tools required to
read EDRs will become more complex for a period of time as
manufacturers increasingly offer EDRs in their vehicle fleets, and
develop existing EDRs to meet this rule.
We are continuing to monitor the progress of voluntarily installed
EDRs and note that the manufacturers are already working toward a
standardized set of downloading tools. We believe that once this
standard becomes effective, the downloading process for EDRs will
become less complex, and the tools will become easier to use and less
expensive. Thus far EDR downloads have provided the information
necessary for the agency to accomplish our research and enforcement
objectives without the requirement of a standardized download tool.
However, if this trend does not continue and download tools become so
expensive that the collection of EDR data by NHTSA, first responders,
crash investigators, and other safety researchers is hampered by the
cost of the tools, the agency will consider taking appropriate action
to address the
[[Page 2179]]
problem. Since there is no evidence that the absence of a standardized
download tool is hampering the usefulness of current EDRs, we are
denying the petitioner's request.
3. Whether NHTSA Should Require Additional Consumer Notification
Public Citizen petitioned NHTSA to require vehicles equipped with
EDRs to have window stickers or labels at the point of sale. It argued
that the final rule's requirement for an owner's manual statement
regarding the presence and functioning of the EDR is insufficient,
because many people do not read the owner's manual before purchasing
the vehicle. Additionally, Public Citizen petitioned NHTSA to require
consumers to be handed a one-page document with a message similar to
the statement in the owner's manual before purchasing the vehicle that
notifies them of the presence of the EDR and describes its purpose and
capabilities.
Agency response: We are denying these requests. The purpose of the
specified statement in the owner's manual is to make the operator aware
of the presence, function, and capabilities of the EDR. We believe that
a statement in the owner's manual is sufficient for that purpose. The
owner's manual is used to provide operators with a variety of types of
important information concerning the vehicle, and we believe that there
is nothing about the nature of EDRs to necessitate such information to
be provided in other locations. We also note that putting this
information on a window sticker would tend to dilute the effect of the
other information that is already there, such as NHTSA's vehicle safety
ratings.
4. Whether EDR Data Should Be Included in the FARS System
Public Citizen asked in its petition that NHTSA include EDR data in
the Fatality Analysis Reporting System (FARS), and ensure that a system
is in place for all first responders to download and forward data to
NHTSA for analysis and inclusion in research databases. It stated that
data analysis and presentation are critical to reaping the maximum
benefit from EDR data. Public Citizen also recommended that NHTSA
should additionally create a new database solely for EDR data to help
corroborate conclusions drawn from other databases, and a system in
partnership with law enforcement officials to ensure that all available
EDR data is retrieved following a crash and sent to the agency for
analysis.
Agency response: We appreciate Public Citizen's suggestions but
note that the specific ways in which NHTSA may utilize EDR data in its
programs is not within the scope of this rulemaking. The current system
that NHTSA has been utilizing to integrate EDR data into research and
analysis efforts has proven to be most adequate thus far. As the agency
maintains and further develops its various safety programs, it will
continue to consider ways in which EDR data may be able to be used to
improve them.
I. Other Technical Revisions
On April 6, 2007, the agency published a final rule establishing
FMVSS No. 126, ``Electronic stability control systems,'' which set
performance and equipment requirements for electronic stability control
(ESC) systems. As a technical correction, we are amending the
definition of ``stability control'' in Sec. 563.5 to read ``means any
device that complies with FMVSS No. 126, ``Electronic stability control
systems.''
J. Summary of Other Letters to the Docket
The American Automobile Association (AAA) stated that although some
states are requiring manufacturers to notify consumers in the vehicle's
owner's manual of the presence and functioning of the EDR, under the
final rule it may take as long as four years for the notice
requirements to transition to the remaining states. It urged the agency
to work with manufacturers to include the owner's manual notice as part
of the routine schedule of updating and revising the owner's manual.
In response, we note that we have reviewed many owners' manuals as
part of this rulemaking. We have found that many have been updated to
reflect the fact that EDRs are included on vehicles.
NHTSA also received and reviewed submissions from more than 400
private citizens expressing various concerns, including a belief in
some cases that the agency was mandating EDRs and that consumer privacy
would not be protected. However, the letters did not generally address
the discussions provided by the agency in the final rule concerning
privacy and other relevant issues. Moreover, the final rule does not
mandate the installation of EDRs but instead standardizes the format of
data collected from EDRs voluntarily installed in vehicles.
IV. Rulemaking Analyses and Notices
This rule makes several technical changes to the regulatory text of
49 CFR Part 563, and does not increase the regulatory burden of
manufacturers. The agency has discussed the relevant requirements of
the Vehicle Safety Act, Executive Order 12866, the Department of
Transportation's regulatory policies and procedures, the Regulatory
Flexibility Act, Executive Order 13132 (Federalism), Executive Order
12988 (Civil Justice Reform), Executive Order 13045 (Protection of
Children from Health and Safety Risks), the Paperwork Reduction Act,
the National Technology Transfer and Advancement Act, Unfunded Mandates
Reform Act, and the National Environmental Policy Act in the August
2006 final rule cited above. Those discussions are not affected by
these technical changes.
Privacy Act
Please note that anyone is able to search the electronic form of
all documents received into any of our dockets by the name of the
individual submitting the document (or signing the document, if
submitted on behalf of an association, business, labor union, etc.).
You may review DOT's complete Privacy Act Statement in the Federal
Register published on April 11, 2000 (Volume 65, Number 70; Pages
19477-78), or you may visit http://www.dot.gov/privacy.html.
V. Regulatory Text
List of Subjects in 49 CFR Part 563
Motor vehicle safety, Motor vehicles, Reporting and recordkeeping
requirements.
0
In consideration of the foregoing, Part 563 is amended as follows:
PART 563--EVENT DATA RECORDERS
0
1. The authority citation for Part 563 continues to read as follows:
Authority: 49 U.S.C. 322, 30101, 30111, 30115, 30117, 30166,
30168; delegation of authority at 49 CFR 1.50.
0
2. Revise Sec. 563.3 to read as follows:
Sec. 563.3 Application.
This part applies to the following vehicles manufactured on or
after September 1, 2012, if they are equipped with an event data
recorder: passenger cars, multipurpose passenger vehicles, trucks, and
buses with a GVWR of 3,855 kg (8,500 pounds) or less and an unloaded
vehicle weight of 2,495 kg (5,500 pounds) or less, except for walk-in
van-type trucks or vehicles designed to be sold exclusively to the U.S.
Postal Service. This part also applies to manufacturers of those
vehicles. However, vehicles manufactured before September 1, 2013 that
are manufactured in two or more stages or that are altered (within the
meaning of
[[Page 2180]]
49 CFR 567.7) after having been previously certified to the Federal
motor vehicle safety standards in accordance with Part 567 of this
chapter need not meet the requirements of this part.
Sec. 563.4 [Removed]
0
3. Remove and reserve Sec. 563.4 to read as follows:
0
4. Revise Sec. 563.5 to read as follows:
Sec. 563.5 Definitions.
(a) Motor vehicle safety standard definitions. Unless otherwise
indicated, all terms that are used in this part and are defined in the
Motor Vehicle Safety Standards, Part 571 of this subchapter, are used
as defined therein.
(b) Other definitions.
ABS activity means the anti-lock brake system (ABS) is actively
controlling the vehicle's brakes.
Air bag warning lamp status means whether the warning lamp required
by FMVSS No. 208 is on or off.
Capture means the process of buffering EDR data in a temporary,
volatile storage medium where it is continuously updated at regular
time intervals.
Delta-V, lateral means the cumulative change in velocity, as
recorded by the EDR of the vehicle, along the lateral axis, starting
from crash time zero and ending at 0.25 seconds, recorded every 0.01
seconds.
Delta-V, longitudinal means the cumulative change in velocity, as
recorded by the EDR of the vehicle, along the longitudinal axis,
starting from crash time zero and ending at 0.25 seconds, recorded
every 0.01 seconds.
Deployment time, frontal air bag means (for both driver and right
front passenger) the elapsed time from crash time zero to the
deployment command, or for multi-staged air bag systems, the deployment
command for the first stage.
Disposal means the deployment command of the second (or higher, if
present) stage of a frontal air bag for the purpose of disposing the
propellant from the air bag device.
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.
Engine RPM means
(1) For vehicles powered by internal combustion engines, the number
of revolutions per minute of the main crankshaft of the vehicle's
engine; and
(2) 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.
Engine throttle, percent full means the driver-requested
acceleration as measured by the throttle position sensor on the
accelerator pedal compared to the fully-depressed position.
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.
Event data recorder (EDR) means a device or function in a vehicle
that records the vehicle's dynamic time-series data during the time
period just prior to a crash event (e.g., vehicle speed vs. time) or
during a crash event (e.g., delta-V vs. time), intended for retrieval
after the crash event. For the purposes of this definition, the event
data do not include audio and video data.
Frontal air bag means an inflatable restraint system that requires
no action by vehicle occupants and is used to meet the applicable
frontal crash protection requirements of FMVSS No. 208.
Ignition cycle, crash means the number (count) of power cycles
applied to the recording device at the time when the crash event
occurred since the first use of the EDR.
Ignition cycle download means the number (count) of power cycles
applied to the recording device at the time when the data was
downloaded since the first use of the EDR.
Lateral acceleration means the component of the vector acceleration
of a point in the vehicle in the y-direction. The lateral acceleration
is positive from left to right, from the perspective of the driver when
seated in the vehicle facing the direction of forward vehicle travel.
Longitudinal acceleration means the component of the vector
acceleration of a point in the vehicle in the x-direction. The
longitudinal acceleration is positive in the direction of forward
vehicle travel.
Maximum delta-V, lateral means the maximum value of the cumulative
change in velocity, as recorded by the EDR, of the vehicle along the
lateral axis, starting from crash time zero and ending at 0.3 seconds.
Maximum delta-V, longitudinal means the maximum value of the
cumulative change in velocity, as recorded by the EDR, of the vehicle
along the longitudinal axis, starting from crash time zero and ending
at 0.3 seconds.
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.
Multi-event crash means the occurrence of 2 events, the first and
last of which begin not more than 5 seconds apart.
Non-volatile memory means the memory reserved for maintaining
recorded EDR data in a semi-permanent fashion. Data recorded in non-
volatile memory is retained after loss of power and can be retrieved
with EDR data extraction tools and methods.
Normal acceleration means the component of the vector acceleration
of a point in the vehicle in the z-direction. The normal acceleration
is positive in a downward direction and is zero when the accelerometer
is at rest.
Occupant position classification means the classification
indicating that the seating posture of a front outboard occupant (both
driver and right front passenger) is determined as being out-of-
position.
Occupant size classification means, for the right front passenger,
the classification of the occupant as an adult and not as a child, and
for the driver, the classification of the driver as not being of small
stature.
Pretensioner means a device that is activated by a vehicle's crash
sensing system and removes slack from a vehicle safety belt system.
Record means the process of saving captured EDR data into a non-
volatile device for subsequent retrieval.
Safety belt status means the feedback from the safety system that
is used to determine that an occupant's safety belt (for both driver
and right front passenger) is fastened or unfastened.
Seat track position switch, foremost, status means the status of
the switch that is installed to detect whether the seat is moved to a
forward position.
Service brake, on and off means the status of the device that is
installed in or connected to the brake pedal system to detect whether
the pedal was pressed. The device can include the brake pedal switch or
other driver-operated service brake control.
Side air bag means any inflatable occupant restraint device that is
mounted to the seat or side structure of the vehicle interior, and that
is designed to deploy in a side impact crash to help mitigate occupant
injury and/or ejection.
Side curtain/tube air bag means any inflatable occupant restraint
device that is mounted to the side structure of the vehicle interior,
and that is designed to deploy in a side impact crash or rollover and
to help mitigate occupant injury and/or ejection.
Speed, vehicle indicated means the vehicle speed indicated by a
manufacturer-designated subsystem
[[Page 2181]]
designed to indicate the vehicle's ground travel speed during vehicle
operation.
Stability control means any device that complies with FMVSS No.
126, ``Electronic stability control systems.''
Steering input means the angular displacement of the steering wheel
measured from the straight-ahead position (position corresponding to
zero average steer angle of a pair of steered wheels).
Suppression switch status means the status of the switch indicating
whether an air bag suppression system is on or off.
Time from event 1 to 2 means the elapsed time from time zero of the
first event to time zero of the second event.
Time, maximum delta-V, lateral means the time from crash time zero
to the point where the maximum value of the cumulative change in
velocity is found, as recorded by the EDR, along the lateral axis.
Time, maximum delta-V, longitudinal means the time from crash time
zero to the point where the maximum value of the cumulative change in
velocity is found, as recorded by the EDR, along the longitudinal axis.
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.
Time to deploy, pretensioner means the elapsed time from crash time
zero to the deployment command for the safety belt pretensioner (for
both driver and right front passenger).
Time to deploy, side air bag/curtain means the elapsed time from
crash time zero to the deployment command for a side air bag or a side
curtain/tube air bag (for both driver and right front passenger).
Time to first stage means the elapsed time between time zero and
the time when the first stage of a frontal air bag is commanded to
fire.
Time to n\th\ stage means the elapsed time from crash time zero to
the deployment command for the nth stage of a frontal air bag (for both
driver and right front passenger).
Time zero means whichever of the following occurs first:
(1) For systems with ``wake-up'' air bag control systems, the time
at which the occupant restraint control algorithm is activated; or
(2) 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
(3) An air bag deployment.
Trigger threshold means a change in vehicle velocity, in the
longitudinal direction, that equals or exceeds 8 km/h within a 150 ms
interval. For vehicles that record ``delta-V, lateral,'' trigger
threshold means a change in vehicle velocity in either the longitudinal
or lateral direction that equals or exceeds 8 km/h within a 150 ms
interval.
Vehicle roll angle means the angle between the vehicle's y-axis and
the ground plane.
Volatile memory means the memory reserved for buffering of captured
EDR data. The memory is not capable of retaining data in a semi-
permanent fashion. Data captured in volatile memory is continuously
overwritten and is not retained in the event of a power loss or
retrievable with EDR data extraction tools.
X-direction means in the direction of the vehicle's X-axis, which
is parallel to the vehicle's longitudinal centerline. The X-direction
is positive in the direction of forward vehicle travel.
Y-direction means in the direction of the vehicle's Y-axis, which
is perpendicular to its X-axis and in the same horizontal plane as that
axis. The Y-direction is positive from left to right, from the
perspective of the driver when seated in the vehicle facing the
direction of forward vehicle travel.
Z-direction means in the direction of the vehicle's Z-axis, which
is perpendicular to the X- and Y-axes. The Z-direction is positive in a
downward direction.
0
5. Revise Sec. 563.7 to read as follows:
Sec. 563.7 Data elements.
(a) Data elements required for all vehicles. Each vehicle equipped
with an EDR must record all of the data elements listed in Table I,
during the interval/time and at the sample rate specified in that
table.
Table I.--Data Elements Required for all Vehicles Equipped With an EDR
------------------------------------------------------------------------
Data sample
Recording interval/ rate
Data element time\1\ (relative to (samples
time zero) per second)
------------------------------------------------------------------------
Delta-V, longitudinal.............. 0 to 250 ms, or 0 to 100
End of Event Time
plus 30 ms, whichever
is shorter.
Maximum delta-V, longitudinal...... 0 to 300 ms, or 0 to N/A
End of Event Time
plus 30 ms, whichever
is shorter.
Time, maximum delta-V.............. 0 to 300 ms, or 0 to N/A
End of Event Time
plus 30 ms, whichever
is shorter.
Speed, vehicle indicated........... -5.0 to 0 sec......... 2
Engine throttle, % full (or -5.0 to 0 sec......... 2
accelerator pedal, % full).
Service brake, on/off.............. -5.0 to 0 sec......... 2
Ignition cycle, crash.............. -1.0 sec.............. N/A
Ignition cycle, download........... At time of download\3\ N/A
Safety belt status, driver......... -1.0 sec.............. N/A
Frontal air bag warning lamp, on/ -1.0 sec.............. N/A
off\2\.
Frontal air bag deployment, time to Event................. N/A
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.
Frontal air bag deployment, time to Event................. N/A
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.
Multi-event, number of events (1, Event................. N/A
2).
Time from event 1 to 2............. As needed............. N/A
[[Page 2182]]
Complete file recorded (yes, no)... Following other data.. N/A
------------------------------------------------------------------------
\1\Pre-crash data and crash data are asynchronous. The sample time
accuracy requirement for pre-crash time is -0.1 to 1.0 sec (e.g., T =
1 would need to occur between -1.1 and 0 seconds).
\2\The frontal air bag warning lamp is the readiness indicator specified
in S4.5.2 of FMVSS No. 208.
\3\The ignition cycle at the time of download is not required to be
recorded at the time of the crash, but shall be reported during the
download process.
(b) Data elements required for vehicles under specified conditions.
Each vehicle equipped with an EDR must record each of the data elements
listed in column 1 of Table II for which the vehicle meets the
condition specified in column 2 of that table, during the interval/time
and at the sample rate specified in that table.
TABLE II.--Data Elements Required for Vehicles Under Specified Minimum Conditions
----------------------------------------------------------------------------------------------------------------
Recording interval/time Data sample
Data element name Condition for requirement \1\ (relative to time rate (per
zero) second)
----------------------------------------------------------------------------------------------------------------
Lateral acceleration.................... If recorded \2\........... 0 to 250 ms............... 100
Longitudinal acceleration............... If recorded............... 0 to 250 ms............... 100
Normal acceleration..................... If recorded............... 0 to 250 ms............... 100
Delta-V, lateral........................ If recorded............... 0 to 250 ms, or 0 to End 100
of Event Time plus 30 ms,
whichever is shorter.
Maximum delta-V, lateral................ If recorded............... 0 to 300 ms, or 0 to End N/A
of Event Time plus 30 ms,
whichever is shorter.
Time, maximum delta-V, lateral.......... If recorded............... 0 to 300 ms, or 0 to End N/A
of Event Time plus 30 ms,
whichever is shorter.
Time, maximum delta-V, resultant........ If recorded............... 0 to 300 ms, or 0 to End N/A
of Event Time plus 30 ms,
whichever is shorter.
Engine RPM.............................. If recorded............... -50 to 0 sec.............. 2
Vehicle roll angle...................... If recorded............... -10 up to 50 sec \3\...... 10
ABS activity (engaged, non-engaged)..... If recorded............... -50 to 0 sec.............. 2
Stability control (on, off, engaged).... If recorded............... -50 to 0 sec.............. 2
Steering input.......................... If recorded............... -50 to 0 sec.............. 2
Safety belt status, right front If recorded............... -10 sec................... N/A
passenger (buckled, not buckled).
Frontal air bag suppression switch If recorded............... -10 sec................... N/A
status, right front passenger (on, off,
or auto).
Frontal air bag deployment, time to nth If equipped with a Event..................... N/A
stage, driver \4\. driver's frontal air bag
with a multi-stage
inflator.
Frontal air bag deployment, time to nth If equipped with a right Event..................... N/A
stage, right front passenger \4\. front passenger's frontal
air bag with a multi-
stage inflator.
Frontal air bag deployment, nth stage If recorded............... Event..................... N/A
disposal, driver, Y/N (whether the nth
stage deployment was for occupant
restraint or propellant disposal
purposes).
Frontal air bag deployment, nth stage If recorded............... Event..................... N/A
disposal, right front passenger, Y/N
(whether the nth stage deployment was
for occupant restraint or propellant
disposal purposes).
Side air bag deployment, time to deploy, If recorded............... Event..................... N/A
driver.
Side air bag deployment, time to deploy, If recorded............... Event..................... N/A
right front passenger.
Side curtain/tube air bag deployment, If recorded............... Event..................... N/A
time to deploy, driver side.
Side curtain/tube air bag deployment, If recorded............... Event..................... N/A
time to deploy, right side.
Pretensioner deployment, time to fire, If recorded............... Event..................... N/A
driver.
Pretensioner deployment, time to fire, If recorded............... Event..................... N/A
right front passenger.
Seat track position switch, foremost, If recorded............... -10 sec................... N/A
status, driver.
[[Page 2183]]
Seat track position switch, foremost, If recorded............... -10 sec................... N/A
right front passenger.
Occupant size classification, driver.... If recorded............... -10 sec................... N/A
Occupant size classification, right If recorded............... -10 sec................... N/A
front passenger.
Occupant position classification, driver If recorded............... -10 sec................... N/A
Occupant position classification, right If recorded............... -10 sec................... N/A
front passenger.
----------------------------------------------------------------------------------------------------------------
\1\ Pre-crash data and crash data are asynchronous The sample time accuracy requirement for pre-crash time is -
01 to 10 sec (e.g., T = -1 would need to occur between -11 and 0 seconds)
\2\ ``If recorded'' means if the data is recorded in non-volatile memory for the purpose of subsequent
downloading
\3\ ``Vehicle roll angle'' may be recorded in any time duration -10 to 50 seconds is suggested
\4\ List this element n--1 times, once for each stage of a multi-stage air bag system
0
6. Revise Sec. 5638 to read as follows:
Sec. 563.8 Data format
(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
Table III.--Reported Data Element Format
----------------------------------------------------------------------------------------------------------------
Data element Minimum range Accuracy Resolution
----------------------------------------------------------------------------------------------------------------
Lateral acceleration................. -5 g to +5 g........... 10%........ 0.5 g.
Longitudinal acceleration............ -50 g to +50 g......... 10%........ 0.5 g.
Normal acceleration.................. -5 g to +5 g........... 10%........ 0.5 g.
Longitudinal delta-V................. -100 km/h to + 100 km/h 10%........ 1 km/h.
Lateral delta-V...................... -100 km/h to + 100 km/h 10%........ 1 km/h.
Maximum delta-V, longitudinal........ -100 km/h to + 100 km/h 10%........ 1 km/h.
Maximum delta-V, lateral............. -100 km/h to + 100 km/h 10%........ 1 km/h.
Time, maximum delta-V, longitudinal.. 0--300 ms, or 0--End of 3 ms....... 2.5 ms.
Event Time plus 30 ms,
whichever is shorter.
Time, maximum delta-V, lateral....... 0--300 ms, or 0--End of 3 ms....... 2.5 ms.
Event Time plus 30 ms,
whichever is shorter.
Time, maximum delta-V, resultant..... 0--300 ms, or 0--End of 3 ms....... 2.5 ms.
Event Time plus 30 ms,
whichever is shorter.
Vehicle roll angle................... -1080 deg to + 1080 deg 10%........ 10 deg.
Speed, vehicle indicated............. 0 km/h to 200 km/h..... 1 km/h..... 1 km/h.
Engine throttle, percent full 0 to 100%.............. 5%......... 1%.
(accelerator pedal percent full).
Engine RPM........................... 0 to 10,000 rpm........ 100 rpm... 100 rpm.
Service brake (on, off).............. On and Off............. N/A.................... On and Off.
ABS activity......................... On and Off............. N/A.................... On and Off.
Stability control (on, off, engaged). On, Off, Engaged....... N/A.................... On, Off, Engaged.
Steering input....................... -250 deg CW to + 250 5%......... 1%.
deg CCW.
Ignition cycle, crash................ 0 to 60,000............ 1 cycle.... 1 cycle.
Ignition cycle, download............. 0 to 60,000............ 1 cycle.... 1 cycle.
Safety belt status, driver........... On or Off.............. N/A.................... On or Off.
Safety belt status, right front On or Off.............. N/A.................... On or Off.
passenger.
Frontal air bag warning lamp (on, On or Off.............. N/A.................... On or Off.
off).
Frontal air bag suppression switch On, Off, or Auto....... N/A.................... On, Off, or Auto.
status.
Frontal air bag deployment, time to 0 to 250 ms............ 2 ms....... 1 ms.
deploy/first stage, driver.
Frontal air bag deployment, time to 0 to 250 ms............ 2 ms....... 1 ms.
deploy/first stage, right front
passenger.
Frontal air bag deployment, time to 0 to 250 ms............ 2 ms....... 1 ms.
n\th\ stage, driver.
Frontal air bag deployment, time to 0 to 250 ms............ 2 ms....... 1 ms.
n\th\ stage, right front passenger.
Frontal air bag deployment, n\th\ Yes or No.............. N/A.................... Yes or No.
stage disposal, driver (y/n).
[[Page 2184]]
Frontal air bag deployment, n\th\ Yes or No.............. N/A.................... Yes or No.
stage disposal, right front
passenger (y/n).
Side air bag deployment, time to 0 to 250 ms............ 2 ms....... 1 ms.
deploy, driver.
Side air bag deployment, time to 0 to 250 ms............ 2 ms....... 1 ms.
deploy, right front passenger.
Side curtain/tube air bag deployment, 0 to 250 ms............ 2 ms....... 1 ms.
time to deploy, driver side.
Side curtain/tube air bag deployment, 0 to 250 ms............ 2 ms....... 1 ms.
time to deploy, right side.
Pretensioner deployment, time to 0 to 250 ms............ 2 ms....... 1 ms.
fire, driver.
Pretensioner deployment, time to 0 to 250 ms............ 2 ms....... 1 ms.
fire, right front passenger.
Seat track position switch, foremost, Yes or No.............. N/A.................... Yes or No.
status, driver.
Seat track position switch, foremost, Yes or No.............. N/A.................... Yes or No.
status, right front passenger.
Occupant size driver occupant 5\th\ Yes or No.............. N/A.................... Yes or No.
female size (y/n).
Occupant position size right front Yes or No.............. N/A.................... Yes or No.
passenger child (y/n).
Occupant position classification, Yes or No.............. N/A.................... Yes or No.
driver oop (y/n).
Occupant position classification, Yes or No.............. N/A.................... Yes or No.
right front passenger oop (y/n).
Multi-event, number of events (1, 2). 1 or 2................. N/A.................... 1 or 2.
Time from event 1 to 2............... 0 to 5.0 sec........... 0.1 sec................ 0.1 sec.
Complete file recorded (y/n)......... Yes or No.............. N/A.................... Yes or No.
----------------------------------------------------------------------------------------------------------------
(b) Acceleration Time-History data and format: the longitudinal,
lateral, and normal acceleration time-history data, as applicable, must
be filtered either during the recording phase or during the data
downloading phase to include:
(1) The Time Step (TS) that is the inverse of the sampling
frequency of the acceleration data and which has units of seconds;
(2) The number of the first point (NFP), which is an integer that
when multiplied by the TS equals the time relative to time zero of the
first acceleration data point;
(3) The number of the last point (NLP), which is an integer that
when multiplied by the TS equals the time relative to time zero of the
last acceleration data point; and
(4) NLP--NFP + 1 acceleration values sequentially beginning with
the acceleration at time NFP * TS and continue sampling the
acceleration at TS increments in time until the time NLP * TS is
reached.
0
7. Revise Sec. 563.9 to read as follows:
Sec. 563.9 Data capture.
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. The memory for
each air bag deployment event must be locked to prevent any future
overwriting of these data.
(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 either to overwrite
the previous non-deployment event data with the current non-deployment
event data, or not to record the current non-deployment event data.
(3) EDR buffers containing previous deployment-event data must not
be overwritten by the current non-deployment event data.
Issued: January 8, 2008.
Nicole R. Nason,
Administrator.
[FR Doc. E8-407 Filed 1-11-08; 8:45 am]
BILLING CODE 4910-59-P