2011-19214. 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.

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: [phone]. Facsimile: [phone].

For legal issues, contact:

Mr. David Jasinski, Office of the Chief Counsel, NCC-112. Telephone: [phone]. Facsimile: [phone].

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.

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.

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.

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 § 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:

○ That events involving deployable restraints other than air bags could be treated as an event trigger at the option of the manufacturer,

○ That the data lock may apply to either the individual event data or the entire EDR at the option of the manufacturer,

○ Whether the acceleration/angular rate data elements in Table II are single sampled (raw) data or time averaged data, and

○ 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.

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 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).

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.

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.

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.

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.

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]

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.

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 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]

The Alliance petitioned the agency to add the following text to the end of § 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.

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]

The Alliance requested that the agency amend § 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 § 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 § 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]

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 § 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 § 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 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 § 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 § 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 § 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 § 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 § 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, 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]

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 § 563.5(b), a manufacturer could interpret § 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 § 563.9(a) as suggested by the AIAM. The agency intended for § 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 § 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 § 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 § 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.

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 § 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 § 563.9(b) be revised.

The AORC commented that § 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.

Agency Response: We concur with the AORC interpretation of § 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 § 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 § 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 § 563.9(b). For this reason, we have revised § 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 § 563.9(a), must be captured, subject to the conditions in § 563.9(b).

(b) In an event that does not meet the criteria in § 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 § 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 § 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 § 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 § 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 § 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.

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

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.

2. Amend paragraph (b) of § 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:

§ 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.

* * * * *

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

§ 563.7

Data elements.

(a) * * *

Table I—Data Elements Required for All Vehicles Equipped With an EDR

Data element	Recording interval/time 1 (relative to time zero)	Data sample rate (samples per second)
Delta-V, longitudinal	0 to 250 ms or 0 to End of Event Time plus 30 ms, whichever is shorter	100
Maximum delta-V, longitudinal	0-300 ms or 0 to End of Event Time plus 30 ms, whichever is shorter	N/A
Time, maximum delta-V	0-300 ms or 0 to End of Event Time plus 30 ms, whichever is shorter	N/A
Speed, vehicle indicated	−5.0 to 0 sec	2
Engine throttle, % full (or accelerator pedal, % full)	−5.0 to 0 sec	2
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/off 2	−1.0 sec	N/A
Frontal air bag deployment, time to deploy, in the case of a single stage air bag, or time to first stage deployment, in the case of a multi-stage air bag, driver	Event	N/A
Frontal air bag deployment, time to deploy, in the case of a single stage air bag, or time to first stage deployment, in the case of a multi-stage air bag, right front passenger	Event	N/A
Multi-event, number of event	Event	N/A
Time from event 1 to 2	As needed	N/A
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, 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

Data element name	Condition for requirement	Recording interval/time 1 (relative to time zero)	Data sample rate (per 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 Event Time plus 30 ms, whichever is shorter	100
Maximum delta-V, lateral	If recorded	0-300 ms or 0 to End of Event Time plus 30 ms, whichever is shorter	N/A
Time maximum delta-V, lateral	If recorded	0-300 ms or 0 to End of Event Time plus 30 ms, whichever is shorter	N/A
Time for maximum delta-V, resultant	If recorded	0-300 ms or 0 to End of Event Time plus 30 ms, whichever is shorter	N/A
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 passenger (buckled, not buckled)	If recorded	−1.0 sec	N/A
Frontal air bag suppression switch status, right front passenger (on, off, or auto)	If recorded	−1.0 sec	N/A
Frontal air bag deployment, time to nth stage, driver 4	If equipped with a driver's frontal air bag with a multi-stage inflator	Event	N/A
Frontal air bag deployment, time to nth stage, right front passenger 4	If equipped with a right front passenger's frontal air bag with a multi-stage inflator	Event	N/A
Frontal air bag deployment, nth stage disposal, driver, Y/N (whether the nth stage deployment was for occupant restraint or propellant disposal purposes)	If recorded	Event	N/A
Frontal air bag deployment, nth stage disposal, right front passenger, Y/N (whether the nth stage deployment was for occupant restraint or propellant disposal purposes)	If recorded	Event	N/A
Side air bag deployment, time to deploy, driver	If recorded	Event	N/A
Side air bag deployment, time to deploy, right front passenger	If recorded	Event	N/A
Side curtain/tube air bag deployment, time to deploy, driver side	If recorded	Event	N/A
Side curtain/tube air bag deployment, time to deploy, right side	If recorded	Event	N/A
Pretensioner deployment, time to fire, driver	If recorded	Event	N/A
Pretensioner deployment, time to fire, right front passenger	If recorded	Event	N/A
Seat track position switch, foremost, status, driver	If recorded	−1.0 sec	N/A
Seat track position switch, foremost, status, right front passenger	If recorded	−1.0 sec	N/A
Occupant size classification, driver	If recorded	−1.0 sec	N/A
Occupant size classification, right front passenger	If recorded	−1.0 sec	N/A
Occupant position classification, driver	If recorded	−1.0 sec	N/A
Occupant position classification, right front passenger	If recorded	−1.0 sec	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 “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.

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

§ 563.8

Data format

(a) * * *

Table III—Reported Data Element Format

Data element	Minimum range	Accuracy 1	Resolution
Lateral acceleration	At option of manufacturer	At option of manufacturer	At option of manufacturer.
Longitudinal acceleration	At option of manufacturer	At option of manufacturer	At option of manufacturer.
Normal Acceleration	At option of manufacturer	At option of manufacturer	At option of 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 Event Time plus 30 ms, whichever is shorter	+/−3 ms	2.5 ms.
Time, maximum delta-V, lateral	0-300 ms, or 0—End of Event Time plus 30 ms, whichever is shorter	+/−3 ms	2.5 ms.
Time, maximum delta-V, resultant	0-300 ms, or 0—End of Event Time plus 30 ms, whichever is shorter	+/−3 ms	2.5 ms.
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 (accelerator pedal percent full)	0 to 100%	+/−5%	1%.
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.
Safety belt status, right front passenger	On or Off	N/A	On or Off.
Frontal air bag warning lamp	On or Off	N/A	On or Off.
Frontal air bag suppression switch status, right front passenger	On, Off, or Auto	N/A	On, Off, or Auto.
Frontal air bag deployment, time to deploy/first stage, driver	0 to 250 ms	+/−2 ms	1 ms.
Frontal air bag deployment, time to deploy/first stage, right front passenger	0 to 250 ms	+/−2 ms	1 ms.
Frontal air bag deployment, time to nth stage, driver	0 to 250 ms	+/−2 ms	1 ms.
Frontal air bag deployment, time to nth stage, right front passenger	0 to 250 ms	+/−2 ms	1 ms.
Frontal air bag deployment, nth stage disposal, driver	Yes or No	N/A	Yes or No.
Frontal air bag deployment, nth stage disposal, right front passenger	Yes or No	N/A	Yes or No.
Side air bag deployment, time to deploy, driver	0 to 250 ms	+/−2 ms	1 ms.
Side air bag deployment, time to deploy, right front passenger	0 to 250 ms	+/−2 ms	1 ms.
Side curtain/tube air bag deployment, time to deploy, driver side	0 to 250 ms	+/−2 ms	1 ms.
Side curtain/tube air bag deployment, time to deploy, right side	0 to 250 ms	+/−2 ms	1 ms.
Pretensioner deployment, time to fire, driver	0 to 250 ms	+/−2 ms	1 ms.
Pretensioner deployment, time to fire, right front passenger	0 to 250 ms	+/−2 ms	1 ms.
Seat track position switch, foremost, status, driver	Yes or No	N/A	Yes or No.
Seat track position switch, foremost, status, right front passenger	Yes or No	N/A	Yes or No.
Occupant size classification, driver	5th percentile female or larger	N/A	Yes or No.
Occupant size classification, right front passenger	Child	N/A	Yes or No.
Occupant position classification, driver	Out of position	N/A	Yes or No.
Occupant position classification, right front passenger	Out of position	N/A	Yes or No.
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.

* * * * *

5. Revise § 563.9 to read as follows:

§ 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 § 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.

Footnotes

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.

2.  See 71 FR 50998.

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

4.  See Docket number NHTSA-2004-18029.

5.  See Docket number NHTSA-2006-25666.

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

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

8.  See Docket number NHTSA-2008-0004.

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.

10.  See 73 FR 2174.

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.

12.  See 73 FR 2175.

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.

14.  See 73 FR 2171.

15.  See 71 FR 51019.

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

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.