Federal Register, Volume 76 Issue 151 (Friday, August 5, 2011)

[Federal Register Volume 76, Number 151 (Friday, August 5, 2011)]
[Rules and Regulations]
[Pages 47478-47489]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2011-19214]

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

DEPARTMENT OF TRANSPORTATION

National Highway Transportation Safety Administration

49 CFR Part 563

[Docket No. NHTSA-2011-0106]
RIN 2127-AK71

Event Data Recorders

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

ACTION: Final rule; response to petitions for reconsideration.

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

SUMMARY: On January 14, 2008, the agency published a final rule \1\
amending the requirements for event data recorders (EDRs). The January
2008 document responded to petitions for reconsideration of the
original August 2006 final rule that established the EDR
standardization requirements for those voluntarily installed. In
response to the January 14, 2008, final rule, the agency received three
petitions for reconsideration from the Alliance of Automobile
Manufacturers (Alliance), the Association of International Automobile
Manufacturers, Inc. Technical Affairs Committee (AIAM), and Mr. Thomas
Kowalick, a private citizen. After careful consideration, the agency is
granting some aspects of the petitions, and denying others.
---------------------------------------------------------------------------

\1\ On February 8, 2008 the Federal Register issued a correction
notice for the data in Table II of the final rule. See 73 FR 8408.

DATES: Effective Date: The amendments in this rule are effective
October 4, 2011.
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 (prior to first sale) 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 September 19, 2011.

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
Rulemaking Analyses and Notices.

FOR FURTHER INFORMATION CONTACT: For technical and policy issues,
contact: David Sutula, Office of Crashworthiness Standards, NVS-112.
Telephone: (202) 366-3273. Facsimile: (202) 366-7002.
For legal issues, contact:
Mr. David Jasinski, Office of the Chief Counsel, NCC-112.
Telephone: (202) 366-2992. Facsimile: (202) 366-3820.
Both persons may be reached by mail at the following address:
National Highway Traffic Safety Administration, 1200 New Jersey
Avenue, SE., West Building, 4th Floor, Washington, DC 20590.

SUPPLEMENTARY INFORMATION:

Table of Contents

I. Background
II. Summary of Petitions for Reconsideration
III. Discussion and Analysis
IV. Rulemaking Analyses and Notices
V. Regulatory Text

I. Background

In August 2006, NHTSA issued a final rule \2\ to establish uniform
performance requirements for the accuracy, collection, storage,
survivability, and retrievability of onboard motor vehicle crash event
data recorders (EDRs) voluntarily installed in passenger cars and other
light vehicles. This final rule was intended to standardize the data
obtained through EDRs so that such data would be put to the most
effective future use.
---------------------------------------------------------------------------

\2\ See 71 FR 50998.
---------------------------------------------------------------------------

Specifically, the regulation, 49 CFR part 563 (Part 563), applies
to passenger cars, multipurpose passenger vehicles, trucks, and buses
with a gross vehicle weight rating (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, that are equipped with an event
data recorder and to the manufacturers of these vehicles. The final
rule is intended to be technology-neutral, so as to permit compliance
with any available EDR technology that meets the specified performance
requirements.
In January 2008 (73 FR 2168), the agency amended the EDR final rule
in the following ways:
We clarified the event storage definitions to alleviate
any uncertainties in multiple event crashes,
Revised certain sensor ranges and accuracies to reflect
current state of the art technologies,
Clarified the recorded data reporting format,
Specified vehicle storage conditions during compliance
testing,
Clarified the required data elements and scope of covered
sensors, and
Revised the effective date to provide additional time for
manufacturers and suppliers to comply with the rule.

The agency made these technical changes 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. The final rule also
changed the effective date to September 1, 2012, to provide
manufacturers more time to implement the necessary changes to EDR
architectures within their normal product development cycles. NHTSA
also issued a Federal Register notice on February 8, 2008, (73 FR 8408)
to correct the placement of decimal points for data in Table II of the
final rule.

[[Page 47479]]

II. Summary of Petitions for Reconsideration

The agency received three petitions for reconsideration \3\ and two
requests for interpretation in response to the January 2008 final rule.
The petitions for reconsideration were submitted by the Alliance of
Automobile Manufacturers (Alliance), the Association of International
Automobile Manufacturers, Inc. Technical Affairs Committee (AIAM), and
Mr. Thomas Kowalick. The requests for interpretation were submitted by
the Automotive Occupant Restraints Council (AORC) and Robert Bosch, LLC
(Bosch). To the extent possible, the agency will address these requests
for interpretation in this notice.
---------------------------------------------------------------------------

\3\ See Docket number NHTSA-2008-0004, submissions 0005 through
0007.
---------------------------------------------------------------------------

The Alliance petitioned the agency to remove collection of
acceleration data from part 563. It commented that acceleration could
be reasonably estimated from delta-V data collected by the EDR, and
that the 250 millisecond time interval required in Part 563 would
increase the cost of memory for storage of acceleration data. It
further commented that the revised acceleration data accuracy
requirements do not sufficiently address the effects of data clipping.
It recommended that the agency amend Sec. 563.6 to be consistent with
the agency's intent to exclude peripheral sensors as described in the
preamble of the final rule. The Alliance recommended that the agency
establish a test procedure for compliance with the delta-V accuracy
requirement. Finally, the Alliance commented on several technical and
editorial corrections to clarify the regulatory text for certain data
elements such as suppression switch status, occupant classification,
antilock braking system (ABS) status, stability control status, and
seat track position.
The AIAM requested that the agency make an allowance in the final
rule for the possibility of reduced accelerometer accuracy resulting
from data clipping. It commented that clipping can occur at higher
impact speeds even with sensors of fairly wide range capability. It
requested that the agency clarify its intent with regard to the capture
and lock of data collected from certain air bag deployment events. In
addition, the AIAM requested that the agency clarify certain data
elements and definitions such as time zero, end of event, multi-event
status, and accelerometer range.
Mr. Thomas Kowalick petitioned the agency to reconsider a
mechanical lock out system for the download port of EDRs that could
only be accessed by the owner of the vehicle. He stated that devices
are being offered to consumers to alter odometer readings, erase EDR
data, or prevent EDR data from being recorded by the vehicle.
In its request for interpretation, the AORC stated its belief that
manufacturers will forego recording of acceleration data and lateral
delta-V data if the agency does not allow for additional inaccuracy due
to data clipping. It requested that the agency clarify the accuracy
requirements in Table III, specifically for accelerometers, and all
parameters calculated from the accelerometer data. Additionally, the
AORC requested that the agency clarify:
[cir] That events involving deployable restraints other than air
bags could be treated as an event trigger at the option of the
manufacturer,
[cir] That the data lock may apply to either the individual event
data or the entire EDR at the option of the manufacturer,
[cir] Whether the acceleration/angular rate data elements in Table
II are single sampled (raw) data or time averaged data, and
[cir] That newer steering systems with active intervention may
allow cases where the steering angle and tire position may not
correlate.
Bosch requested that the agency clarify that the lateral
acceleration data element requirement in Table III is based on the need
for data from lateral sensors with a relatively large range (high-G),
having a typical range of 50 g and used for side crash
events, rather than lateral sensors with a relatively small range (low-
G) having a typical range of 5 g and used for rollover
events. It assumed that the lateral acceleration data used for side
crash events are the main scope of the final rule, and therefore that
the range for the data element would be more appropriately set at
50 g. Bosch also requested that the agency interpret the
accuracy and resolution for the steering input data element in Table
III so that the range, resolution, and accuracy are consistent.

III. Discussion and Analysis

A. Request To Delete Acceleration Data From Requirements of Part 563

Part 563 specifies that if the EDR records acceleration data ``in
non-volatile memory for the purpose of subsequent downloading,'' then
the data must be reported under the minimum conditions and format
specified in Tables II and III. Acceleration data has been introduced
as a desired component of the EDR rulemaking as early as the June 14,
2004 \4\ Notice of Proposed Rulemaking (NPRM). Originally proposed as a
required data element, we revised the requirement to an optional data
element in the August 28, 2006 \5\ final rule in favor of the
requirement to record delta-V data. However, we retained the
acceleration data elements in recognition of the value of this data
when reconstructing a crash. In response to the 2006 final rule, the
Alliance stated that acceleration data could be derived from the delta-
V data and petitioned the agency to delete the collection requirements
for accelerometer data. In the January 14, 2008 final rule, we denied
the Alliance petition stating 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.'' However, for reporting acceleration data, we reduced the
sampling rate from 500 samples/second to 100 samples/second, reduced
the accuracy from 5 percent to 10 percent,
reduced the resolution from 0.01 g to 0.5 g and removed filtering
protocols to better reflect current accelerometer technologies.
---------------------------------------------------------------------------

\4\ See Docket number NHTSA-2004-18029.
\5\ See Docket number NHTSA-2006-25666.
---------------------------------------------------------------------------

In response to the January 14, 2008 final rule, the Alliance again
petitioned the agency to remove the acceleration data element from part
563. It commented that there are several reasons for the agency to
reconsider its decision. First, the Alliance stated that given the
revisions adopted in the January 14, 2008 final rule, retaining
acceleration data in the regulation provides no incremental crash
assessment information since the acceleration data can be readily
derived from delta-V data. It suggested that through simple arithmetic
manipulation of the delta-V data, the agency could derive acceleration
data. Second, the Alliance stated that a 70 millisecond acceleration
data element time interval is typically used in EDRs for evaluating air
bag performance, not the 250 millisecond interval required in Part 563.
It commented that the increased cost of data storage to meet the
regulation could potentially lead to the unintended consequence of
manufacturers opting not to capture and record acceleration data.
Third, the Alliance commented that it is unaware of any way to
practically assess or comply with the 10 percent accuracy
requirement for the acceleration data elements.
The AIAM commented that while the agency provided allowance for

[[Page 47480]]

accelerometers with ranges greater than the minimums specified in Table
III, it did not provide any additional allowance for resolution based
on an extended range. The AIAM thus believes that manufacturers will
incur additional costs to increase the resolution of accelerometers
with ranges in excess of the minimums. It recommended that the agency
reconsider the Alliance approach \6\ proposed in its petition for
reconsideration to the August 28, 2006 final rule. The Alliance
proposed that the accelerometer resolution be revised to ``the range of
the sensor divided by the number of available states in one byte.'' In
this manner, a sensor capable of measuring 100 g would have a
resolution of 0.39 g (100 g/255 states in a byte).
---------------------------------------------------------------------------

\6\ See Docket No. NHTSA-2006-25666-441.
---------------------------------------------------------------------------

Similarly, the AORC stated their belief that vehicle manufacturers
will forgo recording acceleration data due to concerns about
inaccuracies from sensor saturation or data clipping. The AORC
requested that the agency clarify that the accuracy requirement for the
acceleration data elements applies to the full scale physical
application sensor, rather than the minimum range shown in Table III.
Agency Response: We are denying the petition to remove acceleration
from Part 563. The agency continues to believe, as it has twice stated
(in the August 28, 2006 and January 14, 2008 final rules), that
acceleration is a common data element collected in engineering studies
and crash tests. Vehicle accelerations are among the first sets of data
collected by the EDR, and are subsequently used for determining vehicle
delta-V data. We are aware that several vehicle manufacturers, such as
Ford Motor Company (Ford) and General Motors (GM), currently record
acceleration data via the EDR in addition to delta-V data. The agency
has also stated that the acceleration data element is important in
understanding and evaluating air bag deployment algorithms and vehicle
crash pulses for the purposes of better understanding occupant
restraint performance and predicting injury in crash reconstructions.
The Alliance has also recognized the value of accelerometer data \7\
for such purposes.
---------------------------------------------------------------------------

\7\ See Alliance Comments in Docket Nos. NHTSA-2004-18029,
NHTSA-2006-25666, and NHTSA-2008-0004.
---------------------------------------------------------------------------

In its petition for reconsideration, the Alliance first stated that
``* * * it is pointless to separately record acceleration data at a
rate and interval that matches the rate and interval of delta-V data,
given that these acceleration data can be derived by simple arithmetic
manipulation of the delta-V data.'' Secondly, it suggested that the
cost increase involving Part 563 acceleration data could provide strong
incentive for not recording acceleration data at all.
We partially agree with the Alliance regarding the need to
separately record acceleration data at a rate and interval that matches
the rate and interval of delta-V data. Our interest in acceleration
data extends beyond the simple arithmetic manipulation of delta-V data
for the reasons cited above. However, we note that for other reasons
described below, we have revised the acceleration data element in a
manner that addresses the Alliance's concerns about the recording
intervals and potential for increased costs.
The remaining concerns expressed by the Alliance and other
petitioners dealt with persistent technical issues that affect
compliance with the acceleration data element requirements. The
Alliance stated that the accuracy of the acceleration data collected by
the EDR would not necessarily coincide with the laboratory acceleration
data at any given moment in time. Specifically, the Alliance stated
that EDR acceleration data is typically filtered at a different level
than laboratory accelerometers, and thus results in recorded
acceleration data that is phase-shifted in time. Information shared
during an ex parte meeting with GM \8\ on May 8, 2008, also illustrated
this issue: the data showed that at given points in time, the 10
percent accuracy requirement was not met.
---------------------------------------------------------------------------

\8\ See Docket number NHTSA-2008-0004.
---------------------------------------------------------------------------

Three organizations, the Alliance, the AORC, and the AIAM stated
that the revised acceleration data accuracy requirements do not
sufficiently address the effects of data clipping. The Alliance stated
that during crash tests specified for Part 563 compliance, it is not
uncommon to experience brief periods of deceleration exceeding 50 g.
The AORC stated that such clipped data and resulting inaccuracies could
deter manufacturers recording acceleration. The AIAM also agreed with
the Alliance in that manufacturers would need to switch to sensors of
very high ranges (in excess of 100 g) in order to meet the
accuracy requirements in Part 563. Consequently, the AIAM suggested
that vehicle manufacturers would need to redesign their EDR systems
with higher range sensors that could result in degradation in air bag
system performance. The AIAM submitted data from five crash tests to
illustrate that clipping occurs at the higher impact speeds even with
sensors of a fairly wide range. It requested that the agency make an
allowance in the rule for the possibility of reduced accelerometer
accuracy resulting from data clipping.
In the January 2008 final rule, we relaxed the required
accelerometer resolution capability because we recognized that current
EDR technology would not achieve acceleration data element resolutions
of 0.01 g. We agreed that there would be no significant loss in
acceleration data quality if the acceleration resolution was revised to
0.5 g. However, we did not adopt the Alliance proposal for data element
resolution, favoring instead a set resolution of 0.5 g. Our reasoning
for adopting this set resolution limit was that we intended to
standardize EDR output data. We believed that adopting the Alliance
proposal would encourage a proliferation of acceleration data element
output resolutions rather than a standardized single reported
resolution.
At that time, we believed that the revised acceleration data
element accuracy and resolution requirements would provide sufficient
relief to avoid any unnecessary rise in manufacturing costs. We did not
fully anticipate the effects of sensor saturation or clipping on the
choice of accelerometer ranges to comply with the EDR rule. However,
because of this clipping, manufacturers that wished to continue
capturing acceleration data would be left with no alternative but to
increase the sensing range of accelerometers beyond what is practical
for EDRs. This, in part, contributed to the Alliance request to either
remove the acceleration data elements or revise the acceleration data
element resolution requirements.
The data presented by the petitioners and during the ex parte
meeting with GM indicated that clipping can occur for brief periods
even during Federal Motor Vehicle Safety Standard (FMVSS) No. 208,
``Occupant crash protection,'' compliance testing. It is during these
brief periods that the accuracy of the acceleration measurement cannot
be maintained within 10 percent. The Alliance and the AIAM
commented that the only countermeasure available to manufacturers to
solve the clipping problem would be to expand the range of the
accelerometers such that any clipping or saturation would be minimized.
The AORC comments supported these claims. The petitioners suggested
that the trade-off in expanding the accelerometer detection range is a
decreased sensitivity which could negatively affect the performance of
air bag systems.

[[Page 47481]]

One of the primary concerns the agency considered in developing
this final rule was to ensure that air bags continue to deploy
properly. We did not intend to require the data element accuracies
listed in Table III to extend beyond the capabilities of the sensors
used in EDRs, specifically in sensors that are designed to meet
critical safety roles and optimized for those purposes. Likewise, we
find the Alliance comments on filtering and phase-shifting persuasive.
However, we wish to continue collecting accelerometer data so that the
agency might better understand crash scenarios and deployment decisions
made during crashes. Based on our evaluation of these comments, in lieu
of removing acceleration from Part 563, we have instead decided to
remove the reporting specifications for acceleration data elements in
Table III, including minimum range, accuracy and resolution.
We have also added a provision for the EDR report to indicate when
sensor clipping has occurred. We believe that an indicator of when
inertial sensors have become saturated during a crash will aid the
agency in understanding when measurements from the sensors have begun
to exceed their design ranges, and potentially exceed the accuracy
requirements in Part 563. The manner by which clipping is indicated is
at the option of the manufacturer.\9\ This appears as Footnote 1 in
Table III.
---------------------------------------------------------------------------

\9\ Examples of possible indicators would be a flag on the
acceleration measurement trace, or a new report field indicating
when clipping began from time zero.
---------------------------------------------------------------------------

We believe that through our actions, manufacturers may continue to
use current EDR technologies and not incur any significant cost
increases due to use of extended accelerometer ranges. We have
determined that the acceleration data element is important to the
agency's data collection goals. Therefore, we wish to continue
receiving the ``reported'' acceleration data, regardless of the format
with which it is captured.
As such, we have revised the acceleration data elements reported by
the download tool and the accuracy of the acceleration data elements to
be at the option of the manufacturer. For example, if a vehicle
manufacturer elected to record 70 msec of acceleration data at 2 msec
time increments with an accuracy of 0.5 g, we would expect
the reported acceleration data to follow that format. We believe that
this would alleviate concerns about certification accuracies, while
preserving a means of reporting acceleration data from the EDR for
crash reconstruction purposes.
We acknowledge that in making this change, the reported
acceleration output would not be standardized among EDRs. The duration
of the reported output and the resolution may vary depending upon the
EDR design of the vehicle. However, given the aforementioned concerns,
having acceleration data reported by the download tool with an
indicator of when sensor clipping or saturation occurs, would assist
crash reconstructionists with a means of computing a momentum balance
on the crash event and provide a better understanding of vehicle crash
behavior. Furthermore, the agency plans to monitor the acceleration
reported by the EDR download tool through various means, including
comparing the reported output with a differentiated delta-V time
history, and/or by comparing the reported output to laboratory
instrumentation during crash tests. This information will allow the
agency to better understand the significance and variation of data
clipping and filtering experienced in recorded acceleration data. If
the agency finds that the acceleration information from the EDR is not
useful as reported, we may revisit the need for further
standardization.
Thus, for the reasons discussed above, we are denying the petition
to delete the acceleration data elements from part 563. We do not
believe it unreasonable to report acceleration data during download if
a manufacturer voluntarily records acceleration data during a crash. It
would also mitigate data storage concerns since no additional storage
would be required by the EDR over what has already been established in
the design of the EDR.

B. The Effects of Data Clipping on Delta-V Calculation and Accuracy

The Alliance agreed that data clipping is a rare occurrence in real
world conditions, but that during the FMVSS No. 208 tests that will be
used to determine if EDRs have met the requirements in Part 563, there
may exist brief periods of deceleration that can exceed 100 g. It
recommended that the agency revise the delta-V accuracy requirement to
10 percent for events in which no sensor saturation or
data clipping occurs.
Agency Response: In the January 14, 2008 final rule, we denied
petitions to allow additional inaccuracy due to sensor saturation or
data clipping. Our belief at that time was 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 acceleration data, we believe this has been
sufficiently addressed.\10\
---------------------------------------------------------------------------

\10\ See 73 FR 2174.

We believed then that the revised data element accuracy and
resolution requirements would provide sufficient relief to avoid any
unnecessary rise in manufacturing costs, but we did not fully
anticipate the effects of sensor saturation or clipping on the choice
of sensor ranges to comply with the EDR rule. Since we do not wish at
this time to force manufacturers to increase the range of sensors
beyond what is optimal for air bag performance, we have added a
footnote to the data element accuracy requirement in Table III to apply
only within the range of the physical sensor utilized by the EDR. This
would be a minimum output range of -100 km/h to +100 km/h. We note that
previous agency research \11\ has shown that the delta-V data collected
from EDRs during FMVSS No. 208 crash tests are reliable and accurate
when compared with the delta-V data collected from reference sensors in
the laboratory. We believe that the additional requirement for a sensor
saturation or data clipping indicator will aid the agency in
understanding when such measurements exceed the range of the sensor.
---------------------------------------------------------------------------

\11\ Niehoff, P., Gabler, H.C., Brophy, J., Chidester, C.,
Hinch, J., Ragland, C., (2005), ``Evaluation of Event Data Recorders
in Full Systems Crash Tests,'' Paper No. 05-0271, 19th International
Technical Conference on Enhanced Saftey of Vehicles, U.S. DOT.
---------------------------------------------------------------------------

C. Incorporation of Preamble Explanations in Regulatory Text

The Alliance identified two items that were clarified in the
preamble to the January 14, 2008 final rule, but not reflected in the
regulatory text: exclusion of peripheral sensors from the scope of Part
563, and clarification of recording closely timed subsequent events
when the EDR power source is damaged. The AIAM similarly petitioned
that the agency clarify the requirements for storage and locking of
data from air bag deployment events.
1. Exclusion of Peripheral Sensors
In support of the agency's position on exclusion of peripheral
sensors, we stated the following in the January 2008 final rule:

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

[[Page 47482]]

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.\12\
---------------------------------------------------------------------------

\12\ See 73 FR 2175.

The Alliance petitioned the agency to add the following text to the
end of Sec. 563.6, ``Requirements for Vehicles,'' as follows:
``Peripheral sensors that do not produce `rigid body' centroid
acceleration signals are excluded from the requirements of this part.''
Agency Response: We are denying the Alliance request to add this
exclusion to Part 563. We believe that our definitions in the
regulatory text are sufficiently clear. We understand, since this rule
was first promulgated, manufacturers have adopted sophisticated sensing
strategies to determine when air bag deployments are warranted.
Moreover, we also understand vehicle electrical architectures have
become more sophisticated and data from these peripheral sensors may be
captured and ``recorded in non-volatile memory'' in the event of crash.
It was not our intent to capture this level of data when we first began
the EDR rulemaking, nor was it considered. Given the sophistication of
EDRs at that time, it was our intent to capture data as collected by
the restraint control module located inside the vehicle. However, we
note that the Alliance concerns are partially addressed through our
actions to remove the time interval, range, and accuracy requirements
for accelerometer measurements. By removing the requirements for
acceleration measurements, any peripheral acceleration data \13\
collected by an EDR is at the option of the manufacturer. We believe
that these revisions will relieve reporting requirements for any data
from peripheral accelerometers on the vehicle.
---------------------------------------------------------------------------

\13\ For example, we note that some manufacturers have begun
collecting acceleration data at the A, B, and C-pillar locations for
lateral deployment decisions.
---------------------------------------------------------------------------

2. Damage to EDR Power Source
In the January 2008 final rule, we stated the following with regard
to damaged EDR power sources and the recording of subsequent events:

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.\14\
---------------------------------------------------------------------------

\14\ See 73 FR 2171.

The Alliance requested that the agency amend Sec. 563.9 to clarify
the agency's intent with regard to power sources damaged in a first
event by adding the following new paragraph (c) stating: ``If power
source(s) or sensor(s) are damaged during an initial event, it is not
necessary to record data associated with subsequent event(s).'' The
Alliance commented that NHTSA's test procedures have historically
stated that the absence of a test provision from the agency's
procedures does not exempt manufacturers from their obligation to meet
all requirements specified in the standard.
Agency Response: We are denying this petition. We are not compelled
by the petitioner's rationale to add the requested language to the
regulatory text. Part 563 does not contain multi-impact test procedures
for determining what would constitute ``damage'' to the power source or
other sensors.
3. Clarification of the Storage and Locking of Data From Air Bag
Deployment Events
The AIAM petitioned the agency to clarify the requirements for
storage and locking of data from air bag deployment events. It
interpreted the August 2006 final rule as meaning that once data from
an air bag deployment event has been stored and locked, it is not
necessary to record a subsequent event, but if no air bag is deployed
in the first event, two events could be stored. It cited Sec.
563.9(a), which states that, in a frontal or side air bag deployment
crash, an EDR must capture and record the current deployment data, ``up
to two events,'' and that the memory for each air bag deployment event
must be locked to prevent any future overwriting of these data. The
AIAM stated that this could be read to mean that the EDR must be
capable of recording up to two air bag deployments, which would be a
departure from the intent of the August 2006 final rule. The AIAM
petitioned the agency to explain its rationale and include a resulting
cost estimate analysis, if the agency intends to adopt such a change.
Agency Response: The AIAM correctly interpreted Sec. 563.9(a) to
mean that after the EDR has captured, recorded, and locked data from an
air bag deployment event, the EDR is not required to record any
subsequent events. In the preamble to the August 2006 final rule, we
stated: ``If the first event is the deployment of an inflatable
restraint, these data are recorded to memory and the file is locked. No
further analyses (i.e., looking for subsequent triggers) or recording
occurs.'' \15\
---------------------------------------------------------------------------

\15\ See 71 FR 51019.
---------------------------------------------------------------------------

We noted in the preamble to the August 2006 final rule that while
not required to do so, an EDR may capture multi-event data during a
crash that involves an air bag deployment. To clarify the issue, we
have amended Sec. 563.9(a) by removing the phrase ``up to two
events,'' and we have clarified the language regarding side air bag
deployment crashes (as discussed in section H. below). The paragraph
now states ``In a frontal air bag deployment crash, capture and record
the current deployment data. In a side or side curtain/tube air bag
deployment crash, where lateral delta-V is recorded by the EDR, capture
and record the current deployment data. The memory for the air bag
deployment event must be locked to prevent any future overwriting of
the data.'' Thus, any frontal air bag deployment, or any side, or side
curtain/tube air bag deployment where lateral delta-V is recorded by
the EDR, would not require the EDR to record a second, subsequent
event, although it would allow such recording. We note that the phrase
``up to two events'' remains in Sec. 563.9(b) and so there continues
to be an obligation to record multiple non-air bag deployment events.

D. Time Zero for Events Involving Other Non-Reversible Deployment of
Restraints

The AIAM commented that the January 2008 final rule does not
explicitly state how ``time zero'' would be determined in the case of a
non-reversible restraint that is deployed despite a crash that does not
meet the ``trigger threshold.'' It recommended that the agency clarify
the definition for ``time zero'' to include other types of non-
reversible deployable restraints (e.g., pyrotechnic pretensioners).
Additionally, it recommended that the definition for ``event'' include
other non-reversible deployable devices. Specifically, the AIAM
proposed defining ``event'' as ``a crash or other physical occurrence
that causes the trigger threshold to be met or exceeded, or an air bag
or other non-reversible deployable device to be deployed, whichever
occurs first.'' AIAM

[[Page 47483]]

proposed including ``deployment of another type of non-reversible
deployable device'' in the definition of ``time zero.''
Agency Response: We agree with the need to change the definition of
event to include other non-reversible deployable devices. However, we
have used the word ``restraint'' rather than ``device'' in order to
maintain the focus on occupant protection. Such non-reversible
deployable restraints would be inclusive of frontal, side and side
curtain/tube air bags, but also could include devices such as knee air
bags and pretentioners. We believe this change is needed to make the
definition of event consistent with the data recording triggers found
in Sec. 563.9(a) and (b). In the January 2008 final rule, the agency
carefully considered the definition of an event. We agreed with the
industry that an air bag deployment could be considered an event
trigger, but were concerned about proliferation of trigger threshold
strategies that would lock the data and prevent capture of subsequent
crashes in which an air bag is deployed. For purposes of Sec. 563.9(a)
as currently written, we are primarily interested in the collection of
EDR data from high delta-V crashes. We ultimately decided that frontal
and side air bag deployments were consistent with our intent and did
not extend this to other types of deployable restraints. We continue to
believe that Sec. 563.9(a) is clear in stating that the locked
recorded data should be tied to a high delta-V event by virtue of a
frontal or side air bag deployment. However, to further clarify that
other non-reversible deployable restraints are considered events, i.e.,
those covered by Sec. 563.9(b), we have amended the definition of
``event'' as follows: ``Event means a crash or other physical
occurrence that causes the trigger threshold to be met or exceeded, or
any non-reversible deployable restraint to be deployed, whichever
occurs first.'' Consistent with this, we address clarification of Sec.
563.9 later in this document.
We further believe that Part 563 is clear that algorithm wake-up
strategies, and thus time zero, are at the option of the manufacturer.
These wake-up strategies may include such things as pretensioner
activation, or other non-air bag related deployments. However, to
address the AIAM concern and to clarify our strategy, we have replaced
``an air bag deployment'' in the definition of ``time zero'' with
``deployment of a non-reversible deployable restraint.''

E. Clarification of the Definition for End of Event

The AIAM commented that the definition for end of event does not
specify which delta-V mode(s) should be used to determine the end of
the event. It noted that many vehicles measure both longitudinal and
lateral delta-V, and in some cases can measure both concurrently as one
multi-directional event. Our definition for end of event states `` * *
* the moment at which the cumulative delta-V within a 20 ms time period
becomes 0.8 km/h (0.5 mph) or less * * *'' but does not define the
direction of the delta-V mode. Additionally, the AIAM commented that
the definition is not clear as to which of the criteria to use to
determine the end of the event, i.e., the cumulative delta-V or the
algorithm reset. It stated that the event should end based on the later
of the two end of event conditions being met. It requested that the
agency revise the definition to clarify how the end of event should be
determined.
The AORC also commented that the regulatory text does not specify
if the end of event criteria includes both longitudinal and lateral
delta-V components. It stated that both lateral and longitudinal should
be used if available.
Agency Response: In development of the August 2006 final rule, the
agency was mainly focused on events involving frontal impacts since
those types of impacts represent most of the crashes investigated.
Therefore, the agency originally intended to specify that the end of
event is determined by a drop in the longitudinal delta-V component, as
evidenced by our requirement for EDRs to capture the longitudinal
delta-V component, but making the lateral delta-V component an optional
data element.
In responding to the petitions for reconsideration to the August
2006 final rule, the agency agreed that deployment of a frontal or side
air bag could be considered an event trigger. This consideration
required changes in the definitions (e.g., event, time zero, and end of
event) that relate to how the event recording interval is determined.
However, we inadvertently neglected to consider how measurement of
lateral delta-V would impact the determination of when an event has
ended.
We have carefully considered the comments of the AIAM and the AORC
and agree that the definition for the end of an event must account for
the directional component of the delta-V measurement. Therefore, we
have revised the definition of end of event time to mean ``the moment
at which the resultant 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.'' (Emphasis
added). We believe adopting this change will provide the manufacturers
with necessary clarity on determining when an event has ended.

F. Clarification of Frontal Air Bag Suppression Switch Status

The Alliance commented that the data element in Table II for the
frontal air bag suppression switch status appears to only apply to
vehicles equipped with manual frontal air bag suppression switches. It
asked that the agency confirm this interpretation.
Agency Response: We agree that the suppression switch status data
element only applies to vehicles equipped with manual frontal air bag
suppression switches and is meant to indicate the position of a manual
frontal air bag suppression switch at the time of the event as
designated in S4.5.4 of FMVSS No. 208.

G. Compliance Test Procedures

The Alliance requested that the agency develop and publish a test
procedure for compliance with Part 563 as soon as possible. It
suggested that a test procedure would have the potential to elaborate
and clarify the regulatory requirements. It provided the example of
computing the delta-V accuracy requirement as an example of how this
would be helpful. It commented that it is not clear if the requirement
applies to point-by-point delta-V data, or the average of delta-V data
over the 250 ms interval, or to the cumulative delta-V at the end point
of 250 ms. It suggested that the accuracy requirement be a root mean
square average of the recorded delta-V values. The Alliance stated that
the publication of a test procedure could resolve this and other
issues.
The AORC suggested that the accuracy could be evaluated based on 10
percent of the full scale range of the physical application sensor and
would be evaluated after applying filtering and range characteristics
of the physical application sensor to the reference data.
Agency Response: In developing the agency's compliance crash test
procedure for Part 563, the agency considered the various methods
proposed by the petitioners in evaluating delta-V accuracy. The agency
found that a delta-V accuracy requirement applied on a point-by-point
basis proved to be suitably repeatable. This was based on testing that
NHTSA's Office of Vehicle Safety Compliance (OVSC) conducted with a
pair of triaxial accelerometers installed on, and near,

[[Page 47484]]

the EDR during frontal crash tests. The computed delta-V from these
accelerometers provided the agency with signals that could be directly
compared to the delta-V measured by the EDR. The results of these tests
demonstrated a sufficient correlation with the two laboratory sensors
and a means for testing compliance.\16\
---------------------------------------------------------------------------

\16\ A full analysis of the correlation tests will be provided
in the docket for this notice.
---------------------------------------------------------------------------

NHTSA has published the Part 563 test procedure in response to this
request.

H. Data Capture for Events Involving Side Air Bags

The AIAM recommended that the agency clarify its intent with regard
to the capture and lock of data collected from a side air bag versus a
side curtain/tube air bag. It recommended that section 563.9(a) be
clarified to include explicit reference to the separate definitions for
side air bags and side curtain/tube air bags. It commented that because
of the separate definitions for side and side curtain/tube air bags in
Sec. 563.5(b), a manufacturer could interpret Sec. 563.9 to regulate
crash events involving only a side air bag. It added that this appears
to be at odds with the definition for ``time zero'' which cites that an
EDR must capture any crash event that deploys any air bag (front, side,
or side curtain/tube).
Agency Response: We concur with clarifying the applicability of
Sec. 563.9(a) as suggested by the AIAM. The agency intended for Sec.
563.9(a) to capture air bag deployments in frontal crashes or side
crashes that involve either side or side curtain/tube air bags. We
consider the definitions for ``side air bag'' and ``side curtain/tube
air bag'' in Sec. 563.5(b) to be subsets of inflatable occupant
restraint devices designed to be deployed in any side impact crash or
rollover event. Therefore, a ``side curtain/tube air bag'' would simply
be a specific type of ``side air bag,'' and as such would be subject to
the requirements of Sec. 563.9(a).
We have also since recognized that it may not be appropriate to
require the locking of a side or side curtain/tube air bag deployment
event when the lateral delta-V information is not recorded. For
example, in the case of a purely lateral crash, an EDR that minimally
complies with Part 563 would not record any of the lateral crash
information that would be useful for reconstructing a side impact
event. It would also lock the frontal data element information relative
to this side impact event in memory and would require the consumer to
repair (or reset) the EDR, if the consumer would like to restore the
ability to record 2 events in the future.
Therefore, to clarify our intent in the final rule, we are amending
Sec. 563.9(a) to read as follows:

In a frontal air bag deployment crash, capture and record the
current deployment data. In a side or side curtain/tube air bag
deployment crash, where lateral delta-V is recorded by the EDR,
capture and record the current deployment data. The memory for the
air bag deployment event must be locked to prevent any future
overwriting of the data.

I. Prevention of EDR Data Tampering

In response to the August 2006 final rule, Mr. Thomas Kowalick
submitted a petition requesting that the agency require manufacturers
to provide mechanical locks for the on-board diagnostic (OBD2) port for
the sole use and control of the owner/operator of the vehicle. In
response to his 2006 petition for reconsideration, the agency stated
that while Mr. Kowalick presented information that devices exist that
may be used to erase or tamper with EDR data, he did not provide any
information that these devices were in fact being used for this
purpose. We concluded that there were several other ways (e.g., door
locks, ignition keys) that protect access to the OBD2 port. Further, we
required that EDR data from a crash that involves an air bag deployment
be locked to prevent overwriting of these data.
In response to the January 2008 final rule, Mr. Kowalick again
petitioned the agency to reconsider a mechanical lockout system for the
download port of EDRs that could only be accessed by the owner of the
vehicle. He again submitted information that indicates that devices are
being offered to consumers to alter odometer readings, erase EDR data,
or prevent EDR data from being recorded by the vehicle. Mr. Kowalick
cited the agency position that if tampering were to become apparent,
then the agency would reconsider its position on the tampering issue.
He commented that the agency should reconsider its denial of a
requirement for a mechanical lockout tool because the current rule is
inadequate to protect vehicle owners and operators from tampering, and
because the agency did not provide a definition for the term ``lock.''
Agency Response: We are denying this petition. Despite the
purported availability of such devices, we have still not seen evidence
of tampering during our real world data collections, and the petitioner
provided no new information that would suggest that we should
reconsider our previous denial of this request. We note that the
preponderance of information submitted by Messrs. Kowalick, Rosenbluth,
and Thompson \17\ dealt with odometer fraud issues which are outside
the scope of this rule.
---------------------------------------------------------------------------

\17\ After the end of the period to submit petitions for
reconsideration of the January 2008 final rule, two private
individuals, Mr. William Rosenbluth (Docket No. NHTSA-2008-0004-
0012) and Dr. W. David Thompson (Docket No. NHTSA-2008-0004-0013),
submitted comments in support of Mr. Kowalick's petition. We have
opted to address their comments herein.
---------------------------------------------------------------------------

Further, we do not believe that the rule is inadequate to protect
vehicle owners/operators from data tampering. Mr. Kowalick commented
that the agency should require a mechanical lockout device to be
installed on the OBD2 port. We clearly state in Sec. 563.9(a) that
``the memory for each air bag deployment event must be locked to
prevent any future overwriting of these data.'' We further clarified
the meaning of ``locked'' in the preamble by stating that we consider
it to be ``to protect EDR data from changes or deletion.'' We note that
there are many strategies which may be utilized to ``lock'' data to
prevent overwriting in addition to the mechanical lock Mr. Kowalick
proposed. In fact, Mr. Rosenbluth highlights one example as the writing
of data to Electrically Programmable Read Only Memory, which ``is not
electrically changeable,'' to prevent EDR data from being erased or
tampered with after a crash. We do not wish to restrict the method by
which a vehicle manufacturer chooses to lock EDR data collected during
a crash. Therefore, we are denying the petition to require mechanical
locks for the OBD2 port.

K. Other Technical Corrections

The Alliance, the AIAM, the AORC and Bosch commented on several
technical and editorial corrections to clarify the regulatory text as
follows:
1. The AIAM commented that section 563.9(b) should be clarified to
more clearly state that only air bag deployment event data should be
locked after capture. The AIAM believes the intent of the agency was to
require data from only air bag deployment events to be locked, rather
than events that involve other types of deployable restraint systems.
It commented that the regulatory language could be misinterpreted and
recommended that Sec. 563.9(b) be revised.
The AORC commented that Sec. 563.9(b) appears to be inconsistent
with the definition of an event. It interpreted this clause to mean
that a deployment of a restraint other than an air bag may be treated
as a trigger at the option of the manufacturer.

[[Page 47485]]

Agency Response: We concur with the AORC interpretation of Sec.
563.9(b) that the deployment of a restraint other than an air bag may
be treated as an EDR trigger at the option of the manufacturer. We
agree that Sec. 563.9(b) could be misinterpreted to mean that in an
event that involves both an air bag and another type of deployable
restraint, the captured data would not need to be locked. Similarly, we
concur with the AIAM that Sec. 563.9(b) could be misinterpreted to
require the EDR to lock data from crashes in which an air bag was not
deployed, but other deployable restraint systems were activated. We
intended for EDRs to record and lock data from frontal, side, and side
curtain/tube air bag deployment events, but data from events that do
not deploy a frontal, side, or side curtain/tube air bag could be
captured and recorded at the option of the manufacturer subject to the
conditions in Sec. 563.9(b). For this reason, we have revised Sec.
563.9(b) as shown below. We note that the inclusion of ``trigger
threshold'' has been removed since exceeding the trigger threshold is
by definition an event. Similarly, all other ``events'' not captured in
Sec. 563.9(a), must be captured, subject to the conditions in Sec.
563.9(b).

(b) In an event that does not meet the criteria in Sec.
563.9(a), capture and record the current event 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 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 any previous event data that does not deploy an air bag
with the current event data, or to not record the current event
data.
(3) EDR buffers containing previous frontal, side, or side
curtain/tube air bag deployment-event data must not be overwritten
by the current event data.

2. In the definitions set forth in Sec. 563.5(b), the Alliance
recommended that the definition for occupant size classification be
clarified from a driver as not being ``of small stature'' to ``larger
than a 5th percentile female (as defined in 49 CFR part 572, subpart
O),'' and a ``child'' as that defined in 49 CFR part 572, subpart N (6
year old child). It proposed the following definition:

Occupant size classification means, for the right front
passenger, the classification of the occupant as a child and not an
adult, as defined in 49 CFR part 572, subpart N, and for the driver,
the classification of the driver as being as large or larger than a
5th percentile female (as defined in 49 CFR part 572, subpart O).

The Alliance also noted that the occupant classification data
elements differ between Tables II and III. It recommended that the
agency standardize the occupant classification data elements in Tables
II and III to make Part 563 more objective.

Agency Response: We agree with adding more clarity to the Occupant
size classification definition to reflect the occupant size categories
used in testing the suppression of air bags in FMVSS No. 208. We
amended the definition as: ``Occupant size classification means, for
the right front passenger, the classification of the occupant as a
child (as defined in 49 CFR part 572, subpart N or smaller) or not as
an adult (as defined in 49 CFR part 572, subpart O), and for the
driver, the classification of the driver as being a 5th percentile
female (as defined in 49 CFR part 572, subpart O) or larger.'' We also
concur that the differences in occupant classification data elements in
Tables II and III were typographical errors and have made these
editorial corrections in the regulatory text.
3. The Alliance recommended that the word ``status'' be inserted
after ``foremost'' in the right front passenger seat track position
data element in Table II.
Agency Response: We concur with this change. The word ``status'' is
used in the companion data element in Table II for the driver and was
originally part of the 2006 final rule. This was inadvertently dropped
in the 2008 final rule. We have made this editorial correction to Table
II.
4. The Alliance recommended that the requirement in Table III for
the service brake status and ABS activity be revised to read: ``On or
Off.''
Agency Response: We concur. These are listed presently as ``On and
Off.'' However, ``On or Off'' is the correct way to list these options.
We have made the editorial corrections to Table III and to the
definition of ``Service brake, on and off'' in Sec. 563.5.
5. The Alliance recommended that the requirement in Table III for
stability control be revised to read: ``On, Off, or Engaged.''
Agency Response: We concur. This is presently listed as ``On, Off,
Engaged.'' However, we intended for these three states to be offered as
options. Therefore, we have made the requested editorial correction to
Table III and Table II.
6. The AIAM recommended that the agency clarify the data element in
Table I for ``Multi-event, number of event.'' It stated it is unclear
if the status is used to indicate that there were 1 or 2 events, or if
the status is used to indicate which event is being stored, (e.g.,
event 1 of 2 or event 2 of 2). It interpreted this to mean that two
events should be stored only in the case of a multi-event crash
situation.
Agency Response: We agree that the data element in Table I needs
clarification. We intended for the ``multi-event'' data element in
Table I to indicate which event is being stored. In Sec. 563.5(b), we
defined a multi-event crash as ``the occurrence of 2 events, the first
and last of which begin not more than 5 seconds apart.'' We note that
in the case of a single event, the multi-event data element would then
report a ``1.'' In the case of a multiple event, during the first
event, the EDR would not yet know that the second event is going to
occur. Therefore, the data from the first event would still report a
``1'' for the multi-event data element. Any data captured from the
subsequent event would then report a ``2'' for the multi-event data
element and the time from event 1 to 2. To clarify this, we have
amended the multi-event data element in Table I to be ``Multi-event,
number of event'' by removing the ``(1, 2).'' We have also revised this
nomenclature in Table III.
7. The AORC requested that the agency clarify that upon locking of
data from an event, the ``lock'' may be applied to either the data from
the individual event or the entire EDR at the option of the
manufacturer.
Agency Response: The January 2008 final rule revised Sec. 563.9(a)
to require that ``the memory for each air bag deployment event must be
locked to prevent any future overwriting of these data.'' We further
clarified the meaning of ``locked'' in the preamble (73 FR 2172) by
stating that we consider it to be ``to protect EDR data from changes or
deletion.'' We agree that either strategy suggested by the AORC may be
employed to lock the EDR data provided that the minimum conditions
within Sec. 563.9 have been met.
8. The AORC requested that the agency clarify that acceleration and
angular rate data recorded in accordance with Table II represents
single sample (raw) data rather than time-averaged data.
Agency Response: Our understanding of the acceleration data
reported by current EDRs is that the data is time-averaged for
deployment decisions. However, as previously discussed, we have amended
the requirements for the acceleration data elements to be at the option
of the vehicle manufacturer. We note that part 563 does not regulate
``angular rate'' data. Rather, it specifies limits for ``vehicle roll
angle'' data. We believe that this data element is time-averaged data.

[[Page 47486]]

9. The AORC commented that in newer active steering systems the
steering wheel angle and the tire position may not correlate.
Additionally, Bosch commented that the Table III accuracy and
resolution requirements for the steering input data element are
inconsistent with other data elements. It recommended that the agency
revise the range definition for this data element to 100
percent.
Agency Response: In response to the petitioners, we have revised
the minimum range requirement for the ``Steering input'' data element
from -250 degrees CW to 250 degrees CCW to a value of 100
percent in Table III. We agree with Bosch that this change would be
more consistent with the accuracy and resolution requirements being
expressed as percentages. We also believe this change will better
address state of the art active steering systems noted by the AORC.
10. Bosch commented that current EDR designs often utilize two
different types of lateral acceleration sensors: a high-g sensor
( 50 g) to detect side impact events, and a low-g sensor
( 5 g) to detect rollover events. It interpreted that the
final rule is mainly concerned with side impact events, and recommend
that the agency revise the lateral acceleration data element range to
50 g.
Agency Response: We agree that current EDR designs may utilize two
different types of lateral acceleration sensors for side impact and
rollover events. However, for the reasons discussed previously, we have
amended the minimum range requirements to be at the option of the
manufacturer.
11. Other editorial corrections: We have revised the data element
descriptions (first column) in Table III to remove references to the
data range since Table III already references the range for each of the
data elements.

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.

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. Amend paragraph (b) of Sec. 563.5 by revising the definitions of
``end of event time,'' ``event,'' ``occupant size classification,'' and
``time zero,'' removing the definition of ``service brake, on and
off'', and adding a definition in alphabetical order for ``service
brake, on or off'' to read as follows:

Sec. 563.5 Definitions.

* * * * *
(b) * * *
End of event time means the moment at which the resultant
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.
* * * * *
Event means a crash or other physical occurrence that causes the
trigger threshold to be met or exceeded, or any non-reversible
deployable restraint to be deployed, whichever occurs first.
* * * * *
Occupant size classification means, for the right front passenger,
the classification of the occupant as a child (as defined in 49 CFR
part 572, subpart N or smaller) or not as an adult (as defined in 49
CFR part 572, subpart O), and for the driver, the classification of the
driver as being a 5th percentile female (as defined in 49 CFR Part 572,
subpart O) or larger.
* * * * *
Service brake, on or 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.
* * * * *
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) Deployment of a non-reversible deployable restraint.
* * * * *

0
3. In Sec. 563.7, revise Table I in paragraph (a) and Table II in
paragraph (b) to read as follows:

Sec. 563.7 Data elements.

(a) * * *

Table I--Data Elements Required for All Vehicles Equipped With an EDR
------------------------------------------------------------------------
Recording interval/time Data sample
Data element \1\ (relative to time rate (samples
zero) per second)
------------------------------------------------------------------------
Delta-V, longitudinal.......... 0 to 250 ms or 0 to End 100
of Event Time plus 30
ms, whichever is
shorter.

[[Page 47487]]

Maximum delta-V, longitudinal.. 0-300 ms or 0 to End of N/A
Event Time plus 30 ms,
whichever is shorter.
Time, maximum delta-V.......... 0-300 ms or 0 to End of N/A
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, -1.0 sec............... N/A
on/off \2\.
Frontal air bag deployment, Event.................. N/A
time to deploy, in the case of
a single stage air bag, or
time to first stage
deployment, in the case of a
multi-stage air bag, driver.
Frontal air bag deployment, Event.................. N/A
time to deploy, in the case of
a single stage air bag, or
time to first stage
deployment, in the case of a
multi-stage air bag, right
front passenger.
Multi-event, number of event... Event.................. N/A
Time from event 1 to 2......... As needed.............. N/A
Complete file recorded (yes, Following other data... N/A
no).
------------------------------------------------------------------------
\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, and may also illuminate to
indicate a malfunction in another part of the deployable restraint
system.
\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) * * *

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\........... N/A....................... N/A
Longitudinal acceleration............... If recorded............... N/A....................... N/A
Normal acceleration..................... If recorded............... N/A....................... N/A
Delta-V, lateral........................ If recorded............... 0-250 ms or 0 to End of 100
Event Time plus 30 ms,
whichever is shorter.
Maximum delta-V, lateral................ If recorded............... 0-300 ms or 0 to End of N/A
Event Time plus 30 ms,
whichever is shorter.
Time maximum delta-V, lateral........... If recorded............... 0-300 ms or 0 to End of N/A
Event Time plus 30 ms,
whichever is shorter.
Time for maximum delta-V, resultant..... If recorded............... 0-300 ms or 0 to End of N/A
Event Time plus 30 ms,
whichever is shorter.
Engine rpm.............................. If recorded............... -5.0 to 0 sec............. 2
Vehicle roll angle...................... If recorded............... -1.0 up to 5.0 sec \3\.... 10
ABS activity (engaged, non-engaged)..... If recorded............... -5.0 to 0 sec............. 2
Stability control (on, off, or engaged). If recorded............... -5.0 to 0 sec............. 2
Steering input.......................... If recorded............... -5.0 to 0 sec............. 2
Safety belt status, right front If recorded............... -1.0 sec.................. N/A
passenger (buckled, not buckled).
Frontal air bag suppression switch If recorded............... -1.0 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).

[[Page 47488]]

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............... -1.0 sec.................. N/A
status, driver.
Seat track position switch, foremost, If recorded............... -1.0 sec.................. N/A
status, right front passenger.
Occupant size classification, driver.... If recorded............... -1.0 sec.................. N/A
Occupant size classification, right If recorded............... -1.0 sec.................. N/A
front passenger.
Occupant position classification, driver If recorded............... -1.0 sec.................. N/A
Occupant position classification, right If recorded............... -1.0 sec.................. N/A
front passenger.
----------------------------------------------------------------------------------------------------------------
\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\ ``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; -1.0 sec to 5.0 sec is suggested.
\4\ List this element n - 1 times, once for each stage of a multi-stage air bag system.

0
4. In Sec. 563.8, revise Table III in paragraph (a) to read as
follows:

Sec. 563.8 Data format

(a) * * *

Table III--Reported Data Element Format
----------------------------------------------------------------------------------------------------------------
Data element Minimum range Accuracy \1\ Resolution
----------------------------------------------------------------------------------------------------------------
Lateral acceleration................. At option of At option of At option of
manufacturer. manufacturer. manufacturer.
Longitudinal acceleration............ At option of At option of At option of
manufacturer. manufacturer. manufacturer.
Normal Acceleration.................. At option of At option of At option of
manufacturer. manufacturer. manufacturer.
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 or Off.............. N/A.................... On or Off.
ABS activity......................... On or Off.............. N/A.................... On or Off.
Stability control.................... On, Off, or Engaged.... N/A.................... On, Off, or Engaged.
Steering input....................... +/-100%................ +/-5%.................. 1%.
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.

[[Page 47489]]

Safety belt status, right front On or Off.............. N/A.................... On or Off.
passenger.
Frontal air bag warning lamp......... On or Off.............. N/A.................... On or Off.
Frontal air bag suppression switch On, Off, or Auto....... N/A.................... On, Off, or Auto.
status, right front passenger.
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.
nth stage, driver.
Frontal air bag deployment, time to 0 to 250 ms............ +/-2 ms................ 1 ms.
nth stage, right front passenger.
Frontal air bag deployment, nth stage Yes or No.............. N/A.................... Yes or No.
disposal, driver.
Frontal air bag deployment, nth stage Yes or No.............. N/A.................... Yes or No.
disposal, right front passenger.
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 classification, driver. 5th percentile female N/A.................... Yes or No.
or larger.
Occupant size classification, right Child.................. N/A.................... Yes or No.
front passenger.
Occupant position classification, Out of position........ N/A.................... Yes or No.
driver.
Occupant position classification, Out of position........ N/A.................... Yes or No.
right front passenger.
Multi-event, number of event......... 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............... Yes or No.............. N/A.................... Yes or No.
----------------------------------------------------------------------------------------------------------------
\1\ Accuracy requirement only applies within the range of the physical sensor. If measurements captured by a
sensor exceed the design range of the sensor, the reported element must indicate when the measurement first
exceeded the design range of the sensor.

* * * * *

0
5. 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 air bag deployment crash, capture and record the
current deployment data. In a side or side curtain/tube air bag
deployment crash, where lateral delta-V is recorded by the EDR, capture
and record the current deployment data. The memory for the air bag
deployment event must be locked to prevent any future overwriting of
the data.
(b) In an event that does not meet the criteria in Sec. 563.9(a),
capture and record the current event 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 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
any previous event data that does not deploy an air bag with the
current event data, or to not record the current event data.
(3) EDR buffers containing previous frontal, side, or side curtain/
tube air bag deployment-event data must not be overwritten by the
current event data.

Issued on: July 25, 2011.
David L. Strickland,
Administrator.
[FR Doc. 2011-19214 Filed 8-4-11; 8:45 am]
BILLING CODE 4910-59-P