Start Printed Page 3854
National Highway Traffic Safety Administration (NHTSA), Department of Transportation (DOT).
Notice of Proposed Rulemaking (NPRM).
This document proposes to establish a new Federal Motor Vehicle Safety Standard (FMVSS), No. 150, to mandate vehicle-to-vehicle (V2V) communications for new light vehicles and to standardize the message and format of V2V transmissions. This will create an information environment in which vehicle and device manufacturers can create and implement applications to improve safety, mobility, and the environment. Without a mandate to require and standardize V2V communications, the agency believes that manufacturers will not be able to move forward in an efficient way and that a critical mass of equipped vehicles would take many years to develop, if ever. Implementation of the new standard will enable vehicle manufacturers to develop safety applications that employ V2V communications as an input, two of which are estimated to prevent hundreds of thousands of crashes and prevent over one thousand fatalities annually.
Comments must be received on or before April 12, 2017.
You may submit comments to the docket number identified in the heading of this document by any of the following methods:
Online: Go to http://www.regulations.gov and follow the online instructions for submitting comments.
Mail: Docket Management Facility, M-30, U.S. Department of Transportation, West Building, Ground Floor, Rm. W12-140, 1200 New Jersey Avenue SE., Washington, DC 20590.
Hand Delivery or Courier: West Building, Ground Floor, Rm. W12-140, 1200 New Jersey Avenue SE., between 9 a.m. and 5 p.m. Eastern Time, Monday through Friday, except Federal Holidays.
Fax: (202) 493-2251.
Regardless of how you submit your comments, you should mention the docket number of this document. You may call the Docket Management Facility at 202-366-9826.
Instructions: Direct your comments to Docket No. NHTSA-2016-0126. See the SUPPLEMENTARY INFORMATION section on “Public Participation” for more information about submitting written comments.
Docket: All documents in the dockets are listed in the http://www.regulations.gov index. Although listed in the index, some information is not publicly available, e.g., confidential business information (CBI) or other information whose disclosure is restricted by statute. Publicly available docket materials are available either electronically in regulations.gov or in hard copy at DOT's Docket Management Facility, 1200 New Jersey Avenue SE., West Building, Ground Floor, Rm. W12-140, Washington, DC 20590. The Docket Management Facility is open between 9 a.m. and 5 p.m. Eastern Time, Monday through Friday, except Federal Holidays.
Start Further Info
FOR FURTHER INFORMATION CONTACT:
For technical issues, Mr. Gregory Powell, Office of Rulemaking, NHTSA, 1200 New Jersey Avenue SE., Washington, DC 20590. Telephone: (202) 366-5206; Fax: (202) 493-2990; email: firstname.lastname@example.org. For legal issues, Ms. Rebecca Yoon, Office of the Chief Counsel, NHTSA, 1200 New Jersey Avenue SE., Washington, DC 20590. Telephone: (202) 366-2992; email: email@example.com.
End Further Info
Start Supplemental Information
Table of Contents
I. Executive Summary
A. The Safety Need
1. Overall Crash Population That V2V Could Help Address
2. Pre-Crash Scenarios Potentially Addressed by V2V Communications
B. Ways To Address the Safety Need
1. Radar and Camera Based Systems
2. Communication-Based Systems
3. Fusion of Vehicle-Resident and Communication-Based Systems
4. Automated Systems
C. V2V Research Up Until This Point
1. General Discussion
2. Main Topic Areas in Readiness Report
3. Research Conducted Between the Readiness Report and This Proposal
D. V2V International and Harmonization Efforts
E. V2V ANPRM
1. Summary of the ANPRM
2. Comments to the ANPRM
F. SCMS RFI
III. Proposal To Regulate V2V Communications
A. V2V Communications Proposal Overview
B. Proposed V2V Mandate for New Light Vehicles, and Performance Requirements for Aftermarket for Existing Vehicles
C. V2V Communication Devices That Would Be Subject to FMVSS No. 150
1. Original Equipment (OE) Devices on New Motor Vehicles
2. Aftermarket Devices
D. Potential Future Actions
1. Potential Future Safety Application Mandate
2. Continued Technology Monitoring
E. Performance Criteria for Wireless V2V Communication
1. Proposed Transmission Requirements
2. Proposed V2V Basic Safety Message (BSM) Content
3. Message Signing and Authentication
4. Misbehavior Reporting
5. Proposed Malfunction Indication Requirements
6. Software and Security Certificate Updates
IV. Public Acceptance, Privacy and Security
A. Importance of Public Acceptance To Establishing the V2V System
B. Elements That Can Affect Public Acceptance in the V2V Context
1. False Positives
3. Hacking (Cybersecurity)
5. Research Conducted on Consumer Acceptance Issues
6. User Flexibilities for Participation in System
C. Consumer Privacy
1. NHTSA's PIA
2. Privacy by Design and Data Privacy Protections
3. Data Access, Data Use and Privacy
4. V2V Privacy Statement
5. Consumer Education
6. Congressional/Other Government Action
D. Summary of PIA
1. What is a PIA?
2. PIA Scope
3. Non-V2V Methods of Tracking
4. V2V Data Flows/Transactions With Privacy Relevance
5. Privacy-Mitigating Controls
6. Potential Privacy Issues by Transaction Type
E. Health Effects
2. Wireless Devices and Health and Safety Concerns
3. Exposure Limits
4. U.S. Department of Energy (DOE) Smart Grid Implementation
5. Federal Agency Oversight & Responsibilities
6. EHS in the U.S. and Abroad
V. Device Authorization
A. Approaches to Security Credentialing
B. Federated Security Credential Management (SCMS)
2. Technical Design
3. Independent Evaluation of SCMS Technical Design
4. SCMS RFI Comments and Agency ResponsesStart Printed Page 3855
5. SCMS ANPRM Comments and Agency Response
6. SCMS Industry Governance
C. Vehicle Based Security System (VBSS)
D. Multiple Root Authority Credential Management
VI. What is the agency's legal authority to regulate V2V devices, and how is this proposal consistent with that authority?
A. What can NHTSA regulate under the Vehicle Safety Act?
B. What does the Vehicle Safety Act allow and require of NHTSA in issuing a new FMVSS, and how is the proposal consistent with those requirements?
2. Standards “Meeting the Need for Motor Vehicle Safety”
3. “Objective” Standards
4. “Practicable” Standards
C. How are the regulatory alternatives consistent with our Safety Act authority?
D. What else needs to happen in order for a V2V system to be successful?
VII. Estimated Costs and Benefits
A. General Approach to Costs and Benefits Estimates
B. Quantified Costs
1. Component Costs
2. Communication Costs
3. Fuel Economy Impact
4. Overall Annual Costs
5. Overall Model Year (MY) Costs
C. Non-Quantified Costs
1. Health Insurance Costs Relating to EHS
2. Perceived Privacy Loss
3. Opportunity Costs of Spectrum for Other Uses
4. Increased Litigation Costs
D. Estimated Benefits
1. Assumptions and Overview
2. Injury and Property Damage Benefits
3. Monetized Benefits
4. Non-Quantified Benefits
E. Breakeven Analysis
F. Cost Effectiveness and Positive Net Benefits Analysis
1. Cost Effectiveness
2. Lifetime Net Benefits for a Specified Model Year
G. Uncertainty Analysis
H. Estimated Costs and Benefits of V2V Alternatives
VIII. Proposed Implementation Timing
A. New Vehicles
1. Lead Time
2. Phase-In Period
IX. Public Participation
A. How do I prepare and submit comments?
B. Tips for Preparing Your Comments
C. How can I be sure that my comments were received?
D. How do I submit confidential business information?
E. Will NHTSA consider late comments?
F. How can I read the comments submitted by other people?
X. Regulatory Notices and Analyses
A. Executive Order 12866, Executive Order 13563, and DOT Regulatory Policies and Procedures
B. Regulatory Flexibility Act
C. Executive Order 13132 (Federalism)
D. Executive Order 12988 (Civil Justice Reform)
E. Protection of Children From Environmental Health and Safety Risks
F. Paperwork Reduction Act
G. National Technology Transfer and Advancement Act
H. Unfunded Mandates Reform Act
I. National Environmental Policy Act
J. Plain Language
K. Regulatory Identifier Number (RIN)
L. Privacy Act
Proposed Regulatory Text
I. Executive Summary
The National Highway Traffic Safety Administration (NHTSA) is proposing to issue a new Federal Motor Vehicle Safety Standard (FMVSS) No. 150, to require all new light vehicles to be capable of Vehicle-to-Vehicle (“V2V”) communications, such that they will send and receive Basic Safety Messages to and from other vehicles. The proposal contains V2V communication performance requirements predicated on the use of on-board dedicated short-range radio communication (DSRC) devices to transmit Basic Safety Messages (BSM) about a vehicle's speed, heading, brake status, and other vehicle information to surrounding vehicles, and receive the same information from them. When received in a timely manner, this information would help vehicle systems identify potential crash situations with other vehicles and warn their drivers. The proposal also provides a path for vehicles to comply by deploying other technologies that meet certain performance and interoperability requirements, including interoperability with DSRC.
The agency believes that V2V has the potential to revolutionize motor vehicle safety. By providing drivers with timely warnings of impending crash situations, V2V-based safety applications could potentially reduce the number and severity of motor vehicle crashes, thereby reducing the losses and costs to society that would have resulted from these crashes.
More specifically, the agency believes that V2V will be able to address crashes that cannot be prevented by current in-vehicle camera and sensor-based technologies (“vehicle-resident” technologies). This is because V2V would employ omnidirectional radio signals that provide 360 degree coverage along with offering the ability to “see” around corners and “see” through other vehicles. V2V is not restricted by the same line-of-sight limitations as crash avoidance technologies that rely on vehicle-resident sensors. Additionally, V2V communications (BSMs) contain additional information, such as path predictions and driver actions (braking, steering) not available from traditional sensors. This information can be used by receiving vehicles to more reliably predict potential collision events as well as reduce false warnings. This ability to communicate certain information that cannot be acquired by vehicle-resident onboard sensors makes V2V particularly good at preventing impending intersection crashes, such as when a vehicle is attempting to make a left turn from one road to another. V2V also offers an operational range of 300 meters or farther between vehicles, nearly double the detection distance afforded by some current and near-term vehicle-resident systems. These unique characteristics allow V2V-equipped vehicles to perceive and warn drivers of some threats sooner than vehicle-resident sensors can. Furthermore, while the operational status or accuracy of vehicle-resident sensors may be affected by weather, sunlight, shadows, or cleanliness, V2V technology does not share these same system limitations.
As another source of information about the driving environment, moreover, the agency also believes that V2V can be fused with existing radar- and camera-based systems to provide even greater crash avoidance capability than either approach alone. For vehicles equipped with current on-board sensors, the fundamentally different, but complementary, information stream provided by V2V has the potential to significantly enhance the reliability and accuracy of the sensor-based information available. Instead of relying on each vehicle to sense its surroundings on its own, V2V enables surrounding vehicles to help each other by conveying safety information about themselves to other vehicles. V2V communication can thus detect threat vehicles that are not in the sensors' field of view, and can use V2V information to validate a return signal from a vehicle-based sensor. Further, V2V can provide information on the operational status (e.g., brake pedal status, transmission state, stability control status, vehicle at rest versus moving, etc.) of other V2V-equipped vehicles. Similarly, vehicle-resident systems can augment V2V systems by providing the information necessary to address other crash scenarios not covered by V2V communications, such as lane and road departure. These added capabilities can potentially lead to more timely warnings and a reduction in the number of false warnings, thereby adding confidence to the overall safety system, and increasing consumer satisfaction Start Printed Page 3856and acceptance. Although some have contended that vehicle-resident systems could evolve to the point where they have similar ranges to V2V transmissions during the time it will take V2V to penetrate the fleet, the agency believes that these technologies will remain complementary rather than competing even as vehicle-resident systems continue to improve.
In the longer-term, the agency believes that this fusion of V2V and vehicle-resident technologies will advance the further development of vehicle automation systems, including the potential for truly self-driving vehicles. Although most existing automated systems currently rely on data obtained from vehicle-resident technologies, we believe that data acquired from GPS and telecommunications like V2V could significantly augment such systems. Communication-based technology that connects vehicles with each other could not only improve the performance of automated onboard crash warning systems, but also be a developmental stage toward achieving widespread deployment of safe and reliable automated vehicles.
Despite these potential benefits, V2V offers challenges that are not present in vehicle-resident systems. Without government action, these challenges could prevent this promising safety technology from achieving sufficiently widespread use throughout the vehicle fleet to achieve these benefits. Most prominently, vehicles need to communicate a standard set of information to each other, using interoperable communications that all vehicles can understand. The ability of vehicles to both transmit and receive V2V communications from all other vehicles equipped with a V2V communications technology is referred to in this document as “interoperability,” and it is vital to V2V's success. Without interoperability, manufacturers attempting to implement V2V will find that their vehicles are not necessarily able to communicate with other manufacturers' vehicles and equipment, defeating the objective of the mandate and stifling the potential for innovation that the new information environment can create. In addition, there is the issue of achieving critical mass: That V2V can only begin to provide significant safety benefits when a significant fraction of vehicles comprising the fleet can transmit and receive the same information in an interoperable fashion.
The improvement in safety that results from enabling vehicles to communicate with one another depends directly on the fraction of the vehicle fleet that is equipped with the necessary technology, and on its ability to perform reliably. In turn, the effectiveness of any V2V communications technology depends on its ability to reliably transmit and receive recognizable and verifiable standardized information. Because the value to potential buyers of purchasing a vehicle that is equipped with V2V communications technology depends upon how many other vehicle owners have also purchased comparably-equipped models, V2V communications has many of the same characteristics as more familiar network communications technologies.
Viewed another way, an important consequence of any improvement in fleet-wide vehicle safety that results from an individual buyer's decision to purchase a V2V-capable model is the resulting increase in the safety of occupants of other V2V-equipped vehicles. Thus the society-wide benefits of individual vehicle buyers' decisions to purchase V2V-capable models extend well beyond the direct increase in their own safety; in economic parlance, their decisions can confer external benefits on other travelers. Thus a significant “network externality” arises from a new vehicle buyer's decision to purchase a vehicle equipped to connect to the existing V2V communications network.
Conversely, however, the benefits that any individual consumer would receive from voluntary adoption of V2V depend directly on the voluntary adoption of this technology by other consumers. Unless individual buyers believe that a significant number of other buyers will obtain V2V systems, they may conclude that the potential benefits they would receive from this system are unlikely to materialize. As a consequence, they are less likely to invest in V2V communications capabilities that would be would be justified by the resulting improvement in fleet-wide safety. The proposed requirement that all new vehicles be V2V-capable is thus likely to improve transportation safety more rapidly, effectively, and ultimately more extensively than would result from relying on the private decisions of individual vehicle buyers.
Another important consideration in achieving safety benefits from V2V is the long product lifespan of motor vehicles and the resulting slow fleet turnover. This places inherent constraints on the rate at which diffusion of new technologies throughout the entire vehicle fleet can occur. Thus in order to reach the critical mass of participants, a significant portion of the existing vehicle fleet will need replacement and a sustained, coordinated commitment on the part of manufacturers. Due to the inherent characteristics of the automobile market, manufacturers will inevitably face changing economic conditions and perhaps imperfect signals from vehicle buyers and owners, and these signals may not be based on complete information about the effectiveness of V2V technology, or incorporate the necessary foresight to value the potential life-saving benefits of V2V technology during the crucial phase of its diffusion. Without government intervention, the resulting uncertainty could undermine manufacturer plans or weaken manufacturers' incentive to develop V2V technology to its full potential.
We are, therefore, confident that creating the information environment through this mandate would lead to considerable advances in safety, and that those advances might not reach fruition if V2V communications were left to develop on their own.
Overview of the Proposed Rule
The agency believes the market will not achieve sufficient coverage absent a mandate V2V capability for all new light vehicles. A V2V system as currently envisioned would be a combination of many elements. This includes a radio technology for the transmission and reception of messages, the structure and contents of “basic safety messages” (BSMs), the authentication of incoming messages by receivers, and, depending on a vehicle's behavior, the triggering of one or more safety warnings to drivers.
The agency is also proposing to require that vehicles be capable of receiving over-the-air (OTA) security and software updates (and to seek consumer consent for such updates where appropriate). In addition, NHTSA is also proposing that vehicles contain “firewalls” between V2V modules and other vehicle modules connected to the data bus to help isolate V2V modules Start Printed Page 3857being used as a potential conduit into other vehicle systems.
The NPRM presents a comprehensive proposal for mandating DSRC-based V2V communications. That proposal includes a pathway for vehicles to comply using non-DSRC technologies that meet certain performance and interoperability standards. A key component of interoperability is a “common language” regardless of the communication technology used. Therefore, the agency's proposal includes a common specification for basic safety message (BSM) content regardless of the potential communication technology. The proposal also provides potential performance-based approaches for two security functions in an effort to obtain reaction and comment from industry and the public. Following is a more comprehensive discussion of the proposal and potential alternatives for different aspects of V2V security:
Proposal: NHTSA proposes to mandate DSRC technology—A DSRC unit in a vehicle sends out and receives “basic safety messages” (BSMs). DSRC communications within the 5.850 to 5.925 MHz band are governed by FCC 47 CFR parts 0, 1, 2 and 95 for onboard equipment and part 90 for road side units. In reference to the OSI model, the physical and data link layers (layers 1and 2) are addressed primarily by IEEE 802.11p as well as P1609.4; network, transport, and session layers (3,4 and 5) are addressed primarily by P1609.3; security communications are addressed by P1609.2; and additional session and prioritization related protocols are addressed by P1609.12. This mandate could also be satisfied using non-DSRC technologies that meet certain performance and interoperability standards.
Message Format and Information
- NHTSA proposes to standardize the content, initialization time, and transmission characteristics of the Basic Safety Message (BSM) regardless of the V2V communication technology potentially used. The agency's proposed content requirements for BSMs are largely consistent with voluntary consensus standards SAE 2735 and SAE 2945 which contains data elements such as speed, heading, trajectory, and other information, although NHTSA purposely does not require some elements to alleviate potential privacy concerns. Standardizing the message will facilitate V2V devices “speaking the same language,” to ensure interoperability. Vehicles will not be able to “understand” the basic safety message content hindering the ability to inform drivers of potential crashes.
Public Key Infrastructure Proposal: NHTSA proposes V2V devices sign and verify their basic safety messages using a Public Key Infrastructure (PKI) digital signature algorithm in accordance with performance requirements and test procedures for BSM transmission and the signing of BSMs. The agency believes this will establish a level of confidence in the messages exchanged between vehicles and ensure that basic safety message information is being received from devices that have been certified to operate properly, are enrolled in the security network, and are in good working condition. It is also important that safety applications be able to distinguish these from messages originated by “bad actors,” or defective devices, as well as from messages that have been modified or changed while in transit.
Alternative Approach—Performance-based Only: This first alternative for message authentication is less prescriptive and defines a performance-based approach but not a specific architecture or technical requirement for message authentication. This performance only approach simply states that a receiver of a BSM message must be able to validate the contents of a message such that it can reasonably confirm that the message originated from a single valid V2V device, and the message was not altered during transmission. The agency seeks comment on this potential alternative.
Alternative Approach—No Message Authentication: This second alternative stays silent on a specific message authentication requirement. BSM messages would still be validated with a checksum, or other integrity check, and be passed through a misbehavior detection system to attempt to filter malicious or misconfigured messages. Implementers would be free to include message authentication as an optional function. The agency seeks comment on this potential alternative.
Misbehavior Detection and Reporting
Primary Misbehavior Detection and Reporting Proposal: NHTSA proposes to mandate requirements that would establish procedures for communicating with a Security Credential Management System to report misbehavior; and learn of misbehavior by other participants. This includes detection methods for a device hardware and software to ensure that the device has not been altered or tampered with from intended behavior. This approach enhances the ability of V2V devices to identify and block messages from other misbehaving or malfunctioning V2V devices.
Misbehavior Detection Alternative Approach: An alternative for misbehavior detection imposes no requirement to report misbehavior or implement device blocking based to an authority. However, implementers would need to identify methods that check a devices' functionality, including hardware and software, to ensure that the device has not been altered or tampered with from intended behavior. Implementers would be free to include misbehavior detection and reporting and as optional functions. The agency seeks comment on this alternative.
NHTSA proposes that V2V equipment be “hardened” against intrusion (FIPS-140 Level 3) by entities attempting to steal its security credentials.
The agency is proposing that the effective date for manufacturers to begin implementing these new requirements would be two model years after the final rule is adopted, with a three year phase-in period to accommodate vehicle manufacturers' product cycles. Assuming a final rule is issued in 2019, this would mean that the phase-in period would begin in 2021, and all vehicles subject to that final rule would be required to comply in 2023.
The agency is not proposing to require specific V2V safety applications at this time. We believe the V2V communications we are proposing will create the standardized information environment that will, in turn, allow innovation and market competition to develop improved safety and other applications. Additionally, at this time, the agency believes that more research is likely needed in order to create regulations for safety applications. In support of this, we are seeking comment on information that could inform a future decision to mandate any specific safety applications.
Under the Vehicle Safety Act, 49 U.S.C. 30101 et seq., the agency has the legal authority to require new vehicles to be equipped with V2V technology and to use it, as discussed in Section VI below. NHTSA has broad statutory authority to regulate motor vehicles and items of motor vehicle equipment, and to establish FMVSSs to address vehicle safety needs.Start Printed Page 3858
Privacy and Security
V2V systems would be required to be designed from the outset to minimize risks to consumer privacy. The NPRM proposes to exclude from V2V transmitting information that directly identifies a specific vehicle or individual regularly associated with a vehicle, such as owner's or driver's name, address, or vehicle identification numbers, as well as data “reasonably linkable” 
to an individual. Additionally, the proposal contains specific privacy and security requirements with which manufacturers would be required to comply.
The Draft Privacy Impact Assessment that accompanies this proposal contains detailed information on the potential privacy risks posed by the V2V communications system, as well as the controls designed into that system to minimize risks to consumer privacy.
Estimated Costs and Benefits
In this NPRM, the agency proposes that all light vehicles be equipped with technology that allows for V2V communications, but has decided not to propose to mandate any specific safety applications at this time, instead allowing them to be developed and adopted as determined by the market. This market-based approach to application development and deployment makes estimating the potential costs and benefits of V2V quite difficult, because the V2V communication technology being mandated by the agency would improve safety only indirectly, by facilitating the deployment of previously developed OEM safety application. However, the agency is confident that these technologies will be developed and deployed once V2V communications are mandated and interoperable. Considerable research has already been done on various different potential applications, and the agency believes that functioning systems are likely to become available within a few years if their manufacturers can be confident that V2V will be mandated and interoperable.
In order to provide estimates of the rule's costs and benefits, the agency has considered a scenario where two V2V-enabled safety applications, IMA and LTA, are voluntarily adopted on hypothetical schedules similar to those observed in the actual deployment of other advanced communications technologies. The agency believes that IMA and LTA will reduce the frequency of crashes that cannot be avoided by vehicle-resident systems, and will thus generate significant safety benefits that would not be realized in the absence of universal V2V communications capabilities. In addition, the marginal costs of including the IMA and LTA applications are extremely low once the V2V system is in place, which the agency believes will speed their adoption.
The agency has not quantified any benefits attributable to the wide range of other potential uses of V2V, although we believe that such uses are likely to be numerous. Recognizing its experience with other technologies, the agency believes that focusing on two of the many potential uses of V2V technology that are inexpensive to implement provides a reasonable approach to estimating potential benefits of the proposed rule, and is likely to understate the breadth of potential benefits of V2V.
We estimate that the total annual costs to comply with this proposed mandate in the 30th year after it takes effect would range from $2.2 billion to $5.0 billion, corresponding to a cost per new vehicle of roughly $135-$300. This estimate includes costs for equipment installed on vehicles as well as the annualized equivalent value of initial investments necessary to establish the overarching security manager and the communications system, among other things, but, due to uncertainty, does not include opportunity costs associated with spectrum, which will be included in the final cost benefit analysis. The primary source of the wide range between the lower and upper cost estimates is based our assumption that manufacturers could comply with the rule using either one or two DSRC radios.
As discussed above, our benefit calculation examines a case where manufacturers would voluntarily include the IMA and LTA applications on a schedule that reflects adoption rates the agency has observed for other advanced, vehicle-resident safety technologies. Together, these applications could potentially prevent 424,901-594,569 crashes, and save 955-1,321 lives when fully deployed throughout the light-duty vehicle fleet. Converting these and the accompanying reductions in injuries and property damage to monetary values, we estimate that in 2051 the proposed rule could reduce the costs resulting from motor vehicle crashes by $53 to $71 billion (expressed in today's dollars).
The agency conducted two accompanying analyses to identify meaningful milestones in the future growth of benefits resulting from this proposed rule. These analyses highlight the effect that the passage of time has on the accumulated benefits from this proposed rule. Benefits in the first several calendar years after it takes effect will be quite low, because only a limited number of vehicles on the road will be equipped with V2V, but growth in these benefits will accelerate as time goes on.
First, NHTSA used a “breakeven” analysis to identify the calendar year during which the cumulative economic value of safety benefits from the use of V2V communications first exceeds the cumulative costs to vehicle manufacturers and buyers for providing V2V capability. The breakeven analysis indicated that this important threshold would be reached between 2029 and 2032, depending primarily on the effectiveness of the application technologies.
Next, NHTSA projected future growth in the proposed rule's benefits and costs over successive model years after it would take effect. This analysis identified the first model year for which the safety benefits from requiring vehicles to be equipped with V2V communications over their lifetime in the fleet would outweigh the higher initial costs for manufacturing them. It showed that this would occur in model year 2024 to 2026 if the proposed rule first took effect in model year 2021. This occurs sooner than the breakeven year, because focusing only on costs and benefits over the lifetimes of individual model years avoids including the burden of costs for installing V2V communications on vehicles produced during earlier model years.Start Printed Page 3859
Table I-1—Costs * and Benefits in Year 30 of Deployment
|Total annual costs||Per vehicle costs||Crashes prevented and lives saved||Monetary benefits
|$2.2 billion-$5.0 billion||$135-$301||Crashes: 424,901-594,569 Lives: 955-1,321||$53-$71|
|* Note: Does not include spectrum opportunity costs, which will be included in the analysis of the final rule.|
In order to account for the inherent uncertainty in the assumptions underlying this cost-benefit analysis, the agency also conducted extensive uncertainty analysis to illustrate the variation in the rule's benefits and costs associated with different assumptions about the future number of accidents that could be prevented, the assumed adoption rates and estimated effectiveness of the two safety applications, and our assumptions about the costs of providing V2V communications capability. Aside from opportunity costs, this analysis showed that the proposed rule would reach its breakeven year between 2030 and 2032 with 90 percent certainty, with even the most conservative scenario showing that the breakeven year would be five to six years later than the previously estimated years (2029-2032). Considering these same sources of uncertainty in the cost-effectiveness and net benefits analyses showed that the proposed rule would become cost-effective and would accrue positive net benefits between MY 2024 and MY 2027 with 90 percent certainty. This indicates that it is very likely to become cost-effectiveness at most one MY later than estimated in the primary analysis, and that even under the most conservative scenario, this would occur two to three model years later than the initial estimate of 2024-2026.
The agency considered two regulatory alternatives to today's proposal. First, the agency considered an “if-equipped” standard, which would entail simply setting a conditional standard stating that “if a new vehicle is equipped with devices capable of V2V communications, then it is required to meet the following requirements.” However, the agency did not adopt this alternative as the proposal because, as explained above, the agency believes that anything short of a mandate for universal V2V capability on all new vehicles would not lead a sufficient fraction of the vehicle fleet to be equipped with V2V to enable full realization of the technology's potential safety benefits. However, we seek further comment on adopting an “if-equipped” standard as the primary approach to V2V communications technology. We request commenters provide any relevant research and data that supports their position and rationale for this approach to regulation.
Second, we considered a regulatory alternative of requiring that V2V-capable vehicles also be equipped with the two safety applications analyzed in this proposed rule—Intersection Movement Assist (IMA) and Left Turn Assist (LTA)—in addition to V2V capability. This alternative would speed the introduction and increase the certainty of safety benefits. However, because performance requirements and test procedures for these safety applications are still nascent, we are not proposing this alternative at this time. However, the agency requests comment on whether sufficient information exists that could assist it in developing FMVSS-quality test procedures and performance standards for these applications.
We seek comment on all aspects of this proposed rule, as well as the Preliminary Regulatory Impact Assessment (PRIA) and Draft Privacy Impact Assessment (PIA) that accompany it. Although a number of specific questions and requests for comment appear in various locations throughout the text, we encourage comments broadly, particularly those that are supported by relevant documentation, information, or analysis. Instructions for submitting comments are located below in the “Public Participation,” Section IX.
A. The Safety Need
Safety technology has developed rapidly since NHTSA began regulating the auto industry 
—over the last several decades, vehicles have evolved to protect occupants much better in the event of a crash due to advanced structural techniques propagated by more stringent crashworthiness standards, and some crash avoidance technologies (e.g., electronic stability control) are now required standard equipment. In fact, a recent study of data from our Fatality Analysis Reporting System (FARS) estimates those safety technologies have saved 613,501 lives since 1960.
As a result of existing NHTSA standards for crashworthiness and crash avoidance technologies, along with market-driven improvements in safety, motor vehicles are safer now than they have ever been, as evidenced by a significant reduction in highway fatalities and injuries—from 52,627 fatalities in 1970,
to 32,675 fatalities in 2015—a 38 percent reduction.
Start Printed Page 3860
NHTSA believes the greatest gains in highway safety in coming years will result from broad-scale application of crash avoidance technologies along with continued improvements in vehicle crashworthiness that can reduce fatalities and injuries.
To encourage adoption of such technologies, in February 2015 the agency announced that it would add two types of automatic emergency braking systems—crash imminent braking and dynamic brake support—to the list of recommended advanced safety features in our New Car Assessment Program, known to most Americans as NHTSA's Five Star Safety Ratings. In March, 2016 the agency announced an agreement with vehicle manufacturers to voluntarily make automatic emergency braking (AEB) a standard safety on future vehicles.
These technologies, along with technologies required as standard equipment like electronic stability control (ESC), help vehicles react to crash-imminent situations, but do not help drivers react ahead of time to avoid crashes.
This proposed rule would require vehicles to transmit messages about their speed, heading, brake status, and other vehicle information to surrounding vehicles, and to be able to receive the same information from them. V2V range and “field-of-view” capabilities exceed current and near-term radar- and camera-based systems—in some cases, providing nearly twice the range. That longer range and 360 degree field of “view”, currently supported by DSRC, provides a platform enabling vehicles to perceive some threats that sensors, cameras, or radar cannot.
By providing drivers with timely warnings of impending crash situations, V2V-based safety applications could potentially reduce the number and severity of motor vehicle crashes, minimizing the losses and costs to society that would have resulted from these crashes. V2V message data can also be fused with existing radar- and camera-based systems to provide even greater crash-risk detection capability (and thus, driver confidence levels) than either approach alone.
1. Overall Crash Population That V2V Could Help Address
The first step in understanding how V2V could help drivers avoid crashes is determining how many crashes could potentially be addressed by V2V-based technologies. We estimate crash harm based on fatalities, injuries (described by MAIS),
and what we call “property-damage-only,” meaning that no people were hurt, but vehicles sustained damage that will have to be fixed and paid for. Based on 2010-2013 
General Estimates System (GES) and FARS, the agency estimated that there were 5.5 million police-reported crashes annually in the U.S. during those years. About 33,020 fatalities and 2.7 million MAIS 
1-5 injuries were associated with these crashes annually. In addition, about 6.3 million vehicles were damaged in property damage only crashes. These property damage only vehicles were noted as PDOVs.
Overall, these crashes directly cost $195 billion to society in terms of lost productivity, medical costs, legal and court costs, emergency service costs (EMS), insurance administration costs, congestion costs, property damage, and workplace losses. When you add the cost for less-tangible consequences like physical pain or lost quality-of-life, we estimate the total costs for those crashes to be $721 billion.
Because V2V is a communications-based technology, it is relevant to crashes where more than one vehicle is involved: if a single vehicle crashes by itself, like by losing control and leaving the roadway and hitting a tree, V2V would not have been able to help the driver avoid losing control because there would have been no other vehicle to communicate with. Of the 5.5 million crashes described above, 3.8 million (69 percent of all crashes) were multi-vehicle crashes that V2V-based warning technologies could help address, which would translate to approximately 13,329 fatalities, 2.1 million MAIS1-5 injuries, and 5.2 million PDOVs.
However, some multi-vehicle crashes involve vehicles that would not be covered by this rule, and therefore could not yet be assumed to have V2V capability. As this proposal is currently limited only to light vehicles,
the crash population encompasses approximately 3.4 million (62 percent of all crashes) light-vehicle to light-vehicle (LV2LV) crashes, which would translate to 7,325 fatalities, 1.8 million MAIS 1-5 injuries, and 4.7 million PDOVs. The economic and comprehensive costs for these crashes amount to approximately $109 billion and $319 billion, respectively. Figure II-1 helps to illustrate the process for deriving the target population of 3.4 million LV2LV crashes that could be addressed by this proposal. All percentages are percentages of “all police-reported crashes,” rather than percentages of the prior line.
Start Printed Page 3861
2. Pre-Crash Scenarios Potentially Addressed by V2V Communications
In a separate analysis that has been updated using an average of 2010 through 2013 General Estimate System data (which does not include FARS data), the agency started with the initial 37 pre-crash scenarios that have been defined based on police-reported crashes from previous analyses for all crashes.
Of the 37 scenarios, 17 were deemed potentially addressable by V2V communications. Further statistical analysis focusing on the frequency and severity of those 17 pre-crash scenarios identified the top 10 (priority) pre-crash scenarios that V2V could potentially address. Table II-1 provides a graphical depiction of the flow of the pre-crash scenario breakdown used in the analysis.
Table II—1 37 Pre-Crash Scenario Typology
|1. Vehicle Failure.|
|2. Control Loss with Prior Vehicle Action.|
|3. Control Loss without Prior Vehicle Action.|
|4. Running Red Light.|
|5. Running Stop Sign.|
|6. Road Edge Departure with Prior Vehicle Maneuver.|
|7. Road Edge Departure without Prior Vehicle Maneuver.|
|8. Road Edge Departure While Backing Up.|
|9. Animal Crash with Prior Vehicle Maneuver.|
|10. Animal Crash without Prior Vehicle Maneuver.|
|11. Pedestrian Crash with Prior Vehicle Maneuver.|
|12. Pedestrian Crash without Prior Vehicle Maneuver.|
|13. Pedalcyclist Crash with Prior Vehicle Maneuver.|
|14. Pedalcyclist Crash without Prior Vehicle Maneuver.|
|15. Backing Up into Another Vehicle.|
|16. Vehicle(s) Turning—Same Direction.|
|17. Vehicle(s) Parking—Same Direction.|
|18. Vehicle(s) Changing Lanes—Same Direction.|
|19. Vehicle(s) Drifting—Same Direction.|
|20. Vehicle(s) Making a Maneuver—Opposite Direction.|
|21. Vehicle(s) Not Making a Maneuver—Opposite Direction.|
|22. Following Vehicle Making a Maneuver.|
|23. Lead Vehicle Accelerating.|
|24. Lead Vehicle Moving at Lower Constant Speed.|
|25. Lead Vehicle Decelerating.|
|26. Lead Vehicle Stopped.|
|27. Left Turn Across Path from Opposite Directions at Signalized Junctions.|
|28. Vehicle Turning Right at Signalized Junctions.|
|29. Left Turn Across Path from Opposite Directions at Non-Signalized Junctions.|
|30. Straight Crossing Paths at Non-Signalized Junctions.|
|Start Printed Page 3862|
|31. Vehicle(s) Turning at Non-Signalized Junctions.|
|32. Evasive Action with Prior Vehicle Maneuver.|
|33. Evasive Action without Prior Vehicle Maneuver.|
|34. Non-Collision Incident.|
|35. Object Crash with Prior Vehicle Maneuver.|
|36. Object Crash without Prior Vehicle Maneuver.|
The 10 priority pre-crash scenarios listed in Table II-2 can be addressed by the corresponding V2V-based safety applications.
Table II-2—Pre-Crash Scenario/Safety Application Association
|Pre-crash scenarios||Pre-crash groups||Associated safety application|
|Lead Vehicle Stopped||Rear-end||Forward Collision Warning.|
|Lead Vehicle Moving||Rear-end||Forward Collision Warning.|
|Lead Vehicle Decelerating||Rear-end||Forward Collision Waring/Emergency Electronic Brake Light.|
|Straight Crossing Path @ Non Signal||Junction Crossing||Intersection Movement Assist.|
|Left-Turn Across Path/Opposite Direction||Left Turn @ crossing||Left Turn Assist.|
|Opposite Direction/No Maneuver||Opposite Direction||Do Not Pass Warning.|
|Opposite Direction/Maneuver||Opposite Direction||Do Not Pass Warning.|
|Change Lanes/Same Direction||Lane Change||Blind Spot/Lane Change Warning.|
|Turning/Same Direction||Lane Change||Blind Spot/Lane Change Warning.|
|Drifting/Same Direction||Lane Change||Blind Spot/Lane Change Warning.|
The six applications listed in Table II-2 were developed and tested in the Connected Vehicle Safety Pilot Model Deployment.
These safety warning applications were (1) Forward Collision Warning (FCW), (2) Emergency Brake Start Printed Page 3863Light (EEBL), (3) Intersection Move Assist (IMA), (4) Left Turn Assist (LTA), (5) Do Not Pass Warning (DNPW), and (6) Blind Spot/Lane Change Warning (BS/LCW). A description of each safety application and relationship to the pre-crash scenarios is provided below.
(1) Forward Collision Warning (FCW): Warns drivers of stopped, slowing, or slower vehicles ahead. FCW addresses rear-end crashes that are separated into three key scenarios based on the movement of lead vehicles: Lead-vehicle stopped (LVS), lead-vehicle moving at slower constant speed (LVM), and lead-vehicle decelerating (LVD).
(2) Emergency Electronic Brake Light (EEBL): Warns drivers of heavy braking ahead in the traffic queue. EEBL would enable vehicles to broadcast its emergency brake and allow the surrounding vehicles' applications to determine the relevance of the emergency brake event and alert the drivers. EEBL is expected to be particularly useful when the driver's visibility is limited or obstructed.
(3) Intersection Movement Assist (IMA): Warns drivers of vehicles approaching from a lateral direction at an intersection. IMA is designed to avoid intersection crossing crashes, the most severe crashes based on the fatality counts. Intersection crashes include intersection, intersection-related, driveway/alley, and driveway access related crashes. IMA crashes are categorized into two major scenarios: Turn-into path into same direction or opposite direction and straight crossing paths. IMA could potentially address five of the pre-crash scenarios identified in Table II-2.
(4) Left Turn Assist (LTA): Warns drivers to the presence of oncoming, opposite-direction traffic when attempting a left turn. LTA addresses crashes where one involved vehicle was making a left turn at the intersection and the other vehicle was traveling straight from the opposite direction.
(5) Do Not Pass Warning (DNPW): Warns a driver of an oncoming, opposite-direction vehicle when attempting to pass a slower vehicle on an undivided two-lane roadway. DNPW would assist drives to avoid opposite-direction crashes that result from passing maneuvers. These crashes include head-on, forward impact, and angle sideswipe crashes.
(6) Blind Spot/Lane Change Warning (BS/LCW): Alerts drivers to the presence of vehicles approaching or in their blind spot in the adjacent lane. BS/LCW addresses crashes where a vehicle made a lane changing/merging maneuver prior to the crashes.
The final table, Table II-3, merges the estimated target crash population for LV2LV crashes detailed in Table II-2 with the separate analysis that provided the breakdown of V2V pre-crash scenarios and relationships to prototype V2V safety applications. The 3.4 million LV2LV are distributed among the pre-crash scenarios that are associated with V2V safety applications and the economic and comprehensive costs. More specifically, Table II-3 provides a breakdown of crashes associated with FCW, IMA, LTA, and LCW scenarios that are used later when discussing potential benefits in Section VII. Crash scenarios associated with DNPW and EEBL are grouped with all remaining crashes under the “other” category due to the fact they are not used when discussing benefits. The agency grouped these two potential applications into the “other” category because of EEBL's advisory nature that cannot be directly attributed to avoiding a specific crash and the agency's current understanding of DNPW indicates it only addresses a limited amount of crashes per a specific situation and where there are three equipped vehicles present, limiting the amount of information available to develop comprehensive effectiveness estimates.
Overall the agency estimates that, together, these four potential safety applications that could be enabled by this proposal could potentially address nearly 89 percent of LV2LV crashes and 85 percent of their associated economic costs.
Table II-3—Crash Scenarios for LV2LV Safety Population
|V2V Safety applications—crashes||Crash scenarios||Crashes||MAIS 1-5 injuries||Fatalities||PDOVs||Economic costs (billion)||Comprehensive costs
|FCW Rear-End Crashes||Lead Vehicle Stopped||998,664||497,907||242||68,508||$27.4||$65.7|
| ||Lead Vehicle Moving||146,247||80,508||242||12,605||$4.6||$12.9|
| ||Lead Vehicle Decelerating||343,183||173,538||78||25,599||$9.5||$23.1|
|IMA Intersection Crossing Crashes||Turn-Into Path, Into Same Direction or Opposite Direction||425,145||218,852||472||48,423||$12.6||$34.8|
| ||Straight Cross Path||346,187||251,488||1,399||66,580||$14.4||$49.4|
|LTA Left-Turning Crashes||Turn Across Path, Initial Opposite Direction||298,542||224,336||613||64,233||$11.7||$37.9|
|BS/LCW Lane Change/Merge Crashes||Vehicle Changing Lane, Same Direction||475,097||175,044||397||20,816||$11.4||$26.6|
|Note: Due to rounding, the total might not be equal to the sum of each componment.|
B. Ways To Address the Safety Need
The most effective way to reduce or eliminate the property damage, injuries, and fatalities that occur annually from motor vehicle crashes is to lessen the severity of those crashes, or prevent those crashes from ever occurring. In recent years, vehicle manufacturers have begun to offer, or have announced plans to offer, various types of crash avoidance technologies that are Start Printed Page 3864designed to do just that. These technologies are designed to address a variety of crashes, including rear end, lane change, and intersection.
1. Radar and Camera Based Systems
Many of the advanced crash avoidance technologies currently available in the marketplace employ on-board sensor technologies such as cameras, RADAR, or LIDAR, to monitor the vehicles' surroundings.
These technologies are what we call “vehicle-resident” systems because they are systems installed on one vehicle and, unlike V2V, do not communicate with other vehicles. Cameras, RADAR, and LIDAR that are installed on the vehicle can gather information directly by sensing their surroundings, and vehicle-resident crash avoidance technologies can use that information to warn the driver of impending danger so the driver can take appropriate action to avoid or mitigate a crash. Crash scenarios that can currently be addressed by existing crash avoidance technologies include, but are not limited to, Forward Collision Warning (FCW),
Blind Spot Warning (BSW), and Lane Change Warning (LCW).
Additionally, some crash-predicting safety applications leveraging these existing sensing technologies are beginning to emerge and NHTSA is aggressively pursuing those technologies that demonstrate safety benefits.
Vehicle-resident systems can be highly effective in mitigating certain crash types, although their performance varies by sensor type, and is limited in certain situations. Perception range varies from 10 meters to 200 meters for LIDAR and 77 GHz radar, respectively, while field-of-view ranges from 18 degrees to 56 degrees for 77 GHz radar and 24 GHz radar,
respectively. On-board sensors can also exhibit reduced reliability in certain weather conditions (e.g., snow, fog, and heavy rain), and camera systems, in particular, can exhibit reduced performance when encountering lighting transitions and shadows. Most if not all current sensing technologies are susceptible to performance reductions through foreign objects such as dirt or snow. For camera-based systems, some manufacturers have implemented devices that attempt to keep the camera clear for maximal operation. Both sensor types can be vulnerable to misalignment or damage over time. On-board sensors do, however, perform reliably in “urban canyons” and other situations in which a clear view of the sky is not needed.
2. Communication-Based Systems
Devices enabling vehicles to communicate with one another or with road-side equipment and/or infrastructure have been prototyped and tested in field operational tests like the Safety Pilot Model Deployment. These devices, when eventually developed for mass production, could be fully integrated into a vehicle when manufactured, or could be standalone aftermarket units not restricted to a single vehicle. These devices offer varying degrees of functionality, but all are designed to communicate safety information to help mitigate crashes.
Safety information that can help mitigate crashes includes data elements like vehicle position, heading, speed, and so forth—data elements that could help a computer-based safety application on a vehicle calculate whether it and another vehicle were in danger of crashing without driver intervention. These pieces of information are collected into what is known as a “Basic Safety Message,” or “BSM.” In a fully-integrated vehicle communication system, the system is built into the vehicle during production, and consists of a general purpose processor and associated memory, a radio transmitter and transceiver, antennas, interfaces to the vehicle's sensors, and a GPS receiver. It generates the BSM using in-vehicle information obtained from the vehicle's on board sensors. An integrated system can both transmit and receive BSMs, and can process the content of received messages to provide advisories and/or warnings to the driver of the vehicle in which it is installed. Since the vehicle data bus provides a rich data set, integrated systems have the potential to obtain information that could indicate driver intent, which can help inform safety applications such as Left Turn Assist (LTA),
Do Not Pass Warning (DNPW),
and BSW/LCW safety applications, all of which can benefit from, or require, information on turn signal status or steering wheel angle.
Aftermarket devices, which are added to a vehicle after its assembly, can vary significantly from both fully-integrated vehicle communication systems, and from one another. The simplest designs may only transmit (and not also receive) a BSM, may only connect to a power source and otherwise operate independently from the systems in the vehicle, and may not run safety applications or provide advisories/warnings to a driver.
More sophisticated options may have the ability to both receive and transmit a BSM to nearby vehicles, may connect to the vehicle data bus (similar to fully integrated devices), and may contain safety applications that can provide advisories/warnings to the driver. Depending on the type of aftermarket device, different data elements may or may not be available. This may limit what safety applications can be supported. For example, a device that does not connect to a vehicle data bus may support FCW, but without having access to turn signal information, may not be able to support LTA.
Regardless of whether they are integrated or aftermarket, all communication-based systems are designed to, at a minimum; transmit BSM information such as vehicle position and heading to nearby vehicles. That information may be transmitted using various communication methods—like cellular, Wi-Fi, satellite radio, or dedicated short-range communication (DSRC)—each of which has its own advantages and disadvantages. At this time, DSRC is the only mature communication option that meets the latency requirements to support vehicle communication based crash avoidance, although future V2V standards may also meet the latency requirements.
Cellular networks currently offer fairly widespread coverage throughout the nation and are continuing to expand; however, there are still areas (dead spots) where cellular service is Start Printed Page 3865not available. And, although the advancement of long-term evolution (LTE) technology is helping to deliver large amounts of data to cellular users more quickly, transmission rates slow down if a user is moving or is in a high-capacity area with many other LTE users. While many new vehicles today already are equipped with cellular capability, this communication method could possibly introduce security risks, such as cyberattacks or privacy concerns,
and high costs stemming from cellular data costs and fitting new vehicles with cellular capability.
Wi-Fi technology offers generally higher data rates than the other options, but because of its intrinsic design for stationary terminals, and the need for a vehicle to provide its MAC (media access control) address, and obtain the MAC address of all other vehicles in a Wi-Fi hotspot before it can send communications, transmission rates are significantly reduced if a user is moving. Cost concerns and potential security risks for Wi-Fi are similar to those for cellular communication.
Satellite radio, or Satellite Digital Audio Radio Service (SDARS), uses satellites to provide digital data broadcast service nearly nationwide (across approximately 98% of the U.S. land mass—fundamentally not covering Alaska and Hawaii and covering the southern parts of Canada and northern parts of Mexico. Data download time for satellite communication, however, is slow compared to the other communication options which limits its capability to “back office” type communications versus actual vehicle to vehicle safety communications, and the costs and security risks associated with cellular and Wi-Fi communication also apply to satellite.
DSRC is a two-way short-range wireless technology that provides local, nearly instantaneous network connectivity and message transmission. It has a designated licensed bandwidth to permit secure, reliable communication, and provides very high data transmission rates in high-speed vehicle mobility conditions which are critical characteristics for detecting potential and imminent crash scenarios.
Cost concerns and potential security risks are also inherent to DSRC technology.
In this NPRM, the proposal would require V2V communication to use DSRC devices to transmit messages about a vehicle's speed, heading, braking status, etc. to surrounding vehicles, as well as to receive comparable information from surrounding vehicles. As DSRC is based on radio signals, which are omnidirectional (i.e., offer 360 degrees of coverage), V2V offers the ability to “see” around corners and “see” through other vehicles. Consequently, V2V is not restricted by the same line-of-sight limitations as crash avoidance technologies that rely on vehicle-resident sensors. V2V also offers an operational range of 300 meters, or farther, between vehicles, which is nearly double the detection distance afforded by some current and near-term vehicle-resident systems. These unique characteristics allow V2V-equipped vehicles to perceive and warn drivers of some threats sooner than current vehicle-resident sensors can. The proposal would also allow vehicles to comply using non-DSRC technologies that meet certain performance and interoperability standards.
V2V is subject to the current limitations of GPS technology. This includes accuracy levels that are perceived to be only sufficient for warning applications vs. control applications such as automatic braking. The GPS dependency also poses challenges where sky visibility is limited (e.g., under bridges, in tunnels, in areas of heavy foliage, and in highly dense urban areas). Some of these issues, however, can be resolved through techniques such as “dead-reckoning.” 
V2V also requires that a significant number of vehicles be equipped with V2V technology to realize the effectiveness of the system, and similarly, whereas vehicle-resident sensors can “see” stop signs and traffic lights (and use that information to slow or stop the vehicle), the infrastructure also would need to be able to send messages to V2V-equipped vehicles if V2V was to have similar capability.
3. Fusion of Vehicle-Resident and Communication-Based Systems
Both vehicle-resident and communication-based safety systems have certain strengths and limitations, and as such, NHTSA and many commenters to the ANPRM, like the Automotive Safety Council, Hyundai Motor Group, IIHS, Motor & Equipment Manufacturers Association, and Volvo Cars, believe that combining (“fusing”) communication-based systems with vehicle-resident crash avoidance systems to exploit the functionality of both system types presents a significant opportunity. Given the proposed V2V system, we are confident that the technology could be easily combined with other vehicle-resident crash avoidance systems to enhance the functionality of both types of systems. Together, the two systems can provide even greater benefits than either system alone.
For vehicles equipped with current on-board sensors, V2V can offer a fundamentally different, but complementary, source of information that can significantly enhance the reliability and accuracy of the information available. Instead of relying on each vehicle to sense its surroundings on its own, V2V enables surrounding vehicles to help each other by reporting safety information to each other. V2V communication can also detect threat vehicles that are not in the sensors' field of view, and can validate a return from a vehicle-based sensor. This added capability can potentially lead to improved warning timing and a reduction in the number of false warnings, thereby adding confidence to the overall safety system, and increasing consumer satisfaction and acceptance. Similarly, vehicle-resident systems can augment V2V systems by providing the information necessary to address other crash scenarios not covered by V2V communications, such as lane and road departure. These systems can work collectively to advance motor vehicle safety, as was further evidenced in the comments submitted by the Automotive Safety Council and IIHS.
The Automotive Safety Council commented that, in addition to the safety advantages from increased sensing range and the environment use cases, V2V also offers advantages with respect to operation status (e.g., brake pedal status, transmission state, stability control status, vehicle at rest versus moving, etc.) IIHS suggested that whereas current FCW systems are designed to operate off the deceleration of the vehicle directly ahead, V2V could permit communication with all vehicles ahead in the lane of travel, thus warning all vehicles, not just those equipped with FCW, of the eminent need to slow down or stop.
IIHS contended, however, that onboard sensing systems may evolve during the time it will take V2V to penetrate the fleet, potentially to the Start Printed Page 3866point where they have similar ranges to V2V transmissions, such that it may be difficult to quantify how much V2V will reduce collision frequency and severity beyond the capabilities of sensor-based systems. Along similar lines, the Automotive Safety Council countered some of its earlier comments by stating that “it is possible that DSRC technology may be obsolete before the safety goals of V2V systems are realized” such that it may be a better approach to pursue the installation of well-tested, standalone technologies that are currently available.
The agency appreciates the commenters' views on the co-existence of the technologies with varying capability and expressing support for the agency's approach in this proposal. We do disagree, however, with the comments indicating that V2V should not be pursued because onboard sensing systems exist in the marketplace. The agency views these technologies as complementary and not competing. Providing a data rich information environment should, most likely, enable more capability to enhance vehicle safety.
The agency requests comments its views concerning the potential of fusing connected and vehicle-resident technologies. In particular, the agency requests comment on what specific applications could use both technologies to enhance safety. The agency also seeks comment on whether an if-equipped option for V2V would be preferable, given the development of vehicle-resident technologies.
4. Automated Systems
Automated systems perform at least some aspects of a safety-critical control function (e.g., steering, throttle, or braking) automatically—without direct input by a human driver. Examples of automated systems include Crash Imminent Braking (CIB) and Dynamic Brake Support (DBS). These systems are designed, respectively, to automatically apply the vehicle's brakes if the human driver does not respond at all to warnings that are provided, or to supplement the human driver's braking effort if the driver's response is determined (by the system) to be insufficient, in order to mitigate the severity of a rear-end crash, or to avoid it altogether.
Although many automated systems currently rely on data obtained from on-board sensors and cameras to judge safety-critical situations and respond with an appropriate level of control, data acquired from GPS and telecommunications like V2V could significantly augment such systems, since, as mentioned previously, vehicle communication-based systems, like V2V, are capable of providing warnings in several scenarios where vehicle-based sensors and cameras cannot (e.g., vehicles approaching each other at intersections).30 Honda Motor Col, Ltd commented that “. . . the ability of vehicles to directly communicate with one another will greatly assist in the ability to safety and effectively deploy” higher-level driver assistance and automated technologies in Honda vehicles. Along similar lines, Meritor WABCO and the Automotive Safety Council both mentioned that V2V safety applications with warning capability will enhance current active safety systems, but should not be considered a replacement for them.
Systems Research Associates, Inc. stated that “it is irrefutable that V2V, V2I, and V2P communications will be absolutely critical to the successful development of self-driving vehicles that can avoid collisions, navigate responsibly, and achieve a transport objective efficiently and in a timely manner.” Similarly, IEEE USA commented that V2V can provide the trusted map data and situation awareness messages necessary for innovative safety functions, and support the flow of traffic with self-driving cars.
Other commenters, including Robert Bosch LLC and Motor & Equipment Manufacturers Association expressed that V2V data should serve as a supplemental input in developing automated vehicles, but cautioned the agency that vehicles should not have an external, V2V exclusive infrastructure and communication medium dependency. This approach may unnecessarily limit the adoption or implementation of automated systems. Furthermore, the Automotive Safety Council commented that “V2V should be considered as one of the supporting sensor sets for automated vehicle applications, where it can augment the information available to the vehicle about the surrounding environment” by increasing the range and/or reliability of data from sensors, but it is “. . . not sufficient alone as a sensor to support automated vehicles nor a technology that will inhibit the development of automated applications. In order to ensure robust decisions for autonomous functions, sensing redundancy at the vehicle level may still be required to meet functional safety requirements, and/or for functions where the V2V technology is not capable of providing the necessary data or inputs to the vehicle.”
Competitive Enterprise Institute expressed concerns that a V2V mandate may harm vehicle automation efforts. The company cited Google and Bosch's ability to develop vehicle automation systems that use onboard sensors and computers to map vehicle surroundings in real-time and make direction decisions without widespread vehicle-to-vehicle connectivity as reason to suggest that V2V is unnecessary for full-scale automation. The company also commented that if automated systems were required to interact with V2V under a new Standard, this would generate “large and as yet uncontemplated cybersecurity, crash, and products liability risks.” Similarly, the Automotive Safety Council commented that the security system described in the V2V Readiness report “does not provide sufficient protection against all abuse of the V2V system” in the event that active safety applications which leverage the V2V infrastructure, are considered in the future. The group suggested that because “the data fed into the DSRC device from the vehicle sensors is not cryptographically protected,” an attacker “could simply feed a DSRC device bad data, which is subsequently cryptographically signed using the proposed PKI system and transmitted to nearby vehicles.” The Automotive Safety Council suggested that this could allow an attacker to “cause a vehicle to rapidly swerve off the road to avoid a collision with a car that does not exist in reality but was interpreted to exist” because the vehicle received false, but cryptographically signed and thus trusted, data from a nearby malicious vehicle.
QUALCOMM Incorporated maintained an opposing position to Competitive Enterprise Institute and the Automotive Safety Council. The company commented that, “while it is possible to implement a certain level of vehicle automation . . . without V2V, V2V can enhance the overall reliability and coverage of autonomous vehicle technology.” Consequently, the company contended that there is no conflict between the deployment of DSRC and automated vehicles, and further suggested that the two technological advances should be pursued simultaneously so that the additional safety benefits offered by DSRC can penetrate the fleet and be realized in both autonomous and non-autonomous vehicles. Overall, this approach is aligned with the agency's view that V2V is complementary, and not competing, with automated vehicle deployment.
The agency requests comment on the interplay between V2V and autonomous technologies.Start Printed Page 3867
C. V2V Research Up Until This Point
1. General Discussion
The U.S. Department of Transportation, along with other research partners in State DOTs, academia, and industry, has been evaluating how to incorporate communication technology into transportation infrastructure since the mid-1980s, in order to improve transportation (particularly on-road vehicle) safety, mobility, and emissions. That broad research topic is generally referred to as “intelligent transportation systems” or “ITS.” V2V research developed out of ITS research in the mid-2000s, when NHTSA and CAMP began to look at the potential for DSRC as a vehicle communication technology, for the purpose of warning drivers of imminent crash risks in time to avoid them. NHTSA's decision to begin the rulemaking process to require V2V communications capability on new light vehicles thus represented the culmination of several decades of research by government and industry to develop this communications technology for vehicles from the ground up. In the interest of brevity, NHTSA refers readers to the V2V Readiness Report for a summary of the history of ITS research and NHTSA's work with CAMP and other partners prior to 2014.
One element of the V2V research that took place prior to 2014 is the Safety Pilot Model Deployment. The Model Deployment was the culmination of the V2V research that had taken place in prior years. Using the Model Deployment, DOT deployed prototype V2V DSRC devices on real roads with real drivers that interacted for over a year and provided the data that allowed DOT to evaluate the functional feasibility of V2V under real world conditions.
The Model Deployment was conducted in Ann Arbor, Michigan, and ran from August 2012 to February 2014. Sponsored by DOT and conducted by the University of Michigan Transportation Research Institute, the experiment was designed to support evaluation of the functionality of V2V technology. Approximately 2,800 vehicles—a mix of cars, trucks, and transit vehicles operating on public streets within a highly concentrated area—were equipped with integrated in-vehicle safety systems, aftermarket safety devices, or vehicle awareness devices, all using DSRC to emit wireless signals of vehicle position and heading information. Vehicles equipped with integrated in-vehicle or aftermarket safety devices have the additional design functionality of being able to warn drivers of an impending crash situation involving another equipped vehicle.
Data collected during the Model Deployment was used to support an evaluation of functionality of the V2V safety applications used in the Model Deployment—in effect, whether the prototypes and the system worked, but not necessarily how well they worked. Overall, the Model Deployment demonstrated that V2V technology can be deployed in a real-world driving environment. The experimental design was successful in creating naturalistic interactions between DSRC-equipped vehicles that resulted in safety applications issuing warnings in the safety-critical driving scenarios that they were designed to address. The data generated by warning events indicated that all the devices were interoperable, meaning that they were successfully communicating with each other.
The Model Deployment was the first and largest test of V2V technology in a real-world environment. The Model Deployment was a key step in understanding whether the technology worked, the potential of this technology to help avoid crashes, and increase the vehicle safety.
Besides explaining the history of the research that led to NHTSA's decision to initiate rulemaking to require V2V communications capability, the Readiness Report also described NHTSA's understanding of the current state of the research in mid-2014, and identified a number of areas where additional research could be necessary either to develop mandatory requirements for new vehicles equipped with DSRC, or to further develop information needed to inform potential future requirements for DSRC-based safety applications. The following sections summarize the agency's research-based findings in the Readiness Report; list the areas where the agency identified additional research as necessary; and explain the status of research conducted since the Readiness Report in response to those identified research needs.
2. Main Topic Areas in Readiness Report
Based on the agency's research and thinking at the time of issuance, the V2V Readiness Report comprehensively covered several key topic areas:
- What the safety need is that V2V can address, and how V2V addresses it;
- The legal and policy issues associated with requiring V2V for light vehicles, the secure operation of the technology, and the implications of these issues for privacy;
- A description of the technology required for V2V capability, the different types of devices, and the security needed for trusted communications; and
- Based on preliminary data, how much the technology may be expected to cost (both for purchasers of new vehicles, and for the entities who develop and build out the security and communications networks, in terms of initial capital investments), and the potential effectiveness (and thus, benefits) of certain V2V-based safety applications at helping drivers avoid crashes.
(a) Key Findings of Readiness Report
The Readiness Report listed the key findings of the research up to that point, as follows:
- V2V (specifically, DSRC) devices installed in light vehicles as part of the Safety Pilot Model Deployment were able to transmit and receive messages from one another, with a security management system providing secure communications among the vehicles during the Model Deployment. This was accomplished with relatively few problems given the magnitude of this first-of-its-kind demonstration project.
- The V2V devices tested in the Model Deployment were originally developed based on existing communication protocols found in voluntary consensus standards from SAE and IEEE. NHTSA and its research partners participating in the Model Deployment (e.g., its vehicle manufacturers and device suppliers) found that the standards did not contain enough detail as-is and left too much room for interpretation to achieve interoperability. They therefore developed additional protocols that enabled interoperability between devices participating in the study. The valuable interoperability information learned during the execution of Model Deployment is planned to be included in future versions of voluntary consensus standards that would support a larger, widespread technology roll-out.
- As tested in the Model Deployment, safety applications enabled by V2V, examples of which include IMA, FCW, and LTA, have proven effective in mitigating or preventing potential crashes, but the agency recognized that additional refinement to the prototype safety applications used in the Model Deployment would be needed before minimum performance standards could Start Printed Page 3868be finalized and issued.
Based on the agency's understanding of how these prototype safety applications operate, preliminary effectiveness estimates in the Readiness Report indicated substantial ability to mitigate crashes, injuries or fatalities in these crash scenarios. Also, the agency concluded that some safety applications could be better tailored to the safety problem that they are intended to solve (e.g., LTA applications currently trigger only when the driver activates the turn signal, but many drivers do not always activate their turn signals in dedicated turn lanes).
- The agency has the legal authority to mandate V2V (specifically, DSRC) devices in new light vehicles, and could also require them to be installed in commercial vehicles already in use on the road if we also required them for new medium and heavy duty vehicles. The agency also has the authority to mandate safety applications that are V2V-based, and to work with an outside entity to develop the security and communications infrastructures needed to support deployment of V2V technologies in motor vehicles.
- Based on preliminary information used for the report, NHTSA estimated that the V2V equipment and supporting communications functions (including a security management system) would cost approximately $341 to $350 per vehicle in 2020, and it is possible that the cost could decrease to approximately $209 to $227 by 2058, as manufacturers gain experience producing this equipment (the “learning curve” effect). These costs would also include an additional $9 to $18 per year in fuel costs due to added vehicle weight from the V2V system. Estimated costs for the security management system ranged from $1 to $6 per vehicle, and were estimated to increase over time due to the need to support an increasing number of vehicles with V2V technology. The estimated communications costs ranged from $3 to $13 per vehicle. Cost estimates were not expected to change significantly by the inclusion of V2V-based safety applications, since the applications themselves are software and their costs are negligible.
- Based on preliminary estimates used for the report, the total projected preliminary annual costs of the V2V system fluctuated year after year but generally indicated a declining trend. The estimated total annual costs ranged from $0.3 to $2.1 billion in 2020, with the specific costs depending upon the technology implementation scenarios and discount rates. The costs peaked to $1.1 to $6.4 billion between 2022 and 2024, and then gradually decreased to $1.1 to $4.6 billion.
- The analysis conducted for the V2V Readiness Report estimated that just two of many possible V2V safety applications, IMA and LTA, would on an annual basis potentially prevent 25,000 to 592,000 crashes, save 49 to 1,083 lives, avoid 11,000 to 270,000 MAIS 1-5 injuries, and reduce 31,000 to 728,000 property-damage-only crashes by the time V2V technology had spread through the entire fleet, if manufacturers implemented them.
These two applications were used for analysis because they were illustrations of benefits that V2V can provide above and beyond the safety benefits of radar and camera based systems. Of course, the number of lives potentially saved would increase with the implementation of additional V2V- and V2I-based safety applications that could be enabled if vehicles were equipped with V2V communications capability.
(b) Additional V2V-Related Issues That Required the Agency's Consideration
The Readiness Report also recognized that additional items need to be in place for a potential V2V system to be successful. These items were listed as follows:
- Wireless spectrum: V2V communications transmit and receive messages at the 5.85-5.925 GHz frequency. The FCC, as part of an ongoing rulemaking proceeding, is considering whether to allow “Unlicensed National Information Infrastructure” devices (that provide short-range, high-speed, unlicensed wireless connections for, among other applications, Wi-Fi-enabled radio local area networks, cordless telephones, and fixed outdoor broadband transceivers used by wireless Internet service providers) to operate in the same area of the wireless spectrum as V2V.
Given that Wi-Fi use is growing exponentially, “opening” the 5.85-5.925 GHz part of the spectrum could result in many more devices transmitting and receiving information on the same or similar frequencies, which could potentially interfere with V2V communications in ways harmful to its safety intent. More research is needed on whether these Wi-Fi enabled devices can share the spectrum successfully with V2V, and if so, how. In December 2015 and January 2016, the DOT, FCC, and the Department of Commerce sent joint letters to members of the U.S. Senate Committee on Commerce, Science, and Transportation, delineating a collaborative multi-phased approach that will be used to provide real-world data on the performance of unlicensed devices that are designed to avoid interfering with DSRC operations in the 5.85-5.925 GHz band.
- V2V device certification issues: V2V devices are different from other technologies regulated by NHTSA under the Federal Motor Vehicle Safety Standards, insofar as part of ensuring their successful operation (and thus, the safety benefits associated with them) requires ensuring that they are able to communicate with all other V2V devices participating in the system. This means that auto manufacturers (and V2V device manufacturers) attempting to comply with a potential V2V mandate could have a significant testing obligation to guarantee interoperability among their own devices and devices produced by other manufacturers. At the time of the Readiness Report, it was an open question whether individual companies could meet such an obligation themselves, or whether independent testing facilities might need to be developed to perform this function. Based on the security design evaluated for the report, it was thought likely that an entity or entities providing the security management system would require that device manufacturers comply with interoperability certification requirements to ensure the reliability of message content. The agency currently believes the creation of a standardized test device should mitigate manufacturer to manufacturer communication variances to help ensure interoperability.
- Test procedures, performance requirements, and driver-vehicle interface (DVI) issues: Test procedures, performance requirements, and driver-vehicle interfaces appeared to work well enough for purposes of the Model Deployment (as compared to a true production, real-world environment), but NHTSA concluded that additional research and development would be necessary to produce FMVSS-level test procedures for V2V inter-device Start Printed Page 3869communication and potential safety applications.
- As a result of this item from the Readiness Report, NHTSA undertook additional research to examine the minimum performance measures for DSRC communication and system security.
The research included functional and performance requirements for the DSRC device, the results of which directly informed the development of this proposal. As we concluded in the Readiness Report, to eventually go forward with rulemaking involving safety applications, V2V and safety application standards need to be objective and practicable, meaning that technical uncertainties are limited, that tests are repeatable, and so forth. Additionally, the agency deferred consideration of whether standardization of DVIs would improve the effectiveness of safety applications, and whether some kind of standardization could have significant effects on costs and benefits.
- Standing up security and communications systems to support V2V: In order to function safely, a V2V system needs security and communications infrastructure to enable and ensure the trustworthiness of communication between vehicles. The source of each message needs to be trusted and message content needs to be protected from outside interference. A V2V system must include security infrastructure to credential each message, as well as a communications network to get security credentials and related information from vehicles to the entities providing system security (and vice versa).
- Liability concerns from industry: Auto manufacturers repeatedly have expressed concern to the agency that V2V technologies will increase their liability as compared with other safety technologies. In their view, a V2V system exposes them to more legal risk than on-board safety systems because V2V warning technologies rely on information received from other vehicles via communication systems that they themselves do not control. However, the decision options under consideration by NHTSA at the time of the Readiness Report involved safety warning technologies—not control technologies. NHTSA's legal analysis indicated that, from a products liability standpoint, V2V safety warning technologies, analytically, are quite similar to on-board safety warnings systems found in today's motor vehicles. For this reason, NHTSA did not view V2V warning technologies as creating new or unbounded liability exposure for the industry.
Privacy: NHTSA explained in the Readiness Report that, at the outset, readers should understand some very important points about the V2V system as then contemplated and understood by NHTSA. The system will not collect or store any data directly identifying specific individuals or their vehicles, nor will it enable the government to do so. There is no information in the safety messages exchanged by vehicles or collected by the V2V system that directly identifies the driver of a speeding or erratic vehicle for law enforcement purposes, or to third parties. The system—expected to be operated by private entities—will make it difficult to track through space and time specific vehicles, owners or drivers on a persistent basis. Third parties attempting to use the system to track a vehicle would find that it requires significant resources and effort to do so, particularly in light of existing means available for that purpose. The system will not collect financial information, personal communications, or other information directly linked to individuals. The system will enroll V2V enabled vehicles automatically, without collecting any information that identifies specific vehicles or owners. The system will not provide a “pipe” into the vehicle for extracting data. The system is designed to enable NHTSA and motor vehicle manufacturers to find lots or production runs of potentially defective V2V equipment without use of VIN numbers or other information that could identify specific drivers or vehicles. Our research to date suggests that drivers may be concerned about the possibility that the government or a private entity could use V2V communications to track their daily activities and whereabouts. However, NHTSA has worked hard to ensure that the V2V system both achieves the agency's safety goals and protects consumer privacy appropriately.
- Consumer acceptance: If consumers do not accept a required safety technology, the technology will not create the safety benefits that the agency expects. At the time of the report, the agency believed that one potential issue with consumer acceptance could be maintenance. More specifically, if the security system is designed to require consumers to take action to obtain new security certificates—depending on the mechanism needed to obtain the certificates—consumers may find the required action too onerous. For example, rather than accept new certificate downloads, consumers may choose instead to live with non-functioning V2V capabilities.
3. Research Conducted Between the Readiness Report and This Proposal
The findings of the V2V Readiness Report also yielded a series of research, policy and standards needs. The agency believed some of these needs were significant enough that they should be addressed to properly inform any potential regulatory action; such as this NPRM. The agency also identified some needs from the Readiness Report that could be addressed later to potentially support other aspects of V2V deployment such as safety applications. Following is a list of needs identified in the V2V Readiness Report and their current status. The agency has completed what it believes is the necessary research for to inform and support this proposal, although the agency is continuing to study these and other issues. The agency notes that Table II-4 shows the status of the research related to safety applications, which are not being proposed in this NPRM.Start Printed Page 3870
Table II-4—DSRC Performance Requirements and Compliance Testing Research
|Readiness report research need||Description||Research projects initiated to address||Description||Completion date|
|Standards Need V-1 SAE Standards Maturity||Currently Standards are being developed by outside standards organizations||Crash Avoidance Metrics Partnership V2V Interoperability and V2V System Engineering Projects||Crash Avoidance Metrics Partnership providing results of DSRC device performance requirements to SAE standards development committee for SAE J2735 and J2945||April 2016.|
|Research Need V-2 Impact of Software Implementation on DSRC Device Performance||[V-2] V2V device software updates may be required over its lifecycle. NHTSA will need to determine how to ensure necessary V2V device software updates are seamless for consumers and confirmed||DSRC On-Board Unit Performance Measures Booze Allen and Hamilton Crash Avoidance Metrics Partnership—Documentation of On-Board Unit Requirements and Certification Procedures for V2V Systems (System Engineering Project)
V2V-Comminication Research project||BAH project will Develop performance measures for Dedicated Short Range Communication (DSRC) device; and develop security performance measures for the following, but not limited to Critical components on the DSRC device, Firmware on the DSRC device, Predominant elements in a Public Key Infrastructure (PKI)||BAH Completion date—Requirements October 2015/Test Procedures October 2015. CAMP System Engineering Completion date—Requirements Aug 2015/Test Procedures Sept 2015.|
|Research Need V-3 DSRC Data Communication System Performance Measures||[V-3] The purpose of this research is to finalize the operational modes and scenarios, key functions, and qualitative performance measures that indicate minimum operational performance to support DSRC safety and security communication functions||CAMP Communications research completion date—August 2016.|
|Research Need V-5 BSM Congestion Sensitivity||[V-5] Complete congestion mitigation and scalability research to identify bandwidth congestion conditions that could impair performance of safety or other applications, and develop appropriate mitigation approaches||CAMP will develop a single comprehensive document summarizing the minimum level of Connected Vehicle (CV) V2V safety system on-board requirements and certification procedures.|
|Research Need V-6 Relative Positioning Performance Test||[V-6] Research will be required to determine how to test relative positioning performance across GPS receivers produced by different suppliers and yield a generalized relationship between relative and absolute positioning||CAMP V2V Communications Research Project will identify requirement in relation to BSM message congestion mitigation and misbehavior detection|
|Research Need V-7 Vehicle and Receiver Positioning Biases||[V-7] Research to understand potential erroneous position reporting due to positional biases across multiple GPS receiver combinations|
|Research Need VI-7 Compliance Specifications and Requirements||[VI-7] Development of performance requirements, test procedures, and test scenarios to evaluate a device's compliance with interoperability standards, security communication needs; and to support safety applications|
Table II-5—System, Security, and Acceptance Research
|Readiness report research need||Description||Research projects initiated to address||Description||Completion date|
|Policy Need IV-1 Road Side Equipment Authority||NHTSA will evaluate the need for DOT to regulate aspects of RSE operation and assess its authority for doing so||Authority evaluation conducted for NPRM||Issuance of NPRM.|
|Start Printed Page 3871|
|Policy Need IV-2 V2V Device Software Updates||V2V device software updates may be required over its lifecycle. NHTSA will need to determine how to ensure necessary V2V device software updates are seamless for consumers and confirmed||Crash Avoidance Metrics Partnership V2V System Engineering project and Crash Avoidance Metrics Partnership Security Credential Management System Proof of Concept project||The System Engineering project will investigate software update requirements from the vehicle perspective as the Security Credential Management Systems project investigates software update from the security system perspective. Both projects will identify requirements that will facilitate the software update of V2V devices||Completion Date for Requirements—Sept 2015.|
|Research Need V-1 Spectrum Sharing Interference||Evaluate the impact of unlicensed U-NII devices on the transmission and reception of safety critical warnings in a shared spectrum environment||Testing spectrum sharing feasibility||A test plan for testing unlicensed devices that would share the band with licensed DSRC devices has been developed. The testing will evaluate the feasibility of sharing spectrum with unlicensed devices||The evaluation of spectrum sharing interference is pending the conduct of tests with representative U-NII-4 devices that operate in the 5.9 GHz (DSRC) frequency band.Testing could be completed within 12 months of receipt of prototype devices.|
|Research Need VII-1 Consumer Acceptance||Supplement the driver acceptance analysis completed per the Driver Clinics and Safety Pilot Model Deployment with further research that includes a focused assessment of privacy in relation to V2V technology||V2V Crash Avoidance Safety Technology Public Acceptance Review||This review needs to extend the current evaluation of driver acceptance to a broader public acceptance context and evaluate how public acceptance may impact and or influence the design, performance, operation, and implementation of this technology||September 2015.|
|Research Need VIII-1 V2V Location Tracking via BSM||[VIII-1] Assess the availability of information and technologies that facilitate linking data in the BSM to determine a motor vehicle's path||Independent Evaluation of V2V Security Design and Technical Analysis of the Potential Privacy Risk of V2V Systems||The objective of this Task Order is to perform: (1) an independent and comprehensive technical analysis of the V2V security system design that is currently proposed specifically for a V2V connected vehicle environment; and (2) a technical analysis of the potential privacy risks of the entire V2V system that includes security but also focuses on the operation of V2V communications in support of crash avoidance safety applications||March 2016.|
|Research Need VIII-2 V2V Identification Capabilities||[VIII-2] Understanding and quantifying risk of linking vehicle tracking or other information in the BSM to a specific vehicle, address, or individual via available resources (including but not limited to database matching or data mining)|
|Research Need VIII-3 V2V Inventory of Privacy Controls||[VIII-3] Inventory and assess the privacy controls applicable to the SCMS in connection with our comprehensive privacy assessment|
|Research Need VIII-4 V2V Privacy Risk Assessment||[VIII-4] A comprehensive privacy risk analysis of all aspects of the V2V system including infrastructure equipment, on-board vehicle systems, wireless and wired communications, as well as organizational and management issues|
|Start Printed Page 3872|
|Research Need IX-2 Cryptographic flexibility||[IX-2] The chosen cryptographic algorithms are estimated to be resilient against brute force attack for a few decades with some susceptibility through an unanticipated weakness. In the future new algorithms could enable better performance but may require redesign of functions or operations within the SCMS|
|Research Need IX-3 Independent Security Design Assessment||[IX-3] Independent evaluation of CAMP/USDOT security design to assess alignment with Government business needs, identify minimum requirements, assess the security designs ability to support trusted messages and appropriately protect privacy, identify and remove misbehaving devices, and be flexible enough to support future upgrades|
|Research Need IX-1 Misbehavior Authority||Development of the processes, algorithms, reporting requirements, and data requirements for both local and global detection functions; and procedures to populate and distribute the CRL||Crash Avoidance Metrics Partnership System Engineering project, Security Credential Management Proof of Concept project, and Communication Research Project||The CAMP System engineering project will investigate the implementation and device requirements for local (vehicle based) misbehavior detection and global (system-wide) misbehavior detection. The Communication Research project will research local and global misbehavior detection needs. The SCMS Proof of Concept will investigate implementation aspects from the security system perspective||Initial Misbehavior Detection information to be completed December 2015.|
Table II-6—V2V Safety Application Improvement and Performance Verification Research
|Readiness report research need||Description||Research projects initiated to address||Description||Completion date|
|Research Need V-4 Development of Safety Application Test Metrics and Procedures Research Need VI-2 Safety Application Performance Measure Rationale||[V-4] This research will take the performance measures and objective test procedures used during the research of V2V applications and develop FMVSS level performance measures and safety application objective tests||Volpe False Alert Scenarios and Objective Test Procedures for Crash Avoidance Applications project and Vehicle Research and Test Center project||The Volpe project will support NHTSA development of false-positive warning objective test procedures in conjunction with development of objective test procedures and performance criteria for IMA, LTA, FCW, and BS/LCW applications. The results of this IAA will contribute to potential Federal Motor Vehicle Safety Standards (FMVSS) for these crash avoidance applications||Volpe Completion Date—December 2018. VRTC Completion Date—April 2019.|
|Research Need VI-3 Practicability of Non-Ideal Driving Condition Testing||[VI-1] Assess the capability and capacity of possible refinements to reduce frequency of false positive warning while maintaining crash avoidance effectiveness||The VRTC project will incorporate results and information from the Volpe project to develop Federal Motor Vehicle Safety Standards (FMVSS) for these crash avoidance applications|
| ||[VI-2] Develop a rationale to support each performance and test metric recommended for incorporation into an FMVSS|
|Start Printed Page 3873|
| ||[VI-3] Evaluate test variations for non-ideal driving conditions (e.g., curved roads, turn signal use, weather, oblique intersections) and develop a rationale supporting the inclusion or exclusion of those test conditions|
|Research Need VI-4 Fused and Non-Fused V2V Safety Application Test Procedures||[VI-4] Develop test procedures that can be applied to systems relying solely on V2V information as well as “fused” systems, those relying on both V2V and other sources of information (e.g., on-board sensors)|
|Research Need VI-5 Performance and Test Metric Validation||[VI-5] Conduct test validation to ensure that the performance and test metrics are objective, repeatable, and practicable|
|Research Need VI-1 False Positive Mitigation||Assess the capability and capacity of possible refinements to reduce frequency of false positive warning while maintaining crash avoidance effectiveness||Volpe False Alert Scenarios and Objective Test Procedures for Crash Avoidance Applications project and||The Volpe project will support NHTSA development of false-positive warning objective test procedures in conjunction with development of objective test procedures and performance criteria for IMA, LTA, FCW, and BS/LCW applications||Volpe Completion Date—December 2018.|
|Research Need VI-6 DVI Minimum Performance Requirements||Determine DVI's impact on effectiveness of system and safety benefits applications to establish minimum performance for crash avoidance and objective test procedures||V2V On-Road DVI Project||Testing DVIs for Intersection Movement Assist and Left Turn Assist for stopped vehicles||VTTI Completion Date: November 2016.|
D. V2V International and Harmonization Efforts
Section V.F of NHTSA's Readiness Report detailed key similarities and some differences between U.S., European, and Asian V2X implementation approaches. There are several organizations in Europe and Asia conducting activities related to V2V and V2I communications and the U.S. DOT has established ongoing coordination activities with these regions and their representing organizations. For Europe, these organizations include DG CONNECT and the CAR 2 CAR Communications Consortium (C2C-CC). DG CONNECT is the EU directorate responsible for conducting research and pilot projects related to connected vehicles and C2C-CC has been working closely with CAMP as part of the EU-US V2X Harmonization Program.
A number of commenters to the ANPRM/Readiness Report addressed the issue of global harmonization. Most commenters addressing the issue encouraged the agency to pursue global harmonization between the U.S., EU, and Asia-Pacific regions as a way to reduce costs,
and also to facilitate cross-border traffic, as between NAFTA countries.
A number of commenters discussed existing or under-development technical standards by bodies such as ETSI, ISO, and the EU-US Task Force on ITS, and called on NHTSA to support them,
and some commenters suggested that NHTSA work to develop a Global Technical Regulation (GTR) and facilitate harmonization through that approach.
With regard to what specifically should be harmonized, commenters mentioned hardware,
although Cohda Automotive argued that global harmonization efforts have effectively already resulted in a single hardware platform being possible, and that different software could run in each region.
Some industry commenters cautioned, however, that NHTSA should not let harmonization objectives impede safety.
Mercedes expressed concern that harmonization should not just be global, but also consider the risk of a patchwork of differing State regulations for advanced technologies, and asked that NHTSA work with State DOTs to avoid this.
NHTSA recognizes the value of implementing V2V in a globally-harmonized way. Consistency could reduce costs, complexity, and contribute to a successful, long-term sustainable deployment. As discussed in the V2V Readiness Report, significant V2V research and development activities have been completed and continue in both Europe and Asia. Real-world deployments have been announced in both regions focusing on V2I systems to Start Printed Page 3874aid drivers and to attempt improvements in traffic flow.
Collaboration between organizations and governmental bodies in the U.S. and Europe has led to extensive harmonization of the criteria for hardware, message sets, security, and other aspects needed to support V2V between the two regions. It will be possible to use common radios and antennas in both regions. Harmonization could potentially be enhanced by this proposal by prompting solidification of the work focusing on security and message performance requirements for common applications. The connected vehicle applications being developed in Europe place a much stronger priority on mobility and sustainability compared to U.S. focus on safety applications.
Japan, Korea and Australia are the Asia-Pacific countries most involved in pursuing DSRC-based V2X communications. In Japan, MLIT's current V2X approach centers on the adaptation of their electronic tolling system operating at 5.8 GHz. Additionally, some Japanese OEMs (mainly Toyota) are actively supporting the deployment of V2X using 760 MHz communications. Development of message sets in Japan is not yet complete but appears to be moving in a similar direction as the message sets harmonized between Europe and the U.S. Korea currently uses the 5.835-5.855 GHz band for Electronic Toll Collection and DSRC experimentation. Korea has performed field tests for V2V communication in this band. Industry sources indicate that Korea may shift DSRC for ITS to 5.9 GHz to be more aligned internationally.
In Australia, Austroads is the association of Australian and New Zealand road transport and traffic authorities. This organization is currently investigating potential interference issues, and working with affected license holders to evaluate the feasibility of use of the 5.9 GHZ spectrum for V2X in Australia. Another agency, Transport Certification Australia, is leading the design for security requirements, supporting field deployments, and working with the Australian Communications and Media Authority (ACMA) on identifying requirements for spectrum usage. Because the Australian vehicle market is predominantly comprised of imports from the U.S., Europe, and Asia, these Australian agencies have joined in the international harmonization efforts to ensure that the vehicle brought into the country are interoperable with each other and with the new cooperative infrastructure equipment and applications emerging on the market.
Canada has reserved spectrum at 5.9 GHz for V2X and is watching developments in the U.S. closely.
Harmonization and joint standardization is performed under an Implementing Arrangement for Cooperative Activities. This memorandum between the U.S. DOT and the European Commission established a collaborative relationship in 2009 and it was renewed in December 2014.
The harmonization and collaboration on standards is governed by a Harmonization Work Plan that has generated a set of smaller, flexible task groups to focus on specific subjects. The completed and ongoing task groups and their status are the following:
Harmonization Task Group (HTG) 1 on Security Standards and HTG3 on Communications Standards performed their analysis in 2011 with completion of results in 2012. HTG1 (which included experts from ISO, CEN, ETSI, IEEE) worked in coordination with HTG3 to identify the subset of available standards to provide assurance of interoperable security measures in a cooperative, interoperable environment. Because HTG 1 and HTG 3 issues were sufficiently interrelated and the HTGs had a significant overlap in membership, work on these topics was conducted jointly. The analysis documented how implementations of the protocol stack might not be interoperable because the specification of technical features from various Standards Development Organizations (SDOs) was different or incomplete. These differences presented interoperability challenges. HTG1 and 3 results provide guidance to the SDOs for actions to be taken that raise the assurance of security interoperability of deployed equipment. Vehicle connectivity through harmonization of standards and architecture will reduce costs to industry and consumers, in that hardware and/or software development costs will be spread over a larger user base, resulting in reduced unit costs. Differences between vehicles manufactured for different markets will also be minimized, allowing private-sector markets to have a greater set of global opportunities. A final outcome of the HTG1 and HTG3 work was recognition of the need to harmonize security policies and standards. To meet this need, a third HTG (HTG6) was established to explore and find consensus on management policies and security approaches for cooperative ITS.
HTG2 on Harmonization of US BSM and EU CAM: The goal of HTG2 was to harmonize the vehicle-to-vehicle safety messages that had been developed within the EU and separately within the U.S. The group was able to harmonize on the hardware issues. However, differing U.S. and EU software approaches and institutional issues constrained the extent to which a single, cross-region safety message set could be developed. While a single message set did not result, the HTG was able to evolve the two messages in a manner such that simple software translation between the two message sets is sufficient to allow cross-compatibility. It was a significant step to be able to have the two message sets become substantially closer in nature. These advancements will facilitate deployment across multiple regions using similar or identical hardware and software modules.
HTG4/5 on Infrastructure Message Standards: HTG 4/5 is currently in-progress. Its scope is to address the need for standardized Vehicle-to-Infrastructure message sets and interfaces, including:
○ Signalized intersections applications such as Signal Phase and Timing, Signal Request, Signal Status,
○ In-vehicle data message sets.
At this point, there is general agreement on the data concepts in these message sets, but there remain differences in how the data is conveyed between the infrastructure and the vehicles. These differences are due to project and communications restrictions. For example, the U.S. is planning for additional message sets for enhanced functionality; whereas the European approach may limit the initial applications and simply add data elements to the messages over time. ISO Technical Specification 19091, a standard covering to V2I and I2V communications for signalized intersections, is currently under development and is incorporating both harmonized content and recognizing region-specific content—a practical compromise resulting from existing differences in signal standards. Overall, 19091 allows for substantial hardware congruity while acknowledging that fully identical message standards are not viable at this time.
HTG6 on Harmonized Development of a Cooperative-ITS Security Policy Framework: HTG6 assessed security policy needs across international, Start Printed Page 3875regional, and local levels. Analysis was performed to determine optimal candidate guidelines for policy areas. HTG6's intent was to identify where harmonization is desirable by exploring the advantages and limitations of global versus local security policy alternatives, including economic benefits. Implementation of harmonized policies engenders and sustains public trust in the C-ITS system and applications, particularly with a highly mobile environment that expects C-ITS services to remain available as they cross borders as well as over time. The task group is identifying the largest set of common approaches and interfaces for harmonization, recognizing that there will be multiple instantiations of security entities within and adjacent to geographic/jurisdictional borders. Although minimizing the number significantly decreases cost and complexity, decisions to own and operate security occur for diverse reasons, specifically because of differing jurisdictional requirements for security levels, privacy, cryptographic choices, or trust model choices. The group's analysis recognizes the benefits for commonality and identifies those policies and harmonized interfaces that support regional implementations that might diverge. At the time of developing this proposal, most of the reports from this activity are posted.
The SCMS development activity has incorporated key outcomes of this activity, some of which include:
- Implementation of harmonized policies engenders and sustains public trust in the C-ITS system and applications, particularly within a highly mobile environment that expects C-ITS services to remain available as networks evolve over time and as services cross borders.
- To support cross-border/cross-jurisdictional operations of C-ITS applications, individual security systems (known as C-ITS Credential Management Systems or CCMS) require a defined range of harmonized processes as well as specific, secure data flows to support digital auditing and system transparency.
- Planning for inter-CCMS or intra-CCMS communications will require decisions when developing near-term operational systems but those decisions may have longer-term impacts on crypto-agility, system flexibility, and evolution of systems that must be considered from the start.
- Critical near-term steps for policy and decision makers to perform include:
○ Minimize the number of CCMS: Policy makers must determine the number of CCMS that will be operational within a local, regional, or national jurisdiction. Increasing the number of CCMS, in particular the root authorities, significantly increases complexity and cost.
○ Assess risk and set appropriate parameters for risk and privacy: No system will ever be without risk. Policy and decision makers must set acceptable levels of internal and external risk, as well as levels of privacy protection. Further, systems managers must assess these levels continuously throughout the lifecycle both of the security solution as well as end-entity (user) devices and applications. Risk and privacy levels come with trade-offs that will need to be assessed by policy makers.
○ Choose appropriate trust models: After system managers assess and categorize risk, they can identify policy and technical controls to mitigate risk. Collectively, these controls support the implementation of trust models that range from no trust among security entities to full trust that allows users (“trusted actors” that are accepted into the C-ITS security environment) to receive security services even after leaving their “native” system in which they are enrolled. Decisions are also required to establish criteria that define who are trusted actors and policies and procedures for certification, enrollment, removal in the event of misbehavior, and reinstatement.
○ Establish Governance: These decisions include the identification and convening of key stakeholders who will require representation in ongoing decision-making. Once convened, this group will establish processes for decision-making, define criteria for new entrants into the governance process, assign roles and responsibilities, establish authority to provide governance and enforcement, and determine enforcement procedures.
○ Implement harmonized processes: The HTG6 team identified the priority areas for harmonization in report HTG6-3 and identified the interfaces and data flows where the policies would be applied in HTG6-4. Policy makers will need to examine them to determine which ones are appropriate both to support their choice in trust models and throughout the CCMS lifecycle.
HTG group members comprise a small group of international experts who worked together intensively with co-leadership. Members are provided by the EC DG-CONNECT and U.S. DOT, and typically chosen from among the editors of many of the current cooperative ITS standards in the different SDOs providing direct linkages into those SDO activities, as well as representatives of the EU and U.S. DOT and the Vehicle Infrastructure Integration Consortium (VIIC), and expert representatives from roadway and infrastructure agencies, system integrators, and policy analysts. HTG6 expanded the membership beyond the EC and U.S. DOT to include Transport Certification Australia (TCA) plus observers from Canada and Japan.
As the U.S. is taking the lead in potential V2V deployment, whereas Asia and Europe are focusing primarily on V2I implementation, the agency expects that a finalized implementation driven by this proposal will set precedent and potentially adjust standards for V2V implementation globally.
E. V2V ANPRM
To begin the rulemaking process, NHTSA issued an ANPRM on August 20, 2014.
Accompanying the ANPRM, NHTSA also published a research report discussing the status of V2V technology and its readiness for application (“V2V Readiness Report”).
NHTSA's goal in releasing these two documents in 2014 was to not only announce the agency's intent to move forward with the rulemaking process, but also to comprehensively collect all of the available information on V2V and present this information to the public to collect comments that would further help the agency refine its approach with regard to V2V.
1. Summary of the ANPRM
In the ANPRM and the accompanying V2V Readiness Report, we emphasized the capability of V2V to be an enabler for many advanced vehicle safety applications as well as an additional data stream for future automated vehicles.
We also stated our belief that a mandate to include DSRC devices in all vehicles would facilitate a market-driven approach to safety, and possibly other, application deployment.
Current advanced vehicle safety applications (e.g., forward collision warning, automated braking, lane keeping, etc.) use on-board sensors (e.g., cameras, radars, etc.) to perceive a vehicle's surroundings. Because each Start Printed Page 3876type of sensor has advantages and disadvantages under different conditions, manufacturers seeking to incorporate advanced functions in their vehicles are increasingly relying on sensor fusion (i.e., merging information from different sources) to ensure reliable information is available to the vehicle when it makes crash-imminent decisions. When compared to on-board sensors, V2V is a complementary, and unique, source of information that can significantly enhance the reliability of information available to vehicles. Instead of relying on each vehicle to sense its surroundings on its own, V2V enables surrounding vehicles to help each other by communicating safety information to each other. In addition, V2V enables new advanced vehicle safety functionality because it enables vehicles to receive information beyond the range of “traditional” sensing technology.
One important example that we mentioned in the ANPRM is intersection crashes.
Because of V2V's ability to provide vehicles with information beyond a vehicle's range of perception, V2V is the only source of information that supports applications like Intersection Movement Assist (IMA) and Left Turn Assist (LTA). These applications have the unique ability to address intersection crashes, which are among the most deadly crashes that drivers currently face in the U.S.
However, in spite of the benefits of the technology, we explained in the ANPRM that we did not expect that V2V technology would be adopted in the vehicle fleet absent regulatory action by the agency.
Due to the cooperative nature of V2V, we stated that early adopters of the technology would not realize immediate safety benefits until a sufficient number of vehicles in their geographical area have the technology.
In other words, early adopters incurring the costs to equip their vehicle to transmit BSM information about their vehicle would not realize the benefit of the V2V information environment unless other vehicles in their surroundings are also transmitting and receiving BSM information.
In the V2V Readiness Report,
we observed that, based on the data collected from the Safety Pilot Model Deployment Project, V2V systems work in real world testing. V2V-equipped vehicles successfully exchanged BSM information with each other and issued warnings to their drivers.
We further discussed and summarized our preliminary information regarding many of the technical aspects of a potential rule including: The types of safety problems that could be addressed by V2V,
the potential technological solutions to those problems (V2V-based or otherwise),
the potential hardware/software component that could be used in DSRC devices,
the applications that could be enabled by V2V,
and preliminary design concepts for a security system for the V2V environment.
The report also explored various important policy issues including: the agency's legal authority over the various aspects of the V2V environment (e.g., the vehicle components, aftermarket devices, etc.),
issues that may be outside the scope of NHTSA's activities,
privacy and public acceptance concerns over V2V technology,
and potential legal liability implications.
In addition, we began the process of analyzing the costs of a potential rule to require V2V capability in vehicles based on different technology assumptions and different scenarios for adoption.
While we acknowledged that there are a variety of potential benefits of V2V, we conducted a preliminary estimate of the benefits attributable to two V2V-specific safety applications.
Finally, throughout the V2V Readiness Report, we also identified various research and policy gaps in each of the substantive areas that we discussed.
In the context of the V2V Readiness Report, the ANPRM asked 57 questions to help solicit comments from the public more effectively.
While the questions we asked in the ANPRM covered a variety of subjects, many of our questions covered issues relating to estimating costs and benefits.
For example, we asked the public about potential ways to obtain real-world test data concerning the effectiveness of V2V safety applications and whether we have identified the relevant potential crash scenarios for calculating benefits.
On the same subject, we asked if preferring certain technologies over others in the situation of a network good 
such as V2V would lead to any detrimental impact.
The ANPRM questions also covered policy issues such as legal interpretation of NHTSA's authorities under the Motor Vehicle Safety Act,
and how commenters view the public's potential acceptance/non-acceptance of V2V technology.
The ANPRM also posed technical questions such as, how can the agency mandate V2V can help ensure interoperability, whether the Safety Pilot Model Deployment sufficiently demonstrated interoperability, and whether standards under development by organizations such as IEEE and SAE could help ensure interoperability.
We raised important questions regarding the potential sharing of the DSRC spectrum allocation by soliciting comments on potential sharing and, if so, ideas on how to share the spectrum safely.
In addition, we requested comment on the usefulness of our concepts for a potential security design (i.e., PKI)—including specific elements like the certificate revocation list (CRL), whether the system would create new “threat vectors,” sufficiently protect privacy, how DSRC devices could be updated, and potential cybersecurity threats.
2. Comments to the ANPRM
In response to the ANPRM, the V2V Readiness Report, and our questions, we received more than 900 comments.
The agency received responses to the ANPRM from a diverse set of commenters representing a wider range of perspectives than with other agency safety rules. They range from more traditional commenters to NHTSA safety rulemakings (e.g., automobile manufacturers/suppliers, trade associations, standards development organizations, safety advocacy groups, individual citizens, etc.) to newer participants in such rulemakings such as technology/communications companies, other state/federal agencies, and privacy groups. The comments also Start Printed Page 3877covered a wide variety of topics ranging from the technical details of V2V technology to the policy implications of any potential rule. While this document discusses the relevant comments in much greater detail when discussing each aspect of the proposal (in the sections that follow), the paragraphs here contain a sampling of the types of commenters and the major issues they raised.
While expressing general support, the automotive manufacturers stated their belief that the Federal government needs to assume a large role in establishing key elements of the V2V environment (e.g., establishing common operating criteria for V2V devices, establishing a security credentials system, preserving the 5.9 GHz spectrum for V2V safety, and mandating devices in new vehicles).
The automotive manufacturer commenters discussed their legal concerns (including concerns over practicability of an FMVSS if certain aspects of the V2V environment are missing and potential legal liability for manufacturers).
While generally agreeing with our assessment regarding the readiness of some of the industry technical standards to ensure that V2V communications work, the automotive manufacturer commenters also emphasized the importance of privacy and public acceptance to the success of the technology.
In spite of some of these open policy and technical questions, many automotive manufacturer commenters also agreed that a regulation or requirement defining key items needed for interoperability is necessary to realize the full potential benefits of V2V.
Automotive suppliers generally expressed support for the technology as well. They further generally opined that the technology and standards for the technology are mature enough for initial deployment. For example, DENSO 
stated that DSRC is a suitable technology for implementing V2V safety applications and that the current BSM is adequate to support those purposes. Continental further commented that V2V demonstrations thus far show that the system works and is interoperable.
Raising different points, Delphi commented that the coverage of a potential V2V rule should include more than just the vehicles contemplated in the ANPRM and that the technology should be developed in conjunction with the vehicle-resident systems.
Safety advocacy groups also expressed support, but emphasized the importance of ensuring interference-free spectrum for V2V. For example, the American Motorcyclist Association stressed the need for interference-free spectrum to ensure the safety applications will function. V2V, in their view, has the unique capability to address crashes that represent a significant portion of motorcycle crashes (e.g., left turn across path crashes).
They also emphasized the importance of a uniform human-machine interface for safety applications (regardless of whether the applications use V2V or vehicle-resident based information).
Other safety advocacy groups (e.g., the Automotive Safety Council) covered a large variety of topics (e.g., emphasizing the importance of interoperability, the ability of V2V to work in conjunction with vehicle-resident systems, and expressing concern that the security system described in the report would not sufficiently protect against all forms of “abuse” of the V2V environment).
Two standards development organizations also submitted comments. The two organizations (SAE and IEEE) were involved in developing various standards incorporated in this proposed rule. Both generally expressed support for the agency's proposal and stated that—in spite of on-going research—the standards are mature enough to support deployment of DSRC devices and ensure that they are interoperable.
Where the standards organizations differed was their opinion concerning spectrum availability. SAE reiterated its concern that “interference-free spectrum” is critical for the V2V environment.
While IEEE suggested that spectrum sharing is feasible, they opined that DSRC deployment should not wait for further research on spectrum sharing.
Instead “acceptable sharing parameters” may be determined at a later date after DSRC deployment and further research.
While expressing general support for the technology and NHTSA's efforts in this area, technology/communications device manufacturers expressed two general concerns. Through their trade associations,
such manufacturers raised questions about NHTSA's authority to regulate software and mobile devices.
In addition, individual companies (e.g., Qualcomm 
) and other associations (e.g., the Wi-Fi Alliance 
) expressed their opinion regarding the viability of spectrum sharing with unlicensed Wi-Fi devices and the ability of V2V to flourish alongside other technologies that will benefit automotive and highway safety. Finally, the Information Technology Industry Council stated its belief that NHTSA needs to ensure that connected vehicle technologies are allowed to develop using different technological solutions (e.g., other communications mediums beyond DSRC).
Other government agencies also submitted comments. The NTSB commented that both V2V and vehicle-resident crash avoidance technologies are important and they are complementary—especially when one (vehicle-resident) fills the gap during the deployment of the other (V2V).
State agencies also commented.
AASHTO also mentioned that interference-free spectrum is critical and commented that supporting future upgrades to the system through software rather than hardware changes would be important for state agencies.
A significant number of commenters also raised privacy concerns with this rulemaking. In addition to a large number of individual commenters, organizations such as EPIC stated that, since a potential rule would create significant privacy risks, they recommend that the government take various actions to protect the information (e.g., establish when PII can be collected, when/where information can be stored, additional encryption Start Printed Page 3878methods, and require adherence to Consumer Privacy Bill of Rights).
In addition, Professor Dorothy Glancy expressed concern that NHTSA plans to conduct its privacy analysis after the ANPRM stage of the rulemaking process and is concerned that not all potential data collection is accurately portrayed in the ANPRM.
On the other hand, while the FTC agreed that privacy concerns could exist in the V2V environment related to (1) obtaining the vehicle location information and (2) pricing insurance premiums over the driving habits, it believes NHTSA has taken these concerns into account.
Finally, many individual citizen commenters (in addition to the topics covered above) discussed their perception that this rulemaking proposes to mandate a technology that poses a potential health concern. The EMR Policy Institute 
expressed similar concerns stating that NHTSA should postpone this rulemaking until the FCC changes their guidelines regarding human radiation exposure to wireless communications.
F. SCMS RFI
Approximately 30 days after issuing the agency's Advance Notice of Proposed Rulemaking (ANPRM) 
and V2V Readiness Report, NHTSA released a Request for Information (RFI) 
regarding a Security Credential Management System (SCMS) that could support a national deployment of a V2V communication system. NHTSA was interested in hearing from entities interested in establishing components of an SCMS or the SCMS, itself. The RFI was issued separately from the ANPRM and V2V Readiness Report to give potential respondents additional time to review the more-detailed V2V Readiness Report content on the SCMS, allowing time for respondents to formulate informed responses to the Agency's questions about how an SCMS should be designed and whether they would be interested in developing or operating components or the SCMS, as a whole. As discussed in the ANPRM and V2V Readiness Report, we explained that NHTSA would not require the SCMS by regulation and did not expect to establish, fund or operate the SCMS.
Questions in the RFI covered topics such as potential governance structures for the SCMS, requests for estimates of necessary initial capital investment, how respondents believed the SCMS (or the components that they were interested in operating) could generate revenue and be financially sustainable (in order to ensure its uninterrupted operation), what respondents thought of the current SCMS design and, finally, the respondent's interest in standing up and operating some or all of the components of the national V2V SCMS.
NHTSA received 21 responses by the December 15, 2014 response closing date, and approximately 11 respondents indicated an interest in running some or all components of the SCMS. The remaining responses commented more generally on issues of potential governance and liability with two common themes: (1) That the Federal Government should take the lead in standing up and operating the SCMS; and (2) that the Federal Government should indemnify companies participating in the SCMS from liability.
The RFI respondents included vehicle manufacturers, software component developers and suppliers, cryptography experts, certificate management entities, satellite and cellular service providers and academia. Because the process of deploying cooperative V2V technology and supporting establishment of an SCMS both are unprecedented activities, the agency believed it was appropriate to meet with the subset of eleven respondents who expressed interest in operating aspects of the SCMS or the SCMS as a whole. These meetings ensured that the agency and the individual respondents shared a mutual understanding of each respondent's comments, their potential role in an SCMS, and the agency's views on the ways in which an SCMS could be established and deployed.
Meeting discussions covered a wide range of topics—including details of cryptography intricacies, certificate distribution methodologies, root storage and protection, to potential overall SCMS management. NHTSA found these meetings to be very beneficial in terms of introducing the agency to some new potential stakeholders and service providers different than the vehicle OEMs and suppliers with whom NHTSA typically. The diversity of RFI respondents exemplified the multi-stakeholder and cross-cutting nature of the V2V ecosystem.
Additional details on the SCMS RFI responses can be found in Section V.B.4.
III. Proposal To Regulate V2V Communications
A. V2V Communications Proposal Overview
The agency believes that it will not be possible to begin to address the 3.4 million crashes identified in Section II.A, especially the intersection crashes and left-turning crashes, given today's vehicle-resident technology offerings. As described earlier, the limitations of current sensor-based safety systems, in terms of direction and distance, likely will not be able to address intersection and left-turning crashes, among other potential crash scenarios, as effectively as V2V communications could.
The agency's proposal to regulate V2V technology is broken into distinct functional components, some of which have alternatives that could potentially be employed “in-conjunction-with” or “in-place-of” the agency's proposal. The distinct functional components are: The actual communications technology itself (Section III.E), proposed messaging format and content requirements (Section III.E.2), authenticating V2V messages (Section III.E.3), V2V device misbehavior detection and reporting (Section III.E.4), malfunction indication requirements (Section III.E.5), software and certificate updating requirements (Section III.E.6), and proposed cybersecurity related requirements (Section III.E.7).
B. Proposed V2V Mandate for New Light Vehicles, and Performance Requirements for Aftermarket for Existing Vehicles
NHTSA's proposal would require that new light vehicles include vehicle-to-vehicle communication technology able to transmit standardized BSMs over DSRC as described in Section III.E below, beginning two years after issuance of a final rule and phasing in over the following three years at rates of 50 percent, 75 percent, and 100 percent, respectively. “Light vehicles,” in the context of this rulemaking, refers to passenger cars, multipurpose passenger vehicles, trucks, and buses with a gross vehicle weight rating of 10,000 pounds (4,536 kilograms) or less.
The agency Start Printed Page 3879believes that this amount of lead time and phase-in is needed based on the potential for device supply constraints to generate production-level quantities of devices required by automotive OEMs to meet the standard 
and to allow flexibility for vehicle refresh and re-design cycles. The proposal also allows vehicles to comply using non-DSRC technologies that meet certain performance and interoperability standards.
In addition to requiring new light vehicles to be able to transmit and receive BSMs over DSRC, the proposal would also require that similarly-capable aftermarket devices achieve the same DSRC performance.
Besides being the first FMVSS to involve vehicles relying on information transmitted by other vehicles, this FMVSS would also be the first to incorporate elements of secure wireless communication protection directly into the performance requirements.
New motor vehicles are increasingly computerized, and given the importance of ensuring the availability and integrity of safety-critical systems, we considered which requirements could best be incorporated into an FMVSS and which should be part of the V2V security system instead. V2V security requirements are discussed in Section III.E.3 and Section III.E.7, along with a discussion of privacy and security in Section IV.
The agency has put forth this proposed rule on the basis that a fully-implemented V2V system, as currently envisioned, is a compilation of many elements that provide a data-rich technology platform that ensures secure and interoperable communications enabling safety warnings and advisories for drivers. As described in the V2V Readiness Report, V2V devices send out BSMs to alert other vehicles to their presence, and receive BSMs from other vehicles in order to determine whether to warn their drivers of an imminent crash situation. BSMs must be accompanied by message authentication capabilities so that the receiving V2V communication will allow suppliers and vehicle manufacturers to innovate and spur the market for applications that will provide consumers increased safety.
The agency believes that a mandate for all light vehicles is necessary to achieve the safety goals of this proposal. The two vital pieces in order to achieve these crash avoidance benefits are (1) ensuring interoperable V2V communications, and (2) achieving a critical mass of communicating vehicles in the American fleet. NHTSA believes that this proposal is the only way to achieve these two pieces because of the lagging adoption of advanced safety technologies in the marketplace. As evidenced by the slow voluntary deployment of vehicle sensor-based advanced driving assistance systems, the agency believes that it will be even more difficult to achieve a critical V2V implementation level without a mandate due to the cooperative nature of the V2V system. If it cannot reach a critical deployment level within a certain timeframe, the safety benefits of V2V would drop dramatically, and manufacturers would have much less incentive to develop the safety applications (despite their relatively low costs) because they would not have a reason to make the initial investment to install the V2V communications equipment. This represents a classic “collective action” problem, of the sort that government regulation is designed to address. We do not believe that critical mass can be achieved, allowing the life-saving benefits of V2V to come to fruition, in the absence of a government mandate. We seek comment on these tentative conclusions.
NHTSA received a number of comments to the ANPRM and the V2V Readiness Report suggesting that V2V communication technology could be better encouraged through what the agency refers to as an “if-equipped” standard rather than a mandate for all new light vehicles—i.e., that NHTSA should simply set a standard saying “if a new vehicle is equipped with devices capable of V2V communications, then it should meet the following requirements.” While both options are within the agency's regulatory authority, we continue to believe that requiring V2V communication technology for new light vehicles will be the quickest and most effective way to achieve fleet-wide V2V communication technology deployment and ensure the full safety potential of this technology is realized.
Allowing manufacturers to choose whether to apply V2V technology in new vehicles could have two main risks in terms of holding back potential safety benefits. First, it is uncertain how manufacturers would voluntarily deploy V2V capability. Manufacturers typically have implemented new vehicle-resident technologies in their more expensive vehicles first. If manufacturers take this approach for V2V, NHTSA believes that a segmented approach to implementation of V2V technology will not be enough to quickly precipitate the data-rich environment needed to support development of manufacturer-supplied safety applications, or to support the needed establishment of a V2V communications security system. Leaving the pace of that development to the market will, we believe, delay the life-saving benefits of those safety applications because the effectiveness of applications depends on receiving messages from all other vehicles. Second, if fewer vehicles are equipped with V2V, there may be less incentive for industry to develop a sufficient security system, which will feed into concerns from consumers regarding perceived potential privacy and cybersecurity issues. Taken together, the delayed effectiveness of the safety applications plus potentially increased concerns about security may lead manufacturers not to include V2V capability in a significant amount of vehicles at all. For these reasons, NHTSA proposes to require new light vehicles to be V2V-capable.
NHTSA and, we believe other stakeholders, will be working to educate consumers about V2V, and will ensure that the V2V system is designed to minimize security risks and protect privacy appropriately. We believe consumer education will alleviate fear of the unknown as V2V enters the vehicle fleet. Findings from our consumer research between the ANPRM and this NPRM are discussed below in Section IV, and NHTSA will be considering these issues carefully as we move forward.
While we are proposing a V2V communications mandate, we also seek further comment on the costs and benefits of an “if-equipped” option, particularly considering the substantial monetary and potential social costs of a mandate. Do commenters believe an if-equipped option would be a preferable approach, and if so, why? What costs and/or benefits should we consider relative to an if-equipped approach, and how do those costs and benefits compare to our analysis of the costs and Start Printed Page 3880benefits of a mandate? For instance, we seek additional comment on how an if-equipped option may potentially delay or lead to uncertainty in V2V technology development.
In addition, what benefits may accrue from a more gradual, market-based approach to a technology that has never before been widely deployed? What affect would such an approach have on the ability to iterate and test potential V2V technology solutions, including issues related to costs, reliability, security, and deployment? How would an if-equipped approach affect consumer choice and privacy protections? We also seek examples and information related to the success and failure of other network-reliant technologies, including those that evolved in the absence of a government mandate and those that were mandated and whether the example is applicable or not to a safety sensitive function.
C. V2V Communication Devices That Would Be Subject to FMVSS No. 150
1. Original Equipment (OE) Devices on New Motor Vehicles
NHTSA's research thus far indicates that V2V communications technology is feasible for new light vehicles. The Safety Pilot Model Deployment demonstrated that interoperability is possible and directly informed the requirements in this proposed FMVSS and also in SAE standards such as J2735 and J2945. The agency is confident that V2V devices integrated into light vehicles consistent with these requirements will provide the technical foundation for national deployment of DSRC-based crash avoidance capability.
2. Aftermarket Devices
Many consumers may not be ready to purchase a new vehicle, but may be interested in having V2V capabilities in their current vehicles. NHTSA believes that it is likely that aftermarket products may be developed in response to consumer interest in V2V, and we strongly support the innovation and accessibility that aftermarket devices could foster, all potentially leading to expanded and earlier benefits from V2V communication technology. As the name suggests, “aftermarket” refers to products that the vehicle owner purchases and adds to his or her vehicle after the vehicle's manufacture. Aftermarket products are distinguished from “original equipment,” which is installed on the vehicle during its manufacture, prior to initial purchase. Allowing aftermarket products to participate in the V2V system will enable the technology to spread faster than if introduced through new vehicles only—thus accelerating safety benefits.
As part of setting standards for aftermarket V2V devices, however, NHTSA recognizes that some aftermarket products may not be able to populate optional BSM data elements if they do not have access to the CAN bus. Aftermarket devices will therefore need to use other methods to populate elements needed to calculate vehicle position in order to support crash avoidance warnings. Some data elements, such as turn signal indication, will not be able to be derived from other methods. As a result, the inability of some aftermarket devices to populate certain optional BSM data elements may impact the fidelity (ability to balance the level of false positive warnings) of safety applications that the aftermarket device supports. In the Safety Pilot Model Deployment, there were three separate types of “aftermarket” devices—some that were fully integrated into the vehicle just like original equipment; some that were connected to the vehicle for power, but did not have access to the vehicle's data bus; and some that also only connected for power, and could only transmit BSMs but could not receive them and could not deliver crash avoidance warnings. Based on the information we currently have before us, we think it is reasonable to assume that these three types of aftermarket devices could be available in the rulemaking timeframe.
For example, OEMs may choose to offer their own aftermarket V2V devices that can be retrofitted onto earlier vehicle models (retrofit means the devices can interface with the vehicle data bus), made by that OEM, at one of their retailers. For another example, V2V devices, which are not unlike today's dedicated aftermarket navigation systems (e.g., a Garmin or TomTom), could potentially be developed for drivers to purchase and have installed. The agency also foresees the potential for some form of a multi-use device containing a V2V-related application (“app”) that could be brought into a vehicle (“carry-in”) by a driver. A carry-in device could have the capacity to simply send a BSM without providing any warnings to the driver or potentially provide more capabilities in a potential V2V, or V2I, system. Moreover, in the future, there could be yet other types of aftermarket devices that have V2V capabilities not yet envisioned by NHTSA.
NHTSA does not wish to limit the development of different types of aftermarket devices, but we do seek to ensure that all devices participating in the system perform at a minimum or better performance level for V2V communication. This is important because, in order to ensure safe and secure crash avoidance benefits, all BSMs transmitted need to perform at a minimum performance level such that safety applications can identify imminent crash situations and issue warnings to the driver to avoid a crash. Therefore, the minimum performance requirements need to be the same for all devices with provisions that accommodates the optional data elements that can be used to perform better than the minimum.
The proposed requirements for any V2V devices recognize that, as DOT discovered in the Safety Pilot Model Deployment, installation can significantly impact how devices perform. The agency believes there is high probability that a certified device installer could complete the installation for aftermarket safety devices. It is imperative that all V2V components be properly installed to ensure that an aftermarket device functions as intended. Whereas some vehicle owners may choose to replace their own brakes or install other components on their vehicles themselves, installation requirements for aftermarket V2V devices may not be conducive to a do-it-yourself approach. Improper installation of a GPS antenna has the potential to affect the proper population of BSM data elements. Faulty position data from a transmitting vehicle can result in false warnings, improperly timed warnings, etc. Moreover, an improperly installed aftermarket device may put all other V2V-equipped vehicles it encounters at risk until the given vehicle stops communicating, or until its messages are rejected for misbehavior.
The agency seeks comment on the potential need for certification of aftermarket V2V device installations. If so, please provide any potential recommendations of appropriate retail outlets, the certification mechanisms, and authorizers (vehicle manufacturers, device manufacturers, device retailers, others) that should be employed. Conversely, do commenters believe that future available technology may allow consumers to self-install V2V devices such as web-based tools, or other potential methods, that could verify accuracy of an installation? Research supporting this possibility would be very helpful.Start Printed Page 3881
D. Potential Future Actions
1. Potential Future Safety Application Mandate
NHTSA has concluded that V2V communication technology combined with V2V-based safety applications can provide significant safety benefits and potentially help drivers avoid thousands of crashes per year. We believe that by leading with a mandate for V2V communication technology, NHTSA will be able to foster industry development and deployment of new, beneficial safety applications. As previously discussed in the V2V Readiness Report and in the above discussion concerning the safety need, there are a number of these applications that the agency believes could be ready to be deployed soon after a V2V mandate is in effect. In particular, the agency has highlighted two specific applications, IMA and LTA.
The agency focused on these potential safety applications because prototypes of these applications were used during Safety Pilot Model Deployment, because we have sufficient data, and because they can be effectively enabled only by V2V. IMA warns drivers of vehicles approaching from a lateral direction at an intersection, while LTA warns drivers of vehicles approaching from the opposite direction when attempting a left turn at an intersection.
As discussed in the V2V Readiness Report, the agency has and will continue to investigate other potential V2V safety applications that could be enabled by V2V communications.
Depending on the market penetration of applications in response to this proposed mandate of the foundational V2V capability, the agency may later decide to mandate some or all of the potential applications discussed in the Readiness Report, and perhaps future applications yet to be developed. If mandated in the future, applications would likely be incorporated into NHTSA's regulations as FMVSSs, and in the interests of clarity, each application mandate would likely be contained in its own FMVSS.
At this time, though, the agency does not have sufficient information to include with this NPRM proposed test procedures or performance standards for LTA and IMA or any other safety applications. To that end, we request comment on any additional information or research on IMA, LTA and any other applications that could inform and support an agency decision regarding whether to mandate safety applications with or shortly after a final rule requiring DSRC.
2. Continued Technology Monitoring
NHTSA's proposal to mandate V2V communications capability for new light vehicles is based upon the best currently-available scientific data and information. Consistent with its obligations under Executive Order (E.O.) 13563, Improving Regulation and Regulatory Review (Jan. 18, 2011), and E.O. 13610 on the retrospective review of regulations, NHTSA will review relevant new evidence and may propose revisions to a subsequent proposed or final rule as necessary and appropriate to reflect the current state of the evidence to provide an effective regulatory program. In obtaining that new evidence, NHTSA may consider collections of information that may trigger the Paperwork Reduction Act, and would notify the public of these collections through the separate Federal Register Notices required under that Act. NHTSA may also identify and pursue additional issues for new research or conduct further research with regards to existing issues addressed in this proposed rule. Such modifications may be necessary in the future to accommodate new systems and technology designs, and the agency would consider these modifications in consultation with the public through the notice and comment rulemaking process. We acknowledge that the research relevant for evaluating a new technology would vary depending on the type of technology considered.
E. Performance Criteria for Wireless V2V Communication
In order to ensure that vehicles broadcast basic safety messages to support potential safety applications, the agency is proposing performance requirements for DSRC-based V2V communications. As part of this, the agency is also requesting comment on alternative interoperable technology provisions that would allow other technologies to satisfy the mandate, as long as they meet performance and interoperability requirements, which are based on the capabilities of today's DSRC-based V2V communications.
The agency is proposing to require that V2V devices be capable of broadcasting V2V messages in an interoperable manner, i.e., that devices can both transmit and receive BSMs using V2V communications from all other vehicles equipped with a V2V communications technology. We believe that the requirements described below will ensure interoperability. We aim to ensure a uniform method for sending basic safety information about the vehicle. In this way, any vehicle seeking to utilize the V2V information environment to deliver safety benefits would have a known and uniform method for doing so.
In order to create this uniform method, an FMVSS would need to contain requirements in a few areas. First, it would need to establish the content of the information to be sent to the surrounding vehicles (by not only specifying the type of information to send, but also the measuring unit for each information element and the level of precision needed). Second, the FMVSS would need to specify requirements for the wireless transmission of the content (i.e., how far, how often, etc.). Third, we may need to specify a standard approach to authenticate V2V messages that are received to improve confidence in message contents.
In addition to those three points, the FMVSS would also need to specify other aspects of performance for a V2V-communications system in order to support full-scale deployment and enable full functionality including security. The agency recognizes that some capabilities are not necessarily needed to support operations during the first few years of deployment, but would be required as the V2V vehicle fleet grows.
First, the devices regardless of the communication technology used would need a uniform method for dealing with possible occurrences of high volumes of messages (e.g.., potentially reducing the frequency or range of messages in high congestion situations. Second, to help identify and reduce the occurance of misconfigured or malicious devices transmitting BSM messages, the FMVSS may need to specify methods for identifying misbehaving devices. Finally, to support the above functions, vehicles in the V2V environment may need a methods for communicating with security infrastructure such as a SCMS (e.g., in order to obtain new security certificates or report misbehaving devices, and receive information about misbehaving devices).
In short, an FMVSS would explain: (1) What information needs to be sent to the surrounding vehicles; (2) how the vehicle needs to send that information; (3) how a vehicle validates and assigns confidence in the information; and (4) how a vehicle makes sure the prior three functions work in various operational conditions (i.e., broadcast under congested conditions, manage misbehavior, and update security materials). A variety of voluntary Start Printed Page 3882standards cover many of these aspects of performance. Our proposal below draws from these voluntary standards but also explains why a particular threshold or requirements from a voluntary standard is appropriate. Finally, we are proposing a test method for evaluating many of these aspects of performance. Having a clear test method helps inform the public as to how the agency would evaluate compliance with any final FMVSS.
Finally, we acknowledge that research is ongoing in a few of the areas we discuss in this section. While research continues in these areas, we have described for the public the potential requirements that we are considering, and the potential test methods for evaluating compliance with those requirements. We believe that the public comments that we will receive in response (coupled with the agency's ongoing research) will produce a robust record upon which the agency can make a final decision.
1. Proposed Transmission Requirements
Our purpose for proposing a standardized set of transmission requirements is in line with our vision for V2V as an information environment that safety applications can use. By creating a standardized method for transmitting the basic safety message, we are creating the information environment with one clear method for accessing it. Our current belief is that anyone who wants to implement safety applications should know how their system can obtain the V2V information as an input for their application.
In order to have a standardized method for transmitting the basic safety message we believe that a few aspects of performance need requirements. We tentatively believe that all devices should be required to transmit:
- With a sufficient power/range to guarantee reaching other DSRC devices, within a minimum radius, that would allow use of the basic safety message information reliably;
- on the same channel, and support using the same data rate(s); and
- at the times required for each data element so that people who have applications know when it will have information.
(a) DSRC Transmission Range and Reliability
In order to ensure that surrounding vehicles within a certain range of each vehicle transmitting basic safety messages can reliability receive the messages, The proposal includes requirements for the transmission range of the messages. While the research to date has included various specifications for the antenna (e.g., power, polarization, location on the vehicle, etc.), we tentatively believe it more appropriate to measure the ability of the vehicle to transmit the packet to a specified device at a specified distance. In other words this transmission range and reliability requirement employs a more performance-oriented approach where our FMVSS would not specify requirements for the antenna itself.
By specifying the requirements in this fashion, we not only set requirements that can more closely follow real-world conditions, but also leave aspects of design open to manufacturer choice (e.g., antenna location on the vehicle). Our method here would simply seek to ensure that the transmission of the basic safety message travels the required distance and is readable by another DSRC device at that range (regardless of how the antenna is configured). Thus, we seek comment on our proposal. We currently believe that specifying the following three areas would be appropriate:
- The three-dimensional (latitudinal, longitudinal and elevation) minimum range that the basic safety message transmission would need to reach;
- a test device (and its specifications, e.g., its receive sensitivity) for testing the range and the locations to measure reception of the basic safety message; and
- the reliability of the reception of the basic safety message (i.e., how often is the message dropped) based on packet error rate (PER).
In addition, our current belief is that the agency would not need to establish specifications for the transmitting device itself. In other words, we request comment on our current belief that the following design-level requirements would not be necessary for an FMVSS:
- Transmission power;
- antenna polarization; and
- antenna placement.
A basic safety message needs to travel far enough to support potential safety applications that we anticipate would take advantage of the information available through DSRC communications. Aside from the basic “open air” communication scenarios, it is important to also consider whether devices will be able to communicate with others that are on the same road but, perhaps, not at the same elevation or approach angles (i.e., the road elevation may change).
(a) Longitudinal/Lateral Range
Our strategy we considered regarding what minimum range requirement we should include for transmitting the basic safety message was to balance:
- The information needs for potential safety applications; and
- technical capabilities demonstrated.
In terms of information needs for the safety applications, our research to date used a minimum 300 m transmission range—while recognizing this range would diminish in urban and non “open air” environments. The applications tested in the Safety Pilot Model Deployment assumed vehicles were transmitting basic safety messages at the 300 m range. In particular, we believe that DNPW requires the longest communication range for effective operation because it addresses a crash scenario where two vehicles approach each other head-on. Using the target range of 300 m, two vehicles approaching at 60 mph would be afforded approximately 5.6 seconds for the DNPW application to detect the crash scenario and issue a warning. Based on this information, our current belief is that 300 m will serve the needs of the anticipated safety applications.
Based on the existing research, our proposal is to adopt 300 m as the minimum transmission range. We believe that this supports the needs of anticipated safety applications and can be operationally met given current technological capabilities; as demonstrated in Safety Pilot Model Deployment. Currently, we also do not anticipate any safety application requiring more range than 300 m. Thus, we tentatively do not see a reason to increase the minimum transmission range beyond 300 m.
Finally, we have not included a maximum range limit. Maximum transmission range can vary by the power of the transmission, and environmental conditions. While our current proposed requirements do not include establishing a maximum transmission range, we request comment on whether such a limit would be appropriate in conjunction with the other requirements the agency is considering.
We ask for comment on this proposed minimum. Is there any reason that the agency should require a maximum transmission range as well as a minimum? Should the agency choose a different minimum range requirement? What would be appropriate alternative minimum and maximum transmission range values and why? Please provide data to support your position.Start Printed Page 3883
(b) Elevation Transmission Performance
In addition to the 2-dimension range of the basic safety message transmission, we need to consider the potential changes in elevation on roadways. Thus, in addition to establishing a minimum distance that the basic safety message needs to travel, we also need to establish an elevation angle that the message needs to travel.
Safety applications may need information from vehicles at a higher elevation (because of changes in the slope of the roadway, for example). Thus, our current belief is that a proposal to regulate DSRC radio performance should also evaluate whether a vehicle transmitting the basic safety message can transmit said message at an angle that is sufficient to cover potential roadway elevation changes.
Our proposal would require that vehicles transmit the basic safety message not only to 300 m around a vehicle (in all directions—i.e., 360 degrees) but also at an elevation angle of + 10 degrees and −6 degrees. We think that the elevation angle range of + 10 to −6 degrees 360 degrees around the vehicle is an appropriate range to ensure that the broadcast of the BSM can be received by vehicles in a 300m radius given most roadway characteristics such as changes in roadway grade was what was used to demonstrate capability in Safety Pilot Model Deployment. The agency is continuing to research a larger range of elevation angle (+/−10 degrees) to determine actual transmission coverage range. In particular, if the range would be adequate to support transmission and reception of BSMs on roadway grades up to 15 degrees, which is the current design maximum for many States and localities (excluding San Francisco). However, currently it is not practicable to test the +/−10 degree elevation angle range given current testing equipment.
We ask for comment on this proposed minimum. Should the agency choose a different minimum elevation angle requirement? What would be appropriate alternative minimum elevation angle range values and why? Please provide data to support your position.
(2) Testing the Elevation Transmission Range
In order to give context to our proposed requirement, we are also describing the method the agency would use in assessing the elevation angle range performance requirement (i.e., the test procedure and type of test device). As discussed later in this document, the agency would test these requirements using test devices located within a specified area around the vehicle in a static test to determine whether the vehicle's basic safety message transmissions can reach the required range. In order to conduct this test, we need to define two pieces of information:
- The important characteristics of the test device for the purposes of evaluating this requirement; and
- the area around the vehicle where we can place this test device.
(a) Test Device
As further discussed in the test procedure section of this document, we anticipate that our test method would specify various aspects of the test device for the purposes of evaluating a vehicle's DSRC radio performance. However, for the purpose of evaluating this aspect (i.e., the transmission range) of DSRC radio performance, we believe the receive sensitivity of the test device is the characteristic that would need to be most clearly defined in order to test the transmission range objectively.
Based on the currently-available research, the agency would measure this using a test device with a sensitivity of −92 dBm. We believe that −92 dBm is an appropriate sensitivity for the test device receiving the basic safety message during the test because −92 dBm generally models what average devices (e.g., cell phones) use for their antenna sensitivity. We believe that it is a reasonable assumption that a vehicle seeking to obtain basic safety messages for its safety applications would be designed with, at minimum, this level of sensitivity.
Further, our understanding is that −92 dBm falls on the less-sensitive side of the range of an average wireless device's antenna sensitivity. We believe that using a less sensitive device within that range is appropriate in this instance because it means we are using a more stringent test condition that is still within the range of an average device antenna's sensitivity.
(b) Location of the Test Device
In addition to specifying the device, we also believe it is important to specify the location of the device relative to the vehicle being tested. We are proposing to define a zone around the vehicle where a test device is used to evaluate the ability of the vehicle to receive the basic safety message. Currently, the proposed zone is defined as 300 m 2-dimensional range with an elevation angle that can be set at + 10 degree and −6 degrees.
For testing the 2-dimensional (longitudinal and lateral) range, the agency would specify an area within a circle around the vehicle that we may test. The test circle has the following characteristics:
- It is 1.5 m above the test surface.
- It is parallel to the test surface.
- It has a center point that is 1.5 m above the vehicle reference point.
- The circumference of the circle is any point at a 300 m radius from its center point.
In other words, when conducting the compliance test, the agency test engineer may place the test device at any point that is 1.5 m above the ground and within the area of a circle whose center point is 1.5 m above the vehicle reference point and whose radius is 300 m.
For testing the elevation range of the vehicle's transmission, we tentatively believe it is preferable to use two slightly different evaluation methods for the upward elevation versus the downward range. For the upward elevation range, our proposal is that the test engineer may place the test device at any point along the following line:
- The line originates at a point that is 1.5 m above the vehicle reference point.
- The line rises at a +10 degree angle from the test surface 
proceeding in any direction around the vehicle.
- The line terminates at any point that is directly above the circumference of the circle used in the 2-dimentional range test.
On the other hand, for testing downward elevation range, the agency would place the test device at any point along the following line:
- The line originates at a point that is 1.5 m above the vehicle reference point.
- The line falls at a −6 degree angle from the test surface 
proceeding in any direction around the vehicle.
- The line terminates at any point where it intersects the test surface.
Test the downward elevation at a point that is likely closer to the vehicle than the upward elevation, we believe that this method would relieve some test complexities while still ensuring Start Printed Page 3884that the transmissions will reach surrounding vehicles under real-world roadway elevation changes. Further, we believe that the locations defined above (longitudinal, lateral, and elevation) establish the limits of the potential test conditions in a way that would still enable the agency to measure at the extremities of the proposed range requirement.
As noted above, testing the elevation range would enable NHTSA to test for compliance at any point along those aforementioned lines. While we believe that −92 dBm is an appropriate sensitivity for our test device when it is located 300 m away from the tested vehicle, we request comment on whether the test device should still have a sensitivity of −92 dBm if NHTSA tests the vehicle performance closer to the vehicle along the aforementioned elevation testing lines. What would the appropriate function be to determine the sensitivity based on the test device's location along those testing lines?
We further request comment not only on the test method but also on whether there are other aspects of the test that the agency would need to define in order to clearly evaluate this aspect of performance.
The agency is proposing to require that a message packet error rate (PER) is less than 10%. We believe that 10% PER is an appropriate threshold and that vehicles will still be able to receive the basic safety messages so long as the PER is below 10%. The agency believes the PER metric at the proposed rate fulfills the need to evaluate how reliably a V2V device can transmit a message for a specified distance.
The Packet Error Rate (PER) is one way of quantifying how reliably a message can travel a given distance. In essence, it measures how often (i.e., the percentage of) parts of the message (i.e., packets) fail to make it to the destination. The research for V2V safety applications to date assumes that vehicles are transmitting the basic safety message to a range of at least 300 m around the vehicle with a PER of less than 10%.
A PER of less than 10% aligns with the ASTM standard E2213-03 (2003) 188.8.131.52 where “(2) DSRC devices must be capable of transferring messages to and from vehicles at speeds of 85 mph with a Packet Error Rate (PER) of less than 10% for PSDU lengths of 1000 bytes and to and from vehicles at speeds of 120 mph with a PER of less than 10% for PSDU lengths of 64 bytes.” As such, the agency believes this specification, along with the agency's successful Safety Pilot Model Deployment work, makes it appropriate to include this as part of the performance requirements for DSRC devices. Overall, the agency did not observe any dropped basic safety messages (i.e., message did not reach a vehicle within range) due to a high PER, and we believe that the 10% PER threshold will continue to be appropriate in a more full-scale deployment. We request comment on our tentative conclusions and also request comment on what other potential PER thresholds would be more appropriate (and why).
(4) Aspects of Transmission Range Performance Indirectly Tested
We currently believe that testing the range (both 2-dimensional and elevation) and the reliability (PER) of the transmission with a specified test device (−92 dBm) in specified locations is sufficient to determine whether a vehicle would be able to deliver basic safety messages to vehicles around it in the real world (i.e., it would be sufficient for supporting the safety applications currently under active development). However, we recognize that there are a few aspects of performance covered by the V2V research to date that we have not included in this proposal. Our tentative conclusion is that the proposed requirements would cover these aspects of performance indirectly. Further, we believe that Proposal A would avoid unnecessarily restricting manufacturer design choices while still ensuring that the vehicle achieve the safety purpose of transmitting the basic safety message. These aspects of performance are:
- Antenna location on the vehicle;
- antenna polarization; and
- transmit power.
(a) Antenna Location on the Vehicle
The agency and its research partners utilized antenna location mounting requirements on vehicles used in the Safety Pilot Model Deployment activity. However, our tentative conclusion is that it is unnecessary to specify requirements for antenna location. The location of the antenna on a vehicle can affect the ability of the vehicle to transmit the basic safety message to all the necessary locations around the vehicle. However, we believe that testing for reception of the basic safety message at the aforementioned locations around the vehicle would clearly show whether the location of the vehicle antenna is installed at an appropriate location where the vehicle structure would not interfere with the transmission of the basic safety message.
If the antenna location is appropriate enough to transmit the basic safety message to meet the needs of the safety applications, we tentatively see no need to further restrict the location of the antenna on the vehicle (as it is also an important styling decision for the auto manufacturer). However, we request comment on this tentative conclusion. Are there any reasons why the agency should establish requirements for the antenna location on the vehicle? What would these restrictions be? How can they be objectively defined on the vehicle? What data supports your conclusions?
(b) Antenna Polarization
We also tentatively believe that the agency does not need to establish performance requirements for the transmitting antenna's polarization. We are aware that the research to date generally recommended a nominal vertical polarization configuration for the DSRC antennas sending the basic safety message. The research recommended that configuration because vehicle sheet metal can serve as the ground plane and can degrade reception of horizontally polarized waves at or near the horizon.
While we agree that using a non-optimal antenna polarization would lead to increased cost and complexity of the system (i.e., requiring more antennas in order to reach the same transmission coverage), we tentatively do not believe it is necessary to propose limiting such a design. We believe that, for cost considerations, manufacturers are likely to select an antenna polarization that would enable them to achieve the same performance with less antennas. However, so long as the vehicle can transmit the basic safety message to the required range under the conditions specified, we currently see no reason to preclude other antenna polarizations. We also request comment on this tentative conclusion.
(c) Transmit Power
Finally, the requirements and test method also do not directly test for the transmit power. Our current belief is that our test method sufficiently covers this aspect of performance by establishing the range at which the vehicle needs to transmit the basic safety message and the receive sensitivity of the test device. We note that the research to date has recommended various transmission power levels. For example, the SAE J2945/1 standard recommended a minimum radiated power of 15 dBm (under uncongested condtions). However, we believe that our Start Printed Page 3885aforementioned requirements would sufficiently test for this aspect of performance. In essence, by testing whether a device with a sensitivity of −92 dBm can receive messages from a vehicle 300 m away, we are testing whether the transmitting vehicle is doing so with sufficient power to deliver the basic safety message to the required distance.
We currently do not believe it is necessary to further specify the transmit power for vehicles covered by the proposal. Based on the manufacturer's choices regarding antenna location on the vehicle (and potentially other factors such as the body of the vehicle, etc.), a manufacturer may need to make different transmit power choices in order to transmit the message to the required distance. As with antenna location and polarization, we believe that the transmission power is sufficiently addressed (albeit indirectly) by the requirements. We believe that the requirements would establish an appropriate balance between affording the manufacturers design freedom, while still ensuring that they achieve the safety goal of transmitting the basic safety message far enough and reliably enough to support the safety applications. We seek comment on whether there is any reason for the agency to establish a requirement for the transmit power. What should the transmission power be and why?
(5) FCC Transmission Power Restrictions
The agency's proposal is not specifying required transmission power levels for V2V devices. The FCC places restrictions on the transmission power levels of devices utilizing a given spectrum and our expectation is that DSRC devices operating in the designated bandwidth would meet the FCC defined operating specifications. However, we do not believe that our current proposal (i.e., our proposed minimum transmission range and the sensitivity of the test device) would require vehicles to transmit at a power that exceeds FCC regulations.
FCC Part 95L specifies a max EIRP limit of 33dBm for Private OBUs on channels 172, 174, 176, 178, and 184. Our understanding is that devices would be able to meet the these requirements at a power setting lower than the restricted level (Safety Pilot Model Deployment devices were set at a 20 dBm power level).
(b) Channel and Data Rate
In addition to proposing requirements for the transmission range and reliability, we believe it is also important for DSRC-based V2V communications to utilize the same channel and data rate. The channel is a band of frequencies where the transmission occurs. Parties agreeing to use the same channel to communicate are like people that agree to call each other using a particular phone line. The data rate is the speed at which a sender is transmitting information through the channel.
The FCC has statutory authority for allocating spectrum rights and designating band plans for commercial spectrum allocations, including the 5.9 GHz band. DOT defers to the FCC's authority with respect to spectrum rights and channel plans. Based on FCC rules and research to-date, all devices participating in the V2V information environment have utilized the same channel and data rate to transmit BSMs. In relation to DSRC, FCC has specified that BSM transmissions and reception will occur on channel 172, i.e. channel 172 will be dedicated to all BSM communications (safety-critical communications). Therefore, throughout this document, references to BSM transmissions and reception will refer to channel 172 while also recognizing the ongoing DOT-FCC-NTIA spectrum sharing studies and the FCC rulemaking concerning the 5.9 GHz band as described in more detail below. Similar to our approach to transmission power, the agency believes that all BSM transmissions should occur on channel 172. Data rate is also important because a receiving device needs to know the speed at which the transmitting device is sending the information in order to process the information. Thus, in order to ensure interoperability of the devices in the V2V information environment, our current belief is that it is necessary to establish requirements for both the channel and the data rate.
As we discuss below, there are various options for both the channel and the data rate—each with advantages and disadvantages. While there are different choices available, each choice should be able to achieve the objective of ensuring interoperability across devices if it is implemented consistently by all devices. Thus, we are proposing to that all vehicles should transmit the basic safety message on Channel 172, via a dedicated radio at a data rate of 6 Mbps). We also request comment on whether there are other choices for these two aspects of performance that the agency should consider.
(i) Proposed Channel Usage
The FCC currently divides the 5.9 GHz spectrum into seven, ten- megahertz channels consisting of one Control Channel (Channel 178); six Service Channels (Channel 172 for safety-critical communications and Channels 174, 176, 180, 182, and 184 for non-safety-critical communications); and one five megahertz channel, which would be held in reserve. The FCC also allows combining Channels 174 and 176 or Channels 180 and 182 to produce two twenty-megahertz channels, (which would be Channel 175 and 181, respectively).
As we discussed in the sections above, we believe that devices participating in the V2V information environment need exchange messages on the same channel in order to receive each other's broadcasts (i.e., to hear the messages that others send). Up until now, the V2V devices transmitting basic safety messages in the V2V research have used Channel 172 (a 10 MHz channel). The research used a 10 MHz channel as the FCC's current rules for the V2V spectrum divide it into various 10 MHz channels.
Our tentative conclusion is that broadcasting on Channel 172 via continuous mode (radio set to channel 172, a 10 MHz band) is appropriate for devices in the V2V information environment. Thus, we believe that all vehicles should transmit their basic safety messages on the same channel (172). Our tentative conclusion is based on our understanding of the existing research and in alignment with the FCC spectrum allocation. The agency expects that all non-safety-critical communications will occur on the remaining channels allocated for DSRC use by the FCC. The research suggests that a 10 MHz band is sufficient for transmitting the basic safety message to the necessary 300 m range at a sufficient level of reliability PER of less than or equal to 10%.
We seek comment on all related issues we should take into account when considering this proposal, as well as any other potential alternatives.
(ii) Potential Channel Sharing or Re-channelization
NHTSA and the U.S. DOT are committed to finding the best method to develop, successfully test, and deploy advanced automotive and infrastructure safety systems while working to meet existing and future spectrum demands. DOT supports sharing so long as it does not interfere with safety of life communications. In the summer of Start Printed Page 38862015, recognizing the emerging need to perform further research on DSRC properties in order to prepare for studies on sharing, DOT worked collaboratively with the FCC and NTIA to develop a spectrum research plan. This plan (the “DSRC-Unlicensed Device Test Plan”) is posted on DOT's Web site and details a comprehensive set of research opportunities. The plan will allow FCC, NTIA, and DOT to collectively tailor research on DSRC devices in the presence of unlicensed devices to understand the prospective impacts within real-world environments.
The overall goals and objectives of this research are as follows:
- Overall Goals as listed in the DSRC-Unlicensed Device Test Plan
1. Understand the impacts of unlicensed devices operating in the DSRC band.
2. Develop the capability to evaluate proposed band sharing mechanisms.
3. Define requirements necessary for sharing mechanisms to prevent interference.
4. Collaborate with the NTIA and FCC to provide Congress with results on impacts to DSRC operations from proposed sharing mechanisms.
- Specific Objectives and Goals as listed in the DSRC-Unlicensed Device Test Plan
1. Develop the capability to do accurate and relevant experimental evaluations of band sharing and interference between unlicensed devices and DSRC devices.
2. Characterize the existing radio frequency (RF) signal environment in and near the DSRC band.
3. Measure the effect of unlicensed devices on the background noise level.
4. Measure the impact unlicensed device transmissions have on receiving DSRC messages.
5. Measure DSRC suppression caused by Clear Channel Assessment (CCA) of DSRC devices in the presence of unlicensed device transmissions.
6. Measure other impacts on DSRC channel quality of unlicensed device transmissions (e.g., signal to noise (S/N), packet error rate (PER), etc.).
7. Determine the minimum received power levels at which DSRC and unlicensed devices can sense the other.
8. Investigate how interference and detection (determined in the previous objectives) varies if the bandwidth of the overlapping unlicensed device transmission changes.
9. Measure the impact of DSRC operations on unlicensed device performance recognizing that the two radios may form an interactive system.
10. Investigate mitigation possibilities once potential U-NII-4 devices designed and programmed to share the band with DSRC are available.
This DOT testing effort is part of a larger collaborative testing and modelling effort with the FCC and DOC, encouraged by Congress, to ensure appropriate interference-avoidance and spectrum rights allocation in the 5850-5925 MHz (5.9 GHz) band. Congress called upon DOT to lead, in close coordination with FCC and DOC, the development of 5.9 GHz Dedicated Short Range Communications (DSRC) technology, vehicle safety testing, and DSRC capabilities testing. Furthermore, Congress called upon NTIA to study the possibility of allowing unlicensed operations in the 5.9 GHz band. The U.S. Department of Transportation (DOT), the U.S. Department of Commerce (DOC), and the Federal Communications Commission (FCC) each have core, yet interdependent, roles to play in advancing this research.
Recently, the FCC issued a Public Notice to refresh its record regarding its draft proposal to allow sharing of the 5.9 GHz band by U-NII devices.
As part of its Public Notice, the FCC has solicited comments on the two proposed sharing techniques developed by the IEEE DSRC Coexistence Tiger Team (i.e., “Detect and Avoid” and “Re-Channelization”), as well as on other potentially viable approaches to sharing in the band without causing harmful interference to V2V operations.
The FCC described the two proposed sharing approaches as follows: (1) Detect and avoid, under which unlicensed devices would monitor the existing DSRC channels, and if they detected any transmitted DSRC signal, they would avoid using the entire DSRC band. After waiting a certain amount of time the unlicensed device would again sense the DSRC spectrum to determine if any DSRC channels are in use or whether it could safely transmit; and (2) Re-Channelization, under which the DSRC spectrum would be split into two contiguous blocks: one for safety-related communications and one for non-safety-related communications, by moving the control channel and the two public safety channels to the top portion of the band. Additionally, the remaining four DSRC service channels would be reconfigured at the lower end of the band as two 20 megahertz channels rather than maintaining four 10 megahertz channels. The segments designated for safety-related communications would remain exclusive to DSRC, and the remaining spectrum would be shared between the DSRC service channels and unlicensed devices.
We seek comment on the costs and benefits of each sharing proposal, and whether and how we should consider each of these approaches relative to this proposed rule.
(b) Data Rate
In setting a data rate, one is balancing between two competing interests: (1) the speed at which one wants to transmit the information, and (2) how far the information can travel (and how reliably it can travel that distance). In other words, if we send more information in a smaller amount of time, the information cannot reliably travel as great of a distance.
In the context of our rulemaking, our proposal for data rate considers the following technical questions:
- How far do we need the message to travel?
- What is an acceptable PER (i.e., how reliably do packets need to make it to a receiving device in order to ensure that a safety application can function)?
- What bitrate do current systems and voluntary standards under development use? If a final rule used a different set of requirements, how significant would this change be?
In the sections that follow, we first discuss the competing considerations for our data rate proposal. Using the information that we have from our discussion on data rate, we then discuss our proposal for the channel.
(i) Proposed Requirement is 6 Mbps
The agency is proposing to require devices to transmit at 6 Mbps. We believe it is reasonable to expect that transmitting basic safety messages at the 6 Mbps rate can easily cover the necessary range assuming 300 m at a very low PER of 10%. The available research from both CAMP and BAH support this initial conclusion, as described later in this section. Further, while we are requesting comment on changing the bitrate, we note that the current systems and voluntary standards under development all will be able to support multiple bitrates within the ranges examined (i.e., device developers would not need to redesign the current hardware to support a new bitrate).
Finally, while the theoretical analysis by BAH suggests that increasing the bitrate would help to mitigate congestion mitigation, we are unsure given the lack of real-world testing whether altering the bitrate and channel bandwidth is necessary given that the agency is considering other channel Start Printed Page 3887congestion mitigation strategies. These strategies involve adjusting the number of basic safety messages that devices would transmit per second and the power/range of those transmission when channel congestion is detected by a device. More detail on these strategies is found in Section III.E.1.b)(b)(ii). The agency is continuing to refine congestion mitigation approaches including device density in real-world conditions, beyond those tested in the specific Safety Pilot testing and Safety Pilot Model Deployment.
We request comment on our potential approaches to conclusions and our questions above. To support the commenting process, we are also presenting alternative choices for bitrate in the section that follows and we seek comment on those alternatives.
(ii) Alternatives for Data Rate Requirements
The BAH research suggested alternate bitrate possibilities that would change based on the level of congestion on the channel. Their rationale behind this approach is that, when the channel is not busy, the transmitting device should use a lower bitrate that can more reliably send the message. However, when the channel congestion is detected, the device should use a higher bitrate to send the message quicker and vacate the channel as soon as possible. This is a logical strategy because when a vehicle is in a congested environment (e.g., a traffic jam 
); the vehicle does not need to transmit the message as far because the relevant cars are the ones that are fairly close by. In other words, in this scenario, it is important to transit the message fast (not far).
Based on this logic, BAH recommended in its research that devices transmit in the following manner:
- When the Channel Busy Ratio 
is below 50%, transmit the BSM at a data rate of 9 Mbps;
- when the channel busy ratio exceeds 50%, transmit the BSM at a data rate of 18 Mbps and continue to transmit the BSM at a data rate of 18 Mbps until the Channel Busy Ratio falls below 20%.
While we have proposed to use a standard 6 Mbps bit rate, we request comment on the recommendation from BAH and specifically would seek data regarding the following questions:
- Is it appropriate to change the bitrate based on channel busy ratio if the performance within the relevant range is relatively similar across the bitrates under consideration? Would it be more advantageous to use 18 Mbps at all times?
- For changing message bitrates, our understanding is that the transmitting device sends a basic safety message with a header (the first part of the message) always transmitted at 6 Mbps. Our understanding is that the header instructs the receiving device to switch to another bitrate for the remainder of the message. How does this process impact the speed at which devices in the V2V information environment can transmit and receive basic safety messages?
- Is there any information on how much time one would save between transmitting a basic safety message at 6 Mbps versus 18 Mbps (and other bitrates)? In other words, many more messages can be transmitted within a given timeframe if one were to change the bitrate?
- We note that 3 Mbps, 6 Mbps, and 12 Mbps are bitrates that device makers are required to support when they are building a device according to the IEEE 802.11 voluntary standard. The standard affords the option to support other bitrates but does not require it. Is there any information on how many devices support bitrates other than 3 Mbps, 6 Mbps, and 12 Mbps?
- What would the impact be on current systems and voluntary standards under development if the agency were to use a different bitrate (from 6 Mbps) in a final FMVSS?
- BAH suggests that all radios now support 6 and 9 Mbps transmission. (Section 4.3.1 of BAH Report). Is there any information on whether current DSRC radios can support 18 Mbps and dynamically switch between the two bitrates based on channel congestion ratio? What's the cost to implement this change?
(iii) Existing Research on the Impact of Different Potential Data Rates
There are currently two bodies of research available to the agency on the impact that different bitrates can have on the range and reliability of the transmission of the basic safety message, CAMP and work performed by BAH funded by the agency. In essence, the CAMP research showed that there is a small difference in PER between a 6 Mbps and 12 Mbps data rate at 300 m, the assumed minimum range for V2V communications. The BAH research shows that there was a difference in PER between 6 Mbps, 9 Mbps, 12 Mbps, and 18 Mbps. However, most of these differences occurred at a distance exceeding 500 m.
(a) Increasing Data Rate
CAMP conducted a test involving real devices in an outside environment. VSC-A Report Appendix I 
showed that, given a dedicated DSRC transmission channel, using a 12 Mbps data rate somewhat degraded the ability of the message to reach its destination when compared with a 6 Mbps data rate. In their research, they used a vehicle broadcasting basic safety messages and placed it in different locations around various radios that attempted to receive the vehicle's basic safety messages during the test. When the researchers placed the vehicle close to the radios, there seemed to be little degradation in whether the radios could receive the messages (regardless of bitrate). Using the 6 Mbps data rate, 58 receiving radios picked up the basic safety messages. Using 12 Mbps, 57 receiving radios were still able to pick up the basic safety messages. However, when they placed a vehicle at the “far edge” of the range of the receiving radios, 55 radios received basic safety messages at 6 Mbps versus only 45 at 12 Mbps. See Figure III-1 and Figure III-2, below.
Start Printed Page 3888
In addition, the VSC-A research explored the potential impact of using 12 Mbps as opposed to 6 Mbps within a 300 m test range. As evident in the figure below, when using 6 Mbps, nearly all the devices (up to the 300 m test range) received the messages with a very low PER. However, when switching to 12 Mbps, we observe a small increase in the number of devices that could not receive the messages with a low PER between the range of 100 and 300 m.
The research also examined the impact of different bit rates based on transmission power (i.e., if we transmit with more power, how would the 6 and 12 Mbps bit rates affect the ability of the receiving device to obtain the basic safety message? In the CAMP research, radios were able to receive packets at a somewhat lower transmission power when they were being transmitted at 6 Mbps as opposed to 12 Mbps (i.e., packets failed to reach their destination when the power was −90 dBm when they were transmitted at 12 Mbps versus −94 dBm when they were transmitted at 6 Mbps).
(b) Differing Bitrates
BAH also conducted research comparing the impact of data transmission rate to the reliability and range of the transmission. In their research, involving transmissions sent on a flat and open road at a test facility, 18 Mbps (they also tested 6 Mbps, 9 Mbps, and 12 Mbps) did not perform as well (i.e., a higher PER at a shorter distance) as the lower bitrates. However, their field test indicated that the ability of the transmission to successfully deliver the packet remained rather Start Printed Page 3889constant (regardless of the bitrate tested) up to 500 m.
In BAH's report, they surmise that the wide variation of PER at distances above 500 m for all bitrates is attributable to multipath fading.
They conclude that an 18 Mbps bitrate seems more susceptible to multipath fading than other, lower bitrates (i.e., the 18 Mbps bitrate might be more sensitive to environmental changes).
(c) Other Aspects of DSRC Transmission Performance
Thea agency recognizes there other BSM transmission performance parameters that will be necessary for real-world implementation. These parameters are found in the applicable application specifications for DSRC message content and performance parameters. The agency does not see a reason to establish requirements for these parameters based on currently available information. However, we request comment and any supporting information from the public on whether there may be advantages to establishing requirements in these areas to support the safety applications and/or ensure interoperability within the V2V information environment.
(1) Age of BSM Transmission
The age of the BSM transmission is monitored by the data element, DE_DSecond. The DSecond data element provides a time value when a BSM is populated with data there may be a lag between the time the data is collected and populated in the BSM—and when the BSM is actually sent. We are proposing that the device should not transmit a BSM if the data within the BSM is over 150 milliseconds old. In the test procedure section in this document, we are specifying a test device for receiving basic safety messages from the tested vehicle. Our rational is that the requirements and test methods requires the device to transmit a timely BSM.
- The system shall set the DE_DSecond with a value corresponding to milliseconds within a minute of the UTC time when the BSM Part I vehicle location data is determined by the positioning source. [MPR-BSMTX-DATAACC-008]
- DE_DSecond shall be accurate to within 1 ms of the corresponding UTC time. [MPR-BSMTX-DATAACC-009]
- DE_DSecond shall have a value less than 150 ms from the UTC time at which the BSM is transmitted (i.e., the age of the time used in DE_DSecond shall be less than 150 ms). [MPR-BSMTX-DATAACC-010]
Other measurements present in the BSM should be aligned to DE_DSecond insofar as possible in the implementation. Since other measurements present in the BSM do not have an absolute time stamp, it is not clear how this is done in practice. Nevertheless, practical implementations to date have used the most recent measurement updates known to the transmitter at the time when the BSM is composed.
In addition to the issue of transmitting the basic safety message, the V2V research to date also included potential requirements covering the reception of the basic safety message. The potential requirements in this area include the ability of the vehicle to:
- Receive a basic safety message given a particular test device's transmission power and distance from the vehicle;
- translate the 0's and 1's received over the wireless airwaves into the basic safety message (i.e., using the appropriate protocol suite to interpret and unpack the wireless signal into the basic safety message content); and
- authenticate the signature of the basic safety message to confirm that the information is from an authenticated source (i.e., to determine that the message is actually from a vehicle).
While the research (e.g., the V2V safety pilot) included many of these aspects of performance, we tentatively believe that it is unnecessary to separately evaluate the vehicle's ability to receive the basic safety message as a number of indirect methods determining if a vehicle received the information exist in the transmission requirements already, namely congestion detection and mitigation.
Although this may be counterintuitive, we believe that directly evaluating the reception of the basic safety message is best conducted Start Printed Page 3890under conditions where the vehicle is using the information from the basic safety message for a particular purpose. For example, when there is a safety application, the receiving and processing the basic safety message transmissions leads to a response from the vehicle (e.g., a warning). In these conditions, the vehicle's reception of the basic safety message is indirectly (and, we believe, sufficiently) tested by exposing the vehicles to basic safety messages with certain information (e.g., information about a vehicle on a collision course with the tested vehicle) and then measuring the vehicle's response (e.g., whether it issues a warning at the appropriate time).
As this proposal does not include requirements for applications, the agency would need to require vehicles to output a log or record of the basic safety messages that they received within a given amount of time in order to assess whether the vehicle is able to complete the three tasks mentioned above. However, we tentatively believe it's unnecessary at this time to include additional requirements to check a vehicle's ability to receive basic safety messages. By requiring the vehicle to mitigate congestion, we believe that the vehicle must incorporate the ability to receive the message.
Regardless of methods employed, congestion mitigation requires the vehicles to determine the local vehicle density inside a given radius as part of the determination of the maximum time between messages. To do this, the vehicle not only has to have the ability to understand the base channel busy ratio, but also decode the message enough to expose the various temporary IDs of the received BSMs to get an accurate vehicle count. To decode the message far enough to get the temporary IDs, the vehicle needs to be able to interpret the BSM and all of its sub-layers.
We also believe that automakers implementing safety applications would ensure that the vehicle would have the capability to receive the basic safety message (including receiving the transmission and processing the transmission to obtain the message) and authenticate the message. Because the performance of an automaker's safety application in a vehicle would rely on the vehicle's ability to reliably receive basic safety messages, we believe that automakers implementing safety applications would also have a strong incentive to implement an appropriate receive capability in their vehicles.
However, we request comment on our tentative conclusion. We seek comment on whether there is any reason that the agency should include direct requirements for receiving the basic safety message (independent of the vehicle's capability to utilize the information for a safety application, congestion control, Misbehavior detection, or other intended uses). Further, we request comment on what performance the agency should assess and how the agency should assess such performance (i.e., how does the agency test the reception of information when the vehicle is not expected to do anything in response to that information?). Finally, the agency seeks comment on whether there is a need to specify requirements for DSRC devices to have message reception filtering for interference from operation in the adjacent unlicensed spectrum. Please provide substantive data and clarifying reasons why or why not this is necessary along with potential filtering strategies that could be employed, if the commenter believes message reception filtering is necessary.
One potential way to establish direct requirements and measure performance of those requirements would be to require vehicles to:
- Store all basic safety messages received within a certain amount of time (e.g., 5 minutes during the test); and
- output the data through a specified interface or collection of interfaces (e.g., OBD-II).
To test this performance, we would use a test device to generate basic safety messages near the tested vehicle. Access the tested vehicle using the specified interface in the standard and download the basic safety messages received file. Verify that the basic safety messages received by the tested vehicle match the basic safety messages transmitted by the test device. We request comment on whether this is a viable method for establishing requirements for this aspect of performance.
(3) Message Packaging and Protocol Suites
Finally, another important part of ensuring interoperability of any network is for all the devices participating in the network to agree to the same communications method (i.e., speak the same language). For electronic devices communicating over a network, the method of taking information and packaging that information (i.e., in multiple steps, converting it into a string of 1's and 0's) so that it can be sent across a wireless (or wired) network is called a protocol stack. Each step in the protocol stack packages the information for the next step. The transmitting device and the receiving device need to agree upon one method of packaging information so that the transmitting device knows how to package the information into 1's and 0's and then the receiving devices knows what to do with the received 1's and 0's in order to extract the information transmitted.
DSRC communications within the 5.85 to 5.925 MHz band are governed by FCC 47 CFR parts 0, 1, 2 and 95 for onboard equipment and Part 90 for road side units. In reference to the OSI model, the physical and data link layers (layers 1and 2) are addressed primarily by IEEE 802.11p as well as P1609.4; network, transport, and session layers (3,4 and 5) are addressed primarily by P1609.3; security communications are addressed by P1609.2; and additional session and prioritization related protocols are addressed by P1609.12.
Further, a variety of communication performance standards specific to the V2V communications and BSM transmission/reception are defined in SAE J2945 while data element and data frame definitions and coding requirements are defined in SAE J2735.
Devices adhering to these standards know how to package the basic safety message for transmissionover the DSRC 5.9 GHz spectrum. They also know how to interpret and unpack transmissions over that spectrum in order to obtain the basic safety message. While our proposed rule does not include explicit requirements for vehicles transmitting basic safety messages to utilize the methods for packaging the basic safety message in IEEE 802.11 and 1609, our proposed performance test (in effect) would require vehicles to do so.
As further discussed in the test procedure section in this document, we are specifying a test device for receiving basic safety messages from the tested vehicle. Our proposed test device would utilize the method for unpacking the basic safety message that is specified in 802.11 and 1609. Thus, in essence, vehicles transmitting the basic safety message will need to package the message utilizing the same method in order to deliver the message to the test device in our test. If the vehicle is unable to transmit a message packaged in a way that can be unpacked by our test device (i.e., using the IEEE method), the vehicle would fail our proposed performance test.
In this manner, we believe we are specifying a protocol stack that would ensure that devices following the packaging method of the protocol stack would be able to transmit and receive basic safety messages on the DSRC 5.9 GHz spectrum. We request comment on our tentative conclusion. Does the Start Printed Page 3891agency need to specify any additional areas of performance in order to ensure interoperability of the devices? In other words, what aspects of the packaging of the data for transmitting cannot be tested by our proposed test method? How does that impact device interoperability and how would the agency test it?
(d) DSRC-Based Communication—Applicable Industry Standards
(1) Standards and DSRC V2V Technology
Vehicle to Vehicle technology incorporates many components to facilitate crash avoidance capabilities. The basis for Vehicle-to-Vehicle crash avoidance is the communication of safety information among vehicles. Figure III-4 identifies the various components that a DSRC-based system would include; the DSRC radio, GPS receiver, Memory, Safety Applications, Vehicle internal communications network, System Security, and the Driver-Vehicle interface.
To support the V2V wireless communications, a set of voluntary consensus standards will need to continue to be developed. These standards define such things as how devices are to communicate over an identified frequency; how to exchange information including instructions for sending and receiving messages; how to structure, format, and understand message content; and the data elements making up the message content.
We expect that V2V communication will be covered by a family of integrated standards from different organizations that deal with different aspects of wireless communications and message exchange. Such standards will facilitate V2V device developers and implementers successfully exchanging safety messages and security information (e.g. interoperability). The standards will help ensure interoperability meaning any device identified as a V2V device communicates and interprets the messages in the same way.
(2) Voluntary Consensus Standards
Voluntary consensus standard: The term “voluntary” distinguishes the standards development process from governmental or regulatory processes. All interested stakeholders participate, including producers, users, consumers, and representatives of government and academia. Voluntary standards are also made mandatory at times by being incorporated into law by governmental bodies.
A voluntary consensus standards body is defined by the following attributes:
- balance of interest;
- due process;
- an appeals process;
- consensus, which is defined as general agreement, but not necessarily unanimity, and includes a process for attempting to resolve objections by interested parties, as long as all comments have been fairly considered, each objector is advised of the disposition of his or her objection(s) and the reasons why, and the consensus body members are given an opportunity to change their votes after reviewing the comments.
Voluntary consensus standards follow a rigorous, industry inclusive development process where each standard is developed by an established Start Printed Page 3892committee that consists of volunteer representative from interested stakeholders. Examples of such organizations include the Institute of Electrical and Electronic Engineers (IEEE), ASTM International, SAE International (SAE), and the American National Standards Institute (ANSI). Each committee establishes membership protocols regarding voting criteria, structure and format guidelines, and how information is contributed. The committees draft the standards and, once drafted, the standards are presented to the organizations membership for review, comment, and balloting.
If the standard is balloted and accepted, the standard is published. If needed, there are processes for a standard to be revised or updated as technology evolves. We anticipate that such bodies will develop the standards that provide the information to develop and implement interoperable V2V communications, but again stress that our performance requirements may permit technologies other than DSRC to perform V2V communications in the future.
In relation to DSRC V2V Communications, to date two voluntary consensus standard organizations have developed separate, however, interrelated standards based on DSRC-enabled V2V communications. These organizations are the Institute of Electrical and Electronic Engineers (IEEE), and the Society of Automotive Engineers (SAE). IEEE has developed two standards, IEEE 802.11p and IEEE 1609.x. IEEE 802.11p establishes how compliant devices will transmit and receive messages using the 5.9 GHz frequency. IEEE 1609.x defines the protocols for radio channel operations, message exchange, and message security. SAE has also developed two standards, SAEJ2735 and SAEJ2945. SAEJ2735 specifies the BSM message set, its data frames, and data elements. SAEJ2945 establishes minimum performance requirements for the BSM data elements in various messages.
The set of standards for DSRC detail the procedures, protocols, and message content to support the broadcast (special communication capability of DSRC) and receipt of the Basic Safety Message and the linked communications needed to transfer security materials to establish a more secure V2V communications environment.
(3) Computer and Wireless Communication Reference Model
To facilitate the communication needed from devices (hardware) to the applications (software) the International Organization for Standards (ISO) established the Open System Interconnect reference model (OSI). The OSI reference model consists of seven layers that define the different stages data must go through to travel from one device to another over a network.
Each layer has unique responsibilities including passing information to the layers above and below it.
The combination of layers represents protocol stacks. This structure and nomenclature of the OSI reference model is used in the V2V related standards. The Standards cover how data is communicated and interpreted from one V2V device to another device and processed to be used by crash avoidance applications; analogous to how your wireless router transfers data via the internet to an application on your computer such as a web browser.
The layers represent levels of interfaces to enable the bits that represent data to be properly transported and interpreted. The layers are illustrated in Figure III-5. The first layer starts at the bit/hardware device level and indicates how the steam of raw information is sent to the next layer. In relation to V2V this would be the DSRC radio level. In addition to the raw information, layer 2 organizes data packets into network frames that are transported across the V2V wireless network. These first two levels are covered by IEEE 802.11p. The next 3 layers are covered by IEEE 1609.x. Layers 3, 4, and 5 handle the addressing and routing of messages, management of the packetization of data and delivery of packets, and the coordination of message transmissions and authorization (security). Layer 6, session layer, and layer 7, application layer, are covered by SAE J2735 and SAE J2945 and provide for the conversion of incoming data for use by the application and interface protocols with the applications.
These layers and associated standards represent the DSRC protocol stack that developers use to design and produce interoperable devices.
Start Printed Page 3893
(4) DSRC-Based V2V Device Communication Standards
As indicated previously, SAE and IEEE have developed and established standards for DSRC. The DSRC protocol stack and related standards are illustrated in Figure III-6.
Working from the bottom of Figure III-6 and starting with the physical layer, the IEEE 802.11-2012—IEEE Standard for Information technology-Telecommunication and information exchange systems-Local and metropolitan area networks-Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications was published 29 March 2012. The standard covers operations of Wi-Fi devices. A specific section of the standard, 802.11p, covers DSRC communication for V2V and V2I devices that use the 5.9 GHz frequency. The standard describes information exchange between system local and metropolitan networks at the device radio level.
Start Printed Page 3894
From the device (hardware) level of 802.11, the IEEE 1609.x family of standard establishes the protocols for Wireless Access in Vehicular Environments (WAVE). These standards support the network, transport, and session OSI layers. The 1609 standards that are relevant to DSRC include the following:
- 1609.0—Guide for Wireless Access in Vehicular Environments (WAVE) Architecture—This section of the standard describes the full set of 1609 standards and their relationships to each other and other relevant standards such as 802.11. The guide was published 11 December 2013.
- 1609.2—Security Services for Application and Management Messages—Describes the secure message formats and processing for use by WAVE devices, including methods to secure WAVE management messages and methods to secure application messages. It also describes administrative functions necessary to support the core security functions. The V2V security design is based on this standard and incorporates an expanded application of Public-Key infrastructure to secure V2V communications and appropriately protect privacy. This standard is associated with Layer 5, session layer, and Layer 6, presentation layer. This standard was published 26 April 2013.
- 1609.3—Networking Services—In relation to Layers 3 and 4, network and transport, this standard describes the Internet Protocol (IP), User Datagram Protocol (UDP), and the Transmission Protocol (TCP) elements of the internet model and management and data services for WAVE devices. This standard was published 13 July 2012.
- 1609.4—Multi-Channel Operations—This standard crosses layers 2 through 5 to support multi-channel operations of the DSRC radio. Wireless radio operations that include the use of other channels need to provide instructions concerning the operation of the control channel (CCH), the service channel (SCH), interval times, priority access, channel switching, and routing. The current design for a V2V DSRC device uses two radios. One radio is tuned to channel 172 for transmission and reception of the safety-critical communication of the BSM. The second radio uses multi-channel operations to set the CCH and SCH, and use the other channels to support other messages transmission such as the messages associated with security materials. This standard was published 7 February 2011, however, a draft corrigendum that corrects errors is pending publication.
- 1609.12—Identifier Allocations—For the WAVE system this standard describes the use of identifiers and the values that have been associated with the identifiers for use by the WAVE system. This standard was published 21 September 2012.
- Layers 6, Presentation, and Layers 7, Application, are supported by the two SAE standards that define the elements and the minimum performance requirements for the BSM data elements.
SAE J2735—DSRC Message Set Dictionary specifies a message set, and its data frames and data elements specifically for use by application intended to utilize the 5.9 GHz frequency. For crash avoidance safety, the standard identifies the Basic Safety Message (BSM). The standard includes an extensive list of BSM data elements divided into two parts. Part one includes elements that are transmitted with every message. Part two includes elements that are included in the transmission when there is a change of status. The BSM is exclusive to the support of crash avoidance safety applications. Section III.E identifies the BSM elements that are identified as minimum performance requirements for V2V devices.
SAE J2945—DSRC Minimum Performance Requirements—This standard resulted from research indicating a need for a separate standard that would describe the specific requirements for the data elements that would be used in the BSM. The standard will also cover other DSRC messages; however, the first part of the standard will specify the performance requirements for the BSM data elements. The draft of the first part of the standard is being developed using results of V2V research. The standard for BSM performance requirements is scheduled to be completed and balloted late 2015.
The standards explained above represent voluntary consensus standards that have been developed by standards development organization. These standards are not regulatory. These standards, however, do provide a basis of investigation as to what is needed in relation to identifying the minimum performance requirements that if met ensure the proper and safe functionality of V2V DSRC device that will result in the avoidance of crashes.Start Printed Page 3895
(5) Relevance to DSRC-Based Communications
The SAE and IEEE standards supporting DSRC discussed are not performance requirements per se. Performance requirements and standards are interrelated and indicate, at different levels, how a system or device must function. Performance requirements are developed to indicate how a device or system needs to perform. In terms of V2V, performance requirements are associated with an installed device and are viewed from the top of the design and development process. Performance requirements may incorporate various standards that are identified in Section III.D, however, most of the standards are related to sub-systems and components that support the development of design specifications. The higher level performance requirements indirectly verify lower level standards were used by verifying the design performs at the integrated system level.
Figure III-7 illustrates our understanding of the hierarchical relationship associated with performance requirements and how standards are used at different component design specification levels. The bulk of the V2V related standards support primarily support product development specifications at the Controller Spec level and the Component Technical Spec level. The specifications are verified at each level by different component test and sub-system tests. The Auto OEMs conduct tests at the system level to verify design and system operations. After installation, OEMs conduct vehicle integration tests to verify installation and system operation in relation to design specification and regulation identified performance requirements. Once the integration is verified, the Auto OEMs verify compliance with the performance requirements. This hierarchy demonstrates how top level performance requirements supported by standards provide the information to successfully design and implement V2V components that will be interoperable and meet identified system level performance requirements.
The voluntary consensus standards provide information that support both performance requirements and design specifications, and are the bridge for connecting the requirements to the specifications. In relation to the NPRM, the work performed by NHTSA in relation to performance requirements is to identify, and define performance requirements and verification tests that will indicate that V2V device have been designed and implemented such that these devices will operate to provide the DSRC communications and security that will support crash avoidance applications.
(6) Summary of DSRC-Based BSM Transmission RequirementsStart Printed Page 3896
Table III-1—Summary of BSM Transmission Requirements
|Requirement||Proposal||Basis||Relationship to standards||Reason|
|Range (longitudinal & lateral)||Minimum 300m; 360 degrees around vehicle||CAMP—application tested in SPMD also calculation of range needed for DNPW||SAE J2945/1||The setting is based on the need to provide accurate and timely safety alerts. The setting was obtained by extensively testing commercially available equipment and automotive sensors in a wide variety of driving environments.|
|Range (Elevation)||At elevation angle of +10 degrees and −6 degrees||CAMP and BAH research and testing capabilities||SAE J2945/1||Same as above.|
|Reliability||Packet Error Rate <10%||CAMP and BAH||SAE J2945/1||Same as above.|
|BSM Radio Channel||All BSM transmissions and receptions on 172 (safety-critical communications)||FCC rules||SAE J2945/1||Same as above.|
|Data Rate||6 Mbps||CAMP and BAH research—CAMP research shows PER degradation using 12 Mbps. BAH research indicates problems after 500m, also BAH test done under “open field” conditions||SAE J2945/1 (one of the bitrates included in 802.11)||Same as above—Also Current developers support a 6 Mbps data rate. More data and testing is needed to change the data rate and determine if a changing rate can be used and support crash avoidance.|
|Transmission Frequency||10 times per second under non-congested conditions||CAMP—trade-off between long inter-packet delays experienced by V2V safety applications and heavy wireless channel utilization||SAE J2945/1||Accepted among experts to support V2V crash avoidance.|
|Staggering Transmission Time||Random transmission of BSMs every 100 +/−ms between 0 and 5 ms||Mitigate channel congestion if all devices transmitted at same time—CAMP and BAH research||SAE J2945/1||Due to accuracy of devices need to mimic the stagger experienced during SPMD to avoid message collisions to facilitate efficient channel usage.|
(e) Alternative (Non-DSRC) Technologies
This section is intended to recognize and support the continual progression of communication technology. It proposes alternative interoperable technologies performance requirements grounded in today's DSRC technology, which would enable the deployment of potential future V2V communications technologies that meet or exceed the proposed performance requirements, including interoperability with all other V2V communications technologies transmitting BSMs.
This section provides performance-based requirements that would support transmitting the basic safety message via alternative interoperable technologies. The proposed requirements are limited to the transmission of the BSM only. Potential security and privacy requirements and alternatives are discussed in those respective sections of this proposal.
Alternative technologies would need to meet the same message transmission requirements as DSRC-based devices, minus any DSRC-specific requirements such as channel or data rate specifications.
(1) Transmission Range and Reliability
Alternative technologies would need to support the same message transmission range and reliability requirements as DSRC-based devices, minus any specific references to DSRC.
Alternative technologies would need to support the same message transmission range requirements as DSRC-based devices, minus any specific references to DSRC.
(ii) Longitudinal/Lateral Range
Alternative technologies would need to support the same message transmission longitudinal and lateral range requirements as DSRC-based devices, minus any specific references to DSRC.
(iii) Elevation Transmission Performance
Alternative technologies would need to support the same message transmission elevation performance requirements as DSRC-based devices.
(2) Testing the Elevation Transmission Range
Alternative technologies would need to support he same message transmission elevation test requirements as DSRC-based devices.
(a) Test Device
Alternative technologies would need to support the same message transmission elevation transmission performance test device requirements as DSRC-based devices, minus any reference to DSRC.
(b) Location of the Test Device
Alternative technologies would need to support the same message transmission elevation test device location requirements as DSRC-based devices.
Alternative technologies would need to support the same message transmission reliability requirements as DSRC-based devices, minus any reference to DSRC.
(4) Aspects of Transmission Range Performance Indirectly Tested
Alternative technologies would need to support the same message transmission range performance indirect tests as DSRC-based devices.
(a) Transmit Power
Alternative technologies would need to identify the same transmit power as DSRC-based devices, where applicable for a specific communication medium.
(5) Channel and Data Rate
A final rule will need to indicate the range at which the vehicle needs to transmit the basic safety message and Start Printed Page 3897the receive sensitivity for alternative technologies.
(6) Transmission Timing
Alternative technologies would need to meet the same transmission timing requirements as the DSRC-based proposal minus any DSRC-specific requirements, such as channel and data rate. In keeping with the more general nature of the standards for alternative technologies, specifying aspects such as channel congestion or the need for staggering or synchronizing message transmission is assumed not to be needed and assumed to be handled by any protocol or communication medium used for V2V communication.
(a) Default Transmission Frequency
Alternative technologies would need to support the same message transmission frequency as DSRC-based devices, 10 times per second (10 Hz).
(b) Staggering Transmission Time
Alternative technologies would need to address the same issues for staggering transmission timing as DSRC-based devices, minus any direct reference to DSRC.
(7) Other Aspects of Alternative Interoperable Technologies
Alternative technologies would need to address the same issues for staggering transmission timing as DSRC-based devices, minus any direct reference to DSRC.
(a) Age of BSM Transmission
Alternative technologies would need to support the same message age monitoring requirements as DSRC-based devices.
Alternative technologies would need to support the same message reception requirements as DSRC-based devices, minus any references to message congestion mitigation, misbehavior detection, and DSRC-specific messaging content.
Additionally, NHTSA does not seek comment on the need to specify requirements for reception interference from operation in the adjacent unlicensed spectrum given this would be spectrum dependent.
V2V devices using alternative technologies would need to be capable of transmitting and receiving an established message from other V2V devices, regardless of the underlying technology (i.e. the BSM that has specified content of information, but also the measuring unit for each information element and the level of precision needed) Interoperability with DSRC-based devices would, in particular, be necessary. We seek comment on what test procedures or other safeguards would be required to ensure interoperability.
2. Proposed V2V Basic Safety Message (BSM) Content
At the core of this proposal is the basic safety information that we believe vehicles need to send in order to support potential safety applications. In order to realize the safety benefits discussed above, safety application designers need to know what consistent set of information will be available, what units will be used to express that information, and the level of accuracy that each information element will have. This uniform expression of the basic safety information is important because a safety application needs to rely on the information in the messages and assume that the information is accurate to within a given tolerance. The requirements proposed in this section are consistent across any potential communication technology employed in V2V communications.
To date, the automotive industry (through SAE) has been developing voluntary consensus standards 
to help standardize these details of the basic safety message. The general approach of our proposal is to incorporate the data elements from the current draft SAE standards in order to facilitate interoperability between devices that would comply with the proposed FMVSS and any potential future developments of the SAE standards. Further, we are considering each data element and associated tolerance requirements for each of those elements in the context of addressing the safety need of avoiding crashes. Each of the data elements we are proposing to require provide values that collectively contribute to the calculations of possible vehicle interactions and evaluating the imminent crash potential of these interactions. Moreover, the required and optional data elements would create a data-rich environment that can be used to not only identify imminent crash situations, but also ensure the drivers can be given advanced warning of these situations so these drivers can take appropriate evasive action to avoid crashes. Based on our analysis, we are proposing requirements for some, but not all, of the data elements in the SAE standards. However, in order to preserve interoperability with vehicles that may choose to send additional data elements, we are generally proposing to permit vehicles to transmit a data value that either conforms to the SAE standard or is the SAE-specified “data unavailable” value.
Finally, we are also proposing to exclude certain data elements from being transmitted as a part of the BSM. We are proposing this limitation in order to balance the privacy concerns of consumers with the need to prove safety information to surrounding vehicles.
While we request public input on any of the issues discussed in this section, we especially would like input on whether we have appropriately selected (1) the data elements to include/make optional/exclude, and (2) the tolerance levels for each data element.
(1) Required Data Elements and Their Performance Metrics
In the work completed by SAE thus far,
the automotive industry separated the information transmitted in the basic safety message into two parts (Part I and Part II). As we explained in the Readiness Report, Part I information is core information intended to be sent in every basic safety message. Part II is additional information intended to be sent as needed. In this section, we cover data elements from both Part I and II that our proposed requirements would include the performance metrics for each.
(a) Message Packaging
Before reaching the actual elements that support safety applications, the basic safety message needs certain preliminary elements that help a receiving device to know what it is receiving. The three elements that fall into this category are the Message ID, the Message Count, and the Temporary ID. We tentatively believe that all three of these elements are necessary as they allow the receiving device to interpret the digital code it is receiving and the safety information inside the message. The three elements provide the information needed for the device to properly process a sequence of messages that delivers vehicle position and motion data needed to interpret possible crash situations.
(i) Message ID
The first element is the Message ID. This data element explains to the receiving device that the message it is receiving is a basic safety message. SAE Standard J2735 specifies that this data Start Printed Page 3898element is one byte from 0 to 15.
Each number represents a different type of message that could be sent over DSRC. We are proposing to V2V devices sending basic safety messages transmit a “2” as the Message ID. Based on SAE Standard J2735, “2” indicates to the receiving device that the content of the message is a basic safety message and that it should interpret the data accordingly.
(ii) Message Count
The second element here is the Message Count. In SAE Standard J2735, the Message Count assigns each basic safety message a number in sequence between 0 and 127.
Once the device's Message Count reaches 127, the idea is that the next message it sends would have a Message Count of 0. This count helps the receiving device know that it has all the messages sent by the sending device and which order to put them in. For example, if I receive messages 11, 13, 14, and 15 from a particular device, I will know that they are in order but I will know that I am missing message 12 from that particular device. The agency's proposal would require that vehicles follow the requirements of the SAE standard and assign the Message Count for each message in sequence between 0 and 127. We believe that this Message Count data element will enable safety applications that receive these messages to appropriately put the messages in order and be aware of any missing messages that could affect the overall information being processed by the safety application software.
(iii) Temporary ID
Finally, the Temporary ID is a four-byte string array randomly-generated number that allows a receiving device to associate messages sent from the same device together. While the identity of the sending device is not important for a safety application to take appropriate actions during a crash-imminent situation, it is important for a safety application to know that it is receiving, for example, ten messages from one device rather than five messages from two devices. In other words, the Temporary ID balances the safety need of associating basic safety messages with each other (to know if they originate from the same device), with the privacy need to avoid tracking/identifying particular users.
In order to accomplish these goals, we propose that vehicles transmit a Temporary ID as specified in SAE Standard J2735. Based on the SAE standard, the Temporary ID is a randomly-generated four-byte sequence of numbers selected from 4,294,967,296 combinations.
There are many acceptable techniques to generate a random sequence of numbers for the Temporary ID and it does not need to be specified; however, the performance can be tested. Further, the randomly-generated ID is changed to another randomly-generated ID every five minutes, when the BSM security certificate changes. Having the ID and the certificate change at the same time reduces some of the risk that a relationship between the ID and certificate could be developed to track a device. Given the current research available, changing security certificates at five minute intervals helps to reducing the risk of tracking which helps to protect consumer privacy. Additional research is being conducted to further investigate the ability or limitation of the five minute time period to mitigate the potential for tracking and protect privacy.
In addition to the data elements necessary for packaging the basic safety message, the Time data element is critical because all of the information within the basic safety message (e.g., the vehicle location, speed, etc.) being used to enable safety applications needs to be expressed in the context of time. Based on time, the safety application is able to determine when a surrounding vehicle was in a given location and assess where that vehicle may go. Thus, it is important for the Time element not only to be expressed precisely but also using a uniform system among the devices participating in the V2V information environment.
In order to accomplish this purpose, we propose a standard system for vehicles to express time in the basic safety message and a requirement for the accuracy of the time. DSRC-based devices would be required to adhere to SAE Standard J2735 
and devices would be required to use the UTC 
standard for time. The UTC standard is widely accepted. It is also the predominant standard for time for internet devices and GPS devices—two groups of technologies that are closely related with V2V devices. Thus, we believe that the UTC standard is an appropriate standard method for expressing time. Further, we tentatively believe that the UTC method for expressing time contains an appropriate level of accuracy—including a method for accounting for leap seconds.
In addition to using the UTC standard, we propose to require vehicles to transmit the Time data element to an accuracy of 1 ms (i.e., within +/− 1 ms of the actual time). Given the proposed requirements for transmitting the messages, we believe that requiring the time information accompanying each basic safety message to be within 1 ms of the actual time is appropriate. As further discussed below, we are proposing that vehicles transmit a basic safety message 10 times a second (unless specific conditions require otherwise). In the discussions that follow, we are also proposing that vehicles broadcast the messages (in order to help avoid vehicles broadcasting at the same time) at a staggered time (a random value of +/− 5 ms from every tenth of a second). Given these requirements where the broadcast time of a message can vary by as little as 1 ms, we tentatively believe it is appropriate to require that the Time data element be accurate to within 1 ms.
This set of data elements form the foundation of the basic safety message because it is the information that enables all the safety applications being developed to utilize the V2V information environment. The location information of the surrounding vehicles enables a safety application on a vehicle to know whether a crash imminent situation exists or is likely to exist in the near future. For example, an application such as IMA would use location information of surrounding vehicles to determine whether another vehicle is heading into the intersection and likely to cause a crash.
For location, longitudinal and lateral (2D) data, and also vertical (elevation) data would be required. We acknowledge that longitudinal and lateral data are more commonly used in V2V safety applications (since vehicle travel is mostly two dimensional). However, elevation also is important in a number of respects. For example, safety applications such as FCW or LDW can potentially take into account elevation information for merging traffic in on-ramp situations. Further, applications currently under development such as IMA are already taking elevation into account to Start Printed Page 3899differentiate cross traffic that is on an overpass from situations where the cross traffic is on the same plane of travel (i.e., could potentially lead to a crash).
(i) Vehicle Position Reference Point
In order for vehicles to accurately communicate their position in a basic safety message to each other, all vehicles need to agree to a single point on the vehicle as the reference point. Without such a point, the reported position for each vehicle could vary by meters depending on the size of the vehicle and the point on the vehicle that the message is reporting. Thus, we are providing a proposed definition for a vehicle reference point—based upon which the agency would evaluate the compliance of the vehicle location information in the basic safety message.
Our proposal is to define the vehicle reference point as the theoretical point projected on the surface of the roadway that is in the center of a rectangle oriented about the vehicle's axis of symmetry front-to-back. This rectangle encompasses the farthest forward and rearward points and side-to-side points on the vehicle, including original equipment such as outside side view mirrors on the surface of the World Geodetic System-84 (WGS-84) ellipsoid (see Figure III-8). The position reference is obtained from measurements taken when the vehicle is situated on level ground/roadway, i.e. where there is no difference in grade in any direction and all tires contact the ground/roadway evenly. This position provides the BSM position reference of the center of the vehicle along all axes that can be used to determine the outer perimeter of the vehicle in relation to vehicle movement. The position reference is also used to configure the GPS antenna if the antenna cannot be placed at the vehicle's center point.
(ii) Longitude and Latitude
Longitude and latitude position would require that vehicles report a position that is within 1.5 m of their actual position at a Horizontal Dilution of Precision (HDOP) 
less than or equal to 1.5 within the one sigma absolute error. For the 2D location we tentatively believe that 1.5 m is appropriate because it is half of the width of a lane of traffic. Therefore, if vehicles provide position data within this level of accuracy, safety applications should be able to determine whether another vehicle is within its lane of travel. Further, the requirement to stay within the 1.5 m of tolerance at an HDOP smaller than five, within the one sigma absolute error, accounts for some of the variation in position that may occur with GPS due to failure to receive signals from a sufficient number of satellite signals.
If the HDOP is larger than five, there is a high probability that the accuracy of the position of the vehicle will not be accurate enough to support the 1.5m of position. As we anticipate that most vehicles, if not all vehicles, will use GPS to ascertain their location, we currently believe that it is appropriate to account for this potential error in our proposed location requirement in the Start Printed Page 3900basic safety message. Our engineering judgment is that an HDOP smaller than five within the one sigma absolute error appropriately accommodates the potential variation in GPS and provides a monitoring function that can be measured to determine if the GPS within the DSRC device can calculate a position at an accuracy level that supports the 1.5m relative position accuracy needed for DSRC crash avoidance.
Due to the different situations in which elevation is relevant, vehicles would be required to report elevation in the basic safety message with an accuracy of three meters—rather than 1.5.
In terms of elevation, our tentative belief is that the information does not need to be as exact as the longitude and latitude location. Our proposal currently uses three meters (approximately 10 feet) because it provides sufficient distance to distinguish between a vehicle crossing an overpass versus those that are on the same level as the vehicle with a safety application. Further, our current judgment is that reporting the elevation with greater specificity would be counter-productive for certain safety applications. The elevation should be relative to each vehicle being interacted with within 300M. A tolerance of 3m (10ft) provides for low bridges but takes into account changes in grade that change as vehicles close on each other. Therefore, in specifying the elevation tolerance, we tentatively believe that we are balancing the competing safety interests.
In addition to knowing the vehicle's position, a safety application should also consider the characteristics of that vehicle's movement. Rather than extrapolating these characteristics (with less accuracy) based on the position information, safety applications currently under development already consider movement information about the surrounding vehicles in determining whether a crash-imminent situation exists. For the basic safety message, we tentatively believe that speed, heading, acceleration, and yaw are the most relevant pieces of information about a vehicle's moment.
We are proposing characteristics for message content related to speed, heading, acceleration, and yaw rates. Essentially, we propose to measure the rate at which the sending device's location is changing and also any changes to that rate at which a device's location is changing. Because a safety application is generally concerned with the potential future locations of the device (rather than just its present location), it is likely that safety applications will utilize this type of information.
For example, through combining the speed and heading information with a devices's current location, a safety application can calculate whether a surrounding vehicle can collide with the safety application's vehicle. Further, having information about the vehicle's acceleration will make that prediction more accurate because it tells a safety application whether the vehicle is speeding up or slowing down. Yaw rate also affects the predicted location of the vehicle because it measures the rate at which the vehicle's direction is changing (i.e., the rate at which the vehicle's face is pivoting towards the left or the right). The tendency of the vehicle to change direction during its travel (like acceleration) also affects the ability of a safety application to predict its location.
We are proposing that vehicles report their speed in the basic safety message accurate to within 0.28 m/s (1 kph). We tentatively believe that this is the appropriate accuracy for the Speed data element based on the agency's experience in the Safety Pilot Model Deployment, where systems reporting speed information accurate to within 1 kph effectively supported the tested safety applications. We are not aware of any instances during the Model Deployment where an application warned at the incorrect time (i.e., false positive) or failed to warn (i.e., false negative) due to any inaccuracies in the Speed data element. As the available information indicate that the 1 kph tolerance requirement is technically feasible and that it supports the safety applications, we tentatively believe that it would also be an appropriate requirement for a final regulation.
We note that the basic safety message requirements in SAE J2735 state that the speed is reported in increments of 0.02 mph. We currently believe that it is appropriate, in addition to the tolerance of 1 kph established above, to also specify the incremental units to be used by the vehicle in reporting its speed. While it may not be technically feasible to report the speed information with a tolerance of only 0.02 mph, we believe that (by requiring the vehicle to report speed in incremental units of 0.02 mph) we can capture better information about the vehicle's change in speed. Further, by establishing these consistent requirements, vehicles will be able to better rely on the information they are receiving from the surrounding vehicles. As with our rationale for the tolerance of 1 kph in the preceding paragraph, our rationale for proposing that vehicles report the speed information in increments of 0.02 mph is based on our experience in the Safety Pilot testing. In the Safety Pilot, vehicles reported information using these specifications and it provided effective information for the safety applications tested in that program.
We request comment on these tentative conclusions. Is there any data that suggest that the agency should adopt a different tolerance level for the speed information reported in the basic safety message? Is there similar data for the incremental values for reporting speed that we propose to require?
Heading in relation to BSM and crash avoidance is defined as the “actual” heading in relation to the vehicle position reference point (explained above) that indicates the course of the vehicle's motion regardless of the vehicle's orientation to that motion, i.e. where the front of the vehicle is pointing. Knowing the “actual” vehicle heading is needed in order to accurately identify conflict and imminent crash situations.
For Heading, the agency would require different levels of accuracy based on the vehicle's speed. We tentatively believe that this is appropriate because we anticipate that most vehicles will be determining vehicle heading using GPS information. We recognize that the accuracy of GPS-determined heading varies based on speed. We also tentatively believe that heading information might not be as critical at lower speeds. Therefore, we believe it is appropriate to provide more flexibility at lower vehicle speeds. Thus the requirements for heading need to support V2V crash avoidance would read as follows:
- When the vehicle speed is greater than 12.5 m/s (~28 mph), it is required to report vehicle heading accurately to within 2 degrees; and
- when the vehicle speed is less than or equal to 12.5 m/s, it is required to report the vehicle heading accurately to within 3 degrees.
We tentatively believe that 2 degree accuracy for speeds above 12.5 m/s is appropriate because research indicates that at approximately 12.5 m/s (28 mph) Start Printed Page 3901sensors and vehicle dynamics can accurately report heading within 2 degrees. At speeds less than 12.5 m/s the research indicates that the sensors and vehicle dynamics cannot reliably report vehicle heading within 2 degrees, but can reliably and accurately report within 3 degrees of accuracy. Given that at lower speeds vehicles travel less distance and driver-initiated evasive actions can be more effective at the lower speeds, our tentative conclusion is also that a three degree accuracy is appropriate for speeds below 12.5 m/s.
In addition to providing different requirements for accuracy at different speeds, we tentatively believe it is appropriate to require that vehicles “latch” 
the GPS information at very low vehicle speeds. In other words, when the vehicle speed is very low (and a GPS cannot accurately determine the heading) we are proposing to require that the basic safety message transmit the last heading information prior to the vehicle dropping below a given speed.
In this case, the agency is proposing to require the system to latch the heading when the vehicle drops below 1.11 m/s (~2.5 mph). We tentatively believe that 1.11 m/s is an appropriately low threshold where, at speeds lower than 1.11 m/s, the heading information is not as crucial because the vehicle is not changing its location at a significant pace. For reference, a NHTSA 2006 study measured the idling speed of the vehicles (i.e., speed when vehicle is in gear and no brake or throttle is being applied). Of the vehicles that NHTSA measured in that study, the idling speed ranged from 4.0 mph to 7.0 mph.
Further, the agency is proposing to require vehicles to unlatch their heading information (and transmit a heading value that is within 3 degrees of its actual heading) when its speed exceeds 1.39 m/s 
(~3.1 mph). As a vehicle's speed increases towards its idling speed, we propose requiring that the vehicle calculate its heading and report that information in the basic safety message.
For Acceleration, the agency would require vehicles to report horizontal (longitudinal and lateral) acceleration with an accuracy of 0.3 m/s2 and vertical acceleration to 1 m/s2. The requirement is based on the need to provide accurate and timely safety alerts for the crash scenarios and corresponding potential safety applications identified in Table III-2. The requirement was obtained by extensively testing commercially-available equipment and automotive sensors in a wide variety of driving environments, and the numbers were proven to be reasonable based on the equipment and sensor capabilities, while also supporting safety alerts from the appropriate safety application at timings that would enable a driver reaction sufficient to avoid the corresponding crash scenario.
(iv) Yaw Rate
Finally, for Yaw Rate, the agency would require vehicles to report this information to an accuracy of 0.5 degrees per second. The requirement is based on the need to provide accurate and timely safety alerts for the crash scenarios and corresponding potential safety applications identified in Table III-2. The requirement was obtained by extensively testing commercially-available equipment and automotive sensors in a wide variety of driving environments, and the numbers were proven to be reasonable based on the equipment and sensor capabilities, while also supporting safety alerts from the appropriate safety application at timings that would enable a driver reaction sufficient to avoid the corresponding crash scenario.
Table III-2 Potential Safety Applications Reliant on Acceleration and Yaw Rate Information
| ||EEBL||FCW||BSW/ LCW||IMA||LTA||CLW|
|Lead Vehicle Stopped||✓|
|Control Loss without Prior Vehicle Action||✓|
|Vehicle(s) Turning at Non-Signalized Junctions||✓||✓|
|Straight Crossing Paths at Non-Signalized Junctions||✓|
|Lead Vehicle Decelerating||✓||✓|
|Vehicle(s) Changing Lanes—Same Direction||✓|
|Left Turn Across Path—Opposite Direction||✓|
|Lead Vehicle Stopped||✓|
|Control Loss without Prior Vehicle Action||✓|
|Vehicle(s) Turning at Non-Signalized Junctions||✓||✓|
|Straight Crossing Paths at Non-Signalized Junctions||✓|
|Lead Vehicle Decelerating||✓||✓|
|Vehicle(s) Changing Lanes—Same Direction||✓|
|Left Turn Across Path—Opposite Direction||✓|
(e) Additional Event Based Information
In addition to the information discussed thus far, the agency would require additional data conveying the transmitting vehicle's path history, future predicted path, and exterior lights status to also be transmitted as part of the Vehicle Safety Extension (Part II) for V2V safety communications. The data element, Event Flags, shall also be transmitted as long as a defined event is active. For exterior lights status and other, similar data where access to the vehicle databus may be necessary, the agency assumes all integrated devices will have access this information. Aftermarket, standalone devices may or Start Printed Page 3902may not be able to access this information.
(i) Path History
Path history, which provides an adaptable, concise representation of a vehicle's recent movement over some period of time and/or distance, consists of a sequence of positions selected to represent the vehicle's position within an allowable error. The path history can be used not only by safety applications on the transmitting vehicle, but also by other vehicles, which can use this information to predict the roadway geometry and for target vehicle classification with reference to the roadway.
For the Path History (PH) data frame, the agency would require that the vehicle use a history of its past GNSS locations (as dictated by GNSS data elements including UTC time, latitude, longitude, heading, elevation, etc.), sampled at a periodic time interval (typically, 100 ms) and interpolated in-between by circular arcs, to represent the vehicle's recent movement over a limited period of time or distance.
Path history points should be incorporated into the Path History data frame such that the perpendicular distance between any point on the vehicle path and the line connecting two consecutive PH points shall be less than 1 m. In this way, the points present in the path history will concisely represent the actual path history of the vehicle based on the allowable position error tolerance (1 m) between the actual vehicle path and its concise representation. Objective testing of applications as part of the VSC-A Project showed that a PH error tolerance of 1 m satisfies the needed accuracy for target vehicle classification and meets the performance requirements of the safety applications that were developed and demonstrated.
For the subset of the available vehicle path position data elements, a minimum number of PH points necessary to satisfy the required error tolerance between the vehicle path and its PH representation (1 m) should be selected to populate the Path History data frame. Populating the Path History data frame with the minimum number of PH points possible offers significant savings in over-the-air wireless bandwidth when transmitting the PH information to other vehicles wirelessly. Additionally, vehicles should report the minimum number of PH points so that the represented PH distance (i.e., the distance between the first and last PH point) is at least 300 m and no more than 310 m, unless initially there is less than 300 m of PH. We believe that this range is appropriate because the operational range for DSRC is approximately 300 m, and the maximum required signal range for safety applications currently under development is 300 m. However, if the number of PH points needed to meet both the error and distance requirements stated above exceeds the maximum allowable number of points (23), the Path History data frame shall be populated with only the 23 most recent points from the computed set of points. Effectively, the distance requirement shall be relaxed in order to reduce over-the-air bandwidth.
Lastly, to ensure the most accurate representation of the vehicle's current trajectory, the Path History data frame shall be populated with time-ordered PH points, with the first PH point being the closest in time to the current UTC time, and older points following in the order in which they were determined. And, so as to permit safety applications to operate properly, the Path History data frame shall not include any additional data elements/frames in the BSMs intended for vehicle safety communications.
(ii) Path Prediction
Not only is it important to determine where a vehicle has been, it is also useful for safety applications to know where a vehicle is headed, or its future path. This future trajectory estimation can significantly enhance in-lane and out-of-lane threat classification.
Trajectories in the Path Prediction (PP) data frame are represented, at a first order of curvature approximation, as a circle with a radius, R, and an origin located at (0,R), where the x-axis is aligned with the transmitting vehicle's perspective and normal to the vehicle's vertical axis. The vehicle's (x,y,z) coordinate frame follows the SAE convention. The radius, R, will be positive for curvatures to the right when observed from the transmitting vehicle's perspective, and radii exceeding a maximum value of 32,767 are to be interpreted as a “straight path” prediction by receiving vehicles.
The radius, R, can be derived using various means, including map databases, vision systems, global positioning, etc. Alternatively, simple physics equations can be used to compute a curvature based on instantaneous dynamics information (vehicle speed and rate of change of heading, or yaw rate) provided by the vehicle. This curvature can then be extrapolated forward (as a continuous radius of curvature) to provide an estimate of the vehicle's likely intended future trajectory, or path. To minimize the effect of sensor noise and in-lane driver wandering, however, it is also necessary to use low-pass filtering techniques (time constant greater than 2 ms typically) in instances where the radius is derived from instantaneous vehicle information, such as from rate sensors and velocity.
Confidence in the predicted path based on the rate of change of the vehicle dynamics can also be computed in order to infer non-steady-state conditions, such as those stemming from lane changes, curve entry and exit points, curve transitions, and obstacle avoidance, where large changes in vehicle yaw rate occur over a short period of time. In such situations, path estimations may be largely inaccurate and, as such, confidence levels would be low. Conversely, a high confidence value would be reported during steady-state conditions (straight roadways or curves with a constant radius of curvature).
When a deviceis in steady state conditions over a range from 100 m to 2,500 m in magnitude, the agency is proposing to require that the subsystem populate the PP data frame with a calculated radius that has less than 2% error from the actual radius. The agency believes that this range and error rate is appropriate to ensure the effectiveness of safety applications that rely on such information. For the purposes of this performance requirement, steady state conditions are defined as those which occur when the vehicle is driving on a curve with a constant radius and where the average of the absolute value of the change of yaw rate over time is smaller than 0.5 deg/s2.
After a transition from the original constant radius (R1) to the target constant radius (R2), the subsystem shall repopulate the PP data frame within four seconds under the maximum allowable error bound defined above.
Lastly, when the transmitting vehicle is stationary, we propose requiring that a device report a “straight path” radius of value 32,767 and confidence value of 100%, which corresponds to a value of 200 for the data element.
(iii) Exterior Lights
For the Exterior Lights data element, the agency is proposing to require that the subsystem shall set the individual light indications in the data element to be consistent with the vehicle status data that is available. If meaningful values are unavailable, or no light indications will be set, the data element should not be transmitted.
The data element, Exterior Lights, provides the status of all exterior lights on the vehicle, including parking lights, Start Printed Page 3903headlights (including low and high beam, and automatic light control), fog lights, daytime running lights, turn signal (right and left), and hazard signals. This information can be used not only to enhance the operation of safety applications running on the transmitting vehicle, but it can similarly be used by other vehicles within range of receiving messages sent by the transmitting vehicle.
(iv) Event Flags
The data element, Event Flags, conveys the sender's status with respect to safety-related events such as antilock brake system (ABS) activation, stability control activation, hard braking, and airbag deployment, among others. Similar to that mentioned for the Exterior Lights data element, the additional information conveyed in the Event Flags data element can serve to augment the other BSM information used by applications when determining whether to issue or suppress warnings. Furthermore, because the inclusion of the Event Flag data element suggests that an unusual, safety-related event has occurred, vehicles receiving a message containing an Event Flag element may choose to process it differently than a message that does not.
The Event Flags and respective criteria the agency proposing to require in the BSM are defined in SAE J2735 as follows:
ABS Activation: The system is activated for a period of time exceeding 100 ms in length and is currently active.
Stability Control Activation: The system is activated for a period of time exceeding 100 ms in length and is currently active.
Hard Braking: The vehicle has decelerated or is decelerating at a rate of greater than 0.4 g.
Air Bag Deployment: At least one air bag has been deployed.
Hazard Lights: The hazard lights are currently active.
Stop Line Violation: The vehicle anticipates that it will pass the line without coming to a full stop before reaching it.
Traction Control System Activation: The system is activated for a period of time exceeding 100 ms in length and is currently active.
Flat Tire: The vehicle has determined that at least one tire has run flat.
Disabled Vehicle: The vehicle considers itself to be disabled.
Lights Changed: The status of the external lights on the vehicle has changed recently.
Wipers Changed: The status of the front or rear wipers on the vehicle has changed recently.
Emergency Response: The vehicle is a properly authorized public safety vehicle, is engaged in a service call, and is currently moving. Lights and/or sirens may not be evident.
Hazardous Materials: The vehicle is known to be carrying hazardous materials and is labeled as such.
If a stated criterion is met, the sender shall set the Event Flag to 1. If, and only if, one or more of the defined Event Flags are set to 1, the subsystem shall transmit a BSM with the corresponding Event Flags within 250 ms of the initial detection of the event at the sender. The Event Flags data element shall be included in the Vehicle Safety Extension data frame for as long as an event is active. Messages containing Event Flags may also include related optional data. When one or more criteria associated with an event are no longer satisfied, the sender shall set the flag to zero in any Event Flag data element that it sends.
The agency is requesting comment on the appropriateness of each of the Event Flags and corresponding criteria described above.
(f) Vehicle Based Motion Indicators
In addition to describing the location and the motion of vehicles, the device can use other pieces of information to verify state and motion, if the device has access. The agency assumes all integrated devices will have access this information. Aftermarket, standalone devices may or may not be able to access this information. This type of information in the basic safety message can collectively identify operational status and motion that can be used to confirm calculated position and future position of surrounding vehicles. Thus, it helps safety applications determine whether a potential crash imminent situation could exist.
Two pieces of information help fulfill this objective. They are the Transmission State and Steering Wheel Angle data elements. The Transmission State provides an indication concerning the operational direction of the vehicle in relation to its reference point. This information puts the speed, heading, location, etc. information into context. The steering wheel angle (which is not the same as the vehicle heading because this indicates the direction of the steering wheel control itself and not the vehicle) is a data element that indicates which way the wheels are turned, providing another possible indication of direction (in some cases the vehicle's wheels can be turned, however, the vehicle could be skidding in a different direction.).
(i) Transmission State
This data element would require that vehicles report whether they are in a gear in the forward or reverse (or neutral) direction. We tentatively believe that the relevant information for a safety application is whether the vehicle is in gear to begin moving; and if so, whether it will do so in the forward or reverse direction. Thus, our proposal currently does not include any requirement for reporting the gear ratios of the vehicle.
(ii) Steering Wheel Angle
This data element would require that vehicles report the direction of the steering wheel angle to within 5 degrees of the actual steering wheel angle. Here, we are seeking to use another element to confirm actual heading of the vehicle. Thus, the Steering Wheel Angle data element describes the movement of the steering wheel itself (i.e., it does not consider how such movement would affect the direction of the tires). Taking into account steering wheel angle provides a check of the position and motion calculations based on the actual state of the vehicle. We tentatively believe that expressing the steering wheel angle to an accuracy of 5 degrees is sufficient because we believe that a 6 degree change in steering wheel direction provides an indication of vehicle direction.
In other words, steering wheel angle changes of less than 6 degrees can be small adjustments in steering used to maintain current heading. However, steering wheel angle changes greater than 6 degrees result in a measurable change in actual heading of the vehicle. Thus, we tentatively conclude that an accuracy of 5 degrees would be sufficient to confirm (check plausibility) actual heading of the vehicle; i.e. if the actual heading is left are the wheels also turned to the left.
(g) Vehicle Size
This data element is also an element that is fundamental for a safety application's determination of whether a crash scenario might occur. In addition to knowing where a vehicle is, the characteristics of its motion (to predict where the vehicle will be in the near future), and some aspects of the Start Printed Page 3904driver's intent, a safety application needs to know how large the vehicle is in order to know whether a crash might occur. However, we also acknowledge that this data element has more potential privacy impacts than other data elements. As further discussed in this document, the V2V information environment uses multiple strategies to omit as much potentially identifying information as possible in the basic safety message, security credentials, etc. However, we acknowledge that if the vehicle size information is too specific, it could potentially facilitate an effort to identify basic safety messages to a particular vehicle over time. The agency believes the performance metric for this data element balances not only the safety need for accurate information about the vehicle size, but also the privacy needs of the driver.
Thus, we tentatively believe that having a 0.2 m tolerance is an appropriate balancing of those competing interests. This level of specificity meets the need to identify the physical extent of the vehicle for crash avoidance given that vehicle size is to be rounded up which will still provide for the appropriate calculation of a warning such that the driver can take appropriate action to avoid a crash. The additional size for some vehicles will only present an insignificant amount of additional warning time (0.0022 seconds at 25 mph to 0.007 seconds at 65 mph using a 3 second time to collision baseline) that will be transparent to all drivers.
In addition to considering different tolerances for the vehicle length and width data elements, another option is to use vehicle size categories or only express the vehicle length and width in increments of a given value. For example, requiring that the vehicle length be expressed in only increments of 0.2 m would mean that a vehicle with a 10.12 m length and a vehicle with a 10.01 m length would have the same value of 10.2 for the vehicle length in the basic safety message. This type of requirement could have the advantage of aggregating many different vehicles into particular size categories and potentially help discourage identifying a basic safety message to a particular vehicle. We request comment on these potential options (i.e., not only the potential tolerances for these data elements but also the potential to use size categories).
(h) Optional Data Elements
SAE J2735 also contains a variety of additional data elements that the agency is not proposing requirements for in this notice. We tentatively believe that these data elements are elements that may be useful in safety applications that may be used by various suppliers to enhance the operation of an application to issue a warning or suppress a warning. While these data elements will add more information on a status of the vehicle (especially with regard to whether a vehicle is under control), we do not currently have enough information to determine how such information might be applied to an application and thus tailor such information to that application (or applications). Thus, we tentatively believe it is premature to propose requirements for these data elements but are preserving the possibility for these data elements to potentially be employed to ensure future interoperability as technology evolves. The agency is proposing to require that devices either adhere to SAE J2735 for these data elements, or transmit the “unavailable” data value for each of these elements (in accordance with SAE J2735) These data elements are:
- Brake applied status
- Traction control state
- Stability control status
- Auxiliary brake status
- Antilock brake status
- Brake boost applied
- Location Accuracy
(i) Excluded Data Elements
When identifying the data elements to include in the BSM, the agency considered those that would be needed to support possible future applications and the suppression of warnings to reduce the number of false positive warnings. The use of some applications may be limited only to authorized vehicles—for example, only law enforcement and emergency vehicles might have access to an application providing traffic signal priority or pre-emption for emergency or enforcement purposes. To support identification of authorized vehicles, the agency considered including in the BSM optional elements such as the Vehicle Identification Data Field, which includes: VIN string, Owner code, Temporary ID, and Vehicle type. These data elements could identify and verify an emergency or law enforcement vehicle to a traffic control device for signal preemption purposes. However, our privacy experts identified VIN and other data elements directly linked to specific private vehicles and their owners as potential sources of privacy risk to individuals.
To help reduce the privacy risk that could stem from the transmission of information that could be used to associate V2V messages with individual consumers, our proposal excludes certain data elements from transmission as part of the BSM. Specifically, V2V transmissions via DSRC or any future interoperable V2V communications technology may not include data directly identifying a specific private vehicle or individual regularly associated with it, or data reasonably linkable or linkable, as a practical matter, to an individual.
NHTSA intends for the terms “reasonably linkable” and “as a practical matter linkable” to have the same meaning, specifically: Capable of being used to identify a specific individual on a persistent basis without unreasonable cost or effort, in real time or retrospectively, given available data sources.
NHTSA seeks comment on these tentative conclusions. Specifically, we request comment on our proposed exclusion from the BSM of data elements that directly identify, or are reasonably linkable or linkable as a practical matter, to a private individual. Do commenters have thoughts on whether, as a practical matter, any data element (or combination of data elements) currently proposed as part of the BSM is reasonably linkable to an individual on a persistent basis? We seek comment on whether this aspect of NHTSA's proposal appropriately balances consumer privacy with safety—or whether, by declining to identify definitively those data elements that are, or may be, “reasonably linkable” to an individual (and therefore must be excluded from the BSM under NHTSA's proposal), NHTSA will undermine the NPRM's overarching goal of establishing a standardized data set for the BSM and providing adequate data for safety applications.
(2) Proposed BSM Data Initialization Requirements
In addition to the content of the basic safety message, we are aware that participants in the V2V Safety Pilot have included data persistency performance in their on-board V2V systems in order to minimize the time needed for vehicles to begin transmitting basic safety messages after the vehicle starts up.
The advantage of doing so is that when the vehicle starts up, it already has information about its last known location, heading, etc. that was accurate when it shut down. The premise is that upon device startup, the device could begin transmitting sooner rather than waiting for new information, such as receiving a new heading or calculating Start Printed Page 3905path history, both of which would require the device to acquire GPS data and start moving. In many instances, this would reduce the time to initialize the first (after startup) transmission of the BSM. As the vehicle most likely did not travel while it was shut down, the information it saved during shut down should still be accurate upon startup. However, there could be scenarios when the last known heading and path history will be inaccurate, such as when parking “head” or “tail” in (higher frequency) or if the vehicle has been towed (hopefully, very low frequency).
NHTSA recognizes that the practice of saving vehicle data over vehicle on-off-on events is typically used to enhance feature performance, improving consumer acceptance. However, NHTSA does not believe at this time that a minimum requirement for data persistency is needed, nor that we need to identify specific data elements that should be stored upon shutdown and retrieved at startup.
Based on the available information, we currently agree with the research to date that minimizing the time it takes for a vehicle to begin transmitting the basic safety message is desirable as it helps ensure that vehicles will be providing information into the V2V environment as soon as possible after they begin moving. We also agree with the research to date that including data persistency performance in vehicle V2V systems is a good way to accomplish this task.
Instead, the agency's proposal would require that vehicles begin transmitting basic safety messages within a specified amount of time after startup without specifying the method that a manufacturer would choose to meet that requirement. While a manufacturer may use data persistency techniques to meet the performance requirement, we believe that this method for achieving the safety goal appropriately gives the manufacturer more design flexibility.
While the basic safety message transmitted from one vehicle can be useful to other vehicles when the vehicle is stationary, we currently believe that (at a minimum) the vehicle should begin transmitting basic safety messages at a time when we might reasonably expect people to begin driving their vehicle after getting into it. In other words, our current thinking is that the vehicle should begin transmitting before the vast majority of drivers begin driving the vehicle.
The proposed requirements are that a vehicle shall begin transmitting the basic safety message within 2 seconds after a vehicle key on event has occurred. This proposed requirement is based on the final performance requirement associated with FMVSS No. 111 for rear visibility systems. While a V2V system and rear visibility system are not identical, the agency believes the research and decisions leading to finalizing the two second system startup requirements are fungible to V2V and the overarching safety goal.
In NHTSA's rear visibility rulemaking, our naturalistic driving data indicated that 90% of drivers do not select reverse and begin the backing maneuver less than 4.25 seconds after opening the vehicle door.
While in this case, the safety technology proposed for the vehicle is not one that would only be used when the vehicle is traveling in reverse, we believe that the data is a reasonable proxy for when drivers would put the vehicle in gear (forward or reverse) and begin driving. Since our safety goal in this situation is to ensure that the vehicle is transmitting the basic safety message before the vehicle begins to move, we believe that using a performance requirement based on the rear visibility rule's image response time requirement (and test procedure) would be appropriate.
While based on FMVSS No. 111, this proposed requirement for V2V initialization time would need to adjust the test procedure in a few ways to account for the characteristics of a vehicle's V2V system. First, we note that vehicle's V2V system needs to be active whether the vehicle is moving in reverse or moving forward. Thus, the test procedure and requirements should not be based solely on reverse gear. Second, while the temperature condition of the test would affect the rear visibility system display's response time, the temperature condition is not as relevant for a vehicle's V2V system. Instead, the test should specify environmental conditions that approximate the level of access to characteristics of its surrounding environment that a vehicle would normally have to populate the information in the basic safety message (e.g., open sky access to GPS signals, potential saved location/heading information from the basic safety messages prior to vehicle shutdown, etc. Thus, the preconditioning test applied to the vehicle would need to be modified in these ways.
In summary, NHTSA is proposing to require that, after a conditioning procedure, vehicles begin transmitting basic safety messages with the required content and at the required frequency within 2.0 seconds after the driver puts the vehicle into the forward or reverse gear. The conditioning procedure would specify that the vehicle is under open sky conditions as in our test procedure for evaluating the content of the basic safety message. Then the procedure would specify that the test technician:
- Drives the vehicle in any heading at any speed for five minutes;
- stops the vehicle and deactivates the vehicle for any amount of time between 30 minutes to an hour;
- checks to ensure that the V2V system components are in a powered off state;
- opens the driver's door to any width,
- closes the driver's door;
- activates the starting system using the key; and
- selects any gear (forward or reverse) at any time not less than 4.0 seconds and not more than 6.0 seconds after the driver's door is opened. The driver door is open when the edge of the driver's door opposite of the door's hinge is no longer flush with the exterior body panel.
We acknowledge that this procedure may not be representative of a small number of real-world scenarios. For example, if a vehicle is in a parking structure like a garage, it might not have access to open skies. However, for these instances we do not think that there is any practicable way for the vehicle to ascertain its position quickly using GPS. Thus, we cannot determine a way to ensure that a test specifying those conditions would be a practicable test. We also note that the proposed procedure does not include moving the vehicle between shut down and startup. While vehicles might be moved when shut off, we think those are special circumstances (e.g., when the vehicle is towed). Those conditions are a small portion of real-world scenarios and they are situations where the driver is likely to spend more time with the car active before encountering other vehicles (e.g., when starting up in a towed vehicle lot, the vehicle may not interact with other moving vehicles until it reaches the roadway).
We request comment on our proposal for helping to ensure that vehicles begin broadcasting basic safety messages before a vehicle begins to move. More specifically, NHTSA requests comments in relation to whether a data persistency requirement is needed, and specifically in relation to:
- Supporting the interoperability of V2V devices;
- The performance of BSM transmission and how data persistency can be used to properly reduce the time of the initial transmission; and
- The possible impacts to crash avoidance functionality.Start Printed Page 3906
Please provide any supporting evidence that the agency can used to make an informed decision.
(3) Summary Table of BSM Content Requirements
Table III-3—Summary of BSM Content Requirements 150
|Message Packaging||Message ID—(2) for BSM Message Count—sequence No
Temp ID—random No. from specific device||Preliminary elements need to ID, process, and sequence BSMs||SAE J2735||Allows device to interpret message and obtain safety information.|
|Time||Use UTC standard to set time||UTC is accepted standard for setting universal system time||SAE J2735, J2945/1||Need time standard to related messages to time critical conflict situations.|
|Position (Longitude & Latitude)||Longitude and Latitude within 1.5m of actual position at HDOP <5 and 1 sigma absolute error||Per CAMP research to develop relationship between measurable absolute position and relative position||SAE J2735, J2945/1||Provides for accurate relative vehicle position need to support crash avoidance—(CAMP).|
|Position (Elevation)||3m (10 feet) (more difficult to calculate than lat/long)||Accurate elevation reduces false positives—SPMD||SAE 2735, J2945/1||3m provides for low bridges and changes in grade for crash avoidance.|
|Movement (Speed)||Accurate within 0.28 m/s (1 kph)||Same as EDR rule—tighter accuracy then identified by CAMP. Changed to be consistent with existing standard||SAE J2735, J2945/1||The setting is based on the need to provide accurate and timely safety alerts. The setting was obtained by extensively testing commercially available equipment and automotive sensors in a wide variety of driving environments.|
|Movement (Heading)||Speed >12.5 m/s accuracy within 2 degree—Speed >12.5 m/s within 3 degrees||Research indicates that above 12.5 m/s sensors and vehicle dynamics can support 2 degrees—under 12.5 m/s can support 3 degrees||SAE J2735, J2945/1||Same as above.|
|Movement (Acceleration)||Longitudinal & Lateral accuracy 0.3 m/s2—Vertical accuracy 1 m/s||CAMP research and testing||SAE J2735, J2945/1||Same as above.|
|Movement (Yaw rate)||Accuracy within 0.5 degrees per second||CAMP||SAE J2735, J2945/1||The setting is based on the need to provide accurate and timely safety alerts. The setting was obtained by extensively testing commercially available equipment and automotive sensors in a wide variety of driving environments.|
|Vehicle Motion Indicator (Transmission)||Report if vehicle is in forward or reverse gear, or neutral||CAMP||SAE J2735, J2945/1||Same as above.|
|Vehicle Motion Indicator (Steering Wheel Angle)||Report the direction of steering wheel angle within 5 degrees of actual||CAMP||SAE J2735, J2945/1||Same as above.|
|Vehicle Size||Vehicle length and width within 0.2m tolerance||CAMP and MITRE privacy research||SAE J2735, J2945/1||Balance the need to know the physical extent of the vehicle for crash avoidance and still protect privacy.|
|Start Printed Page 3907|
|Excluded Data Elements: No data elements directly or, as a practical matter, linkable to a specific individual or vehicle (including but not limited to VIN string, Owner code, Temporary ID, Vehicle Type)||Mandate that these optional data element cannot be populated for device in privately owned light vehicles||MITRE privacy research||SAE J2735, J2945/1||To protect consumer privacy by reducing privacy risk.|
|Path History||Provides concise representation of vehicles recent movements with accuracy of min 23 points and required to be transmitted with BSM||CAMP research to support crash avoidance||SAE J2735, J2945/1||Use in calculations to identify vehicle conflict situations.|
|Path Prediction||Perpendicular Distance—1M; Radius error—2%; Transmission Time 4s||CAMP research||SAE J2735, J2945/1||The setting is based on the need to provide accurate and timely safety alerts. The setting was obtained by extensively testing commercially available equipment and automotive sensors in a wide variety of driving environments.|
3. Message Signing and Authentication
(a) Purpose and Safety Need for Confidence in the BSM
As discussed previously, V2V safety applications can utilize the data in the basic safety message (such as position, heading, and speed) about other vehicles around it to determine whether it and another vehicle are in danger of crashing. In other words, a safety application would determine whether it is necessary to take action (e.g., issue a warning) based on the information coming from another, nearby vehicle. Even in a warning system, it is important for safety applications to have accurate information available to make their decisions. Incorrect warnings can (at worst) directly increase safety risks and (at minimum) affect the driver's acceptance of the warning system. If the driver of a V2V-equipped vehicle receives a large number of warnings when there is no crash imminent situation (i.e., false warnings), then the driver may lose confidence and not respond appropriately when there is a true crash-imminent situation.
Thus it is important that the safety application can place as much confidence as possible in the data contained within BSM messages and detect when messages are modified or changed while in transit. To help improve the level of confidence in BSM messages the agency's primary message authentication proposal describes a Public Key Infrastructure (PKI) approach to message authentication.
In addition two alternatives are presented for comment. This first alternative for message authentication set out for comment is less prescriptive and defines a performance-based approach rather than a specific architecture or technical requirement. The second alternative set out for comment stays silent on message authentication and does not specify a message authentication requirement, leaving authentication at the discretion of V2V device implementers.
(b) Public Key Infrastructure Proposal
The agency is proposing to mandate requirements that would establish a message authentication approach based on a Security Credential Management System (SCMS) that uses Public Key Infrastructure (PKI) digital signatures to sign and verify basic safety messages. This would include requiring devices to sign each message, send a valid certificate with each message, and periodically obtain up-to-date security materials.
(1) How does the Public Key Infrastructure validate messages?
When transmitting a BSM, the sender uses a security certificate issued by a certificate authority to digitally sign each BSM. The security certificate is composed of the following elements:
- A date range describing the validity period for the certificate
- A Public key corresponding to a private key
- Digital signature from a certificate authority
When a nearby device receives a properly formed BSM, it can use the certificate included in the BSM to verify that the digital signature in the BSM is valid. Furthermore, the receiving device can also verify that the security certificate included in the BSM is valid as well. The receiving vehicle can verify that digital signature on the certificate included in the BSM is digitally signed by the certificate authority that issued it to the sending device. The receiving device should already have a copy of the authorizing certificate for the authority stored on-board. In the event that it does not, the receiving device would need to request the authorizing certificate from the sending device. Once the authorizing certificate is obtained, the receiving device can verify that the certificate authority is valid and the certificate used to sign the BSM is also valid. This process can be repeated for any number of certificate authorities that are in the PKI hierarchy, up to the root certificate authority, which authorizes the entire system. This process allows receiving devices to verify a sender's credentials. For detailed information on the proposed Security Credential Management System, see Hehn, T., et al., “Technical Design of the Security Credential Start Printed Page 3908Management System”, 2014, Docket No. NHTSA-2015-0060-0004.
The SCMS organization certifies that a device is indeed authorized to participate in the V2V environment and then issues credentials to the device. Thus, a receiving device can have more confidence in the information contained in a BSM message because it knows that the SCMS previously confirmed the sender is an approved device and issued these credentials.
In addition to the SCMS device certification, a device also needs to properly sign the basic safety message. The following sections discuss how the device utilizes the certificates from the SCMS and how the agency can confirm that devices are doing so.
(a) Signing the Basic Safety Message for Transmission
The process for signing the basic safety message involves the use of two “keys,” one public and one private.
The signature process uses the private key and an original string of numbers as inputs to generate an encoded string of numbers (an otherwise meaningless set of numbers). The public key associated with that private key is then used by the signature verification process to reverse the signature process (i.e., take the encoded string of meaningless numbers and reverse it to generate the original string of numbers). Therefore, the receiving device takes the information from the sending device and (using the characteristics of these equations) can verify the signature of the sender.
The agency employed this signing process in V2V devices used throughout its research activities and was proven through the Safety Pilot Model Deployment activity. Devices in these activities have been signing the basic safety message and constructing the security credentials of the message by combining the message content with the certificate, the signature, and the time stamp of the information.
Table III-4 shows how the public key, private key, and signature fit together with the other parts of the basic safety message.
Table III-4—Basic Safety Message Key Components
|• Public Key
• Signature of the Pseudonym Certificate Authority
• Says when certificate effective and when expires||(i.e., the speed, heading, location, etc. information that supports the safety applications)||Produced from the following steps: • Compute hash of the Message Content and Timestamp
• Use your private key to create an encoded string of numbers
• The encoded string of numbers is your signature||(i.e., when the information is transmitted.]).|
When the transmitting device sends a basic safety message it assembles each of the parts of the message in Table III-4 above. The vehicle uses a combination of the message content, timestamp, and a private key to generate the signature. The device also attaches the certificate to the message. The certificate includes the public key, corresponding to the private key used to sign the message, the validity period of the certificate, and the signature from the Pseudonym Certificate Authority. The pseudonym certificate contains the signature of the PCA from the SCMS allowing message receivers to verify the pseudonym certificate. The validity period is used to determine if the certificate is valid or if the receiving device should reject the credentials if they are expired.
The vehicle constructs the signature by using the message content and the time stamp portions of the message as inputs into the following process:
(a) Create a hash 
of the message content and timestamp (i.e., a shortened version of the message content/time stamp that is fixed length—e.g., 32 characters). A standard NIST formula (SHA-2) 
governs the creation of the hash.
(b) Input the hashed contents through an Elliptical Curve Digital Signature Algorithm 
(the equation that creates the encoded string of numbers). The resulting number is the “digital signature.”
(b) Verifying the Signature Upon Receipt
A device receiving the basic safety message performs the following sequence of steps in order to verify the signature:
(a) Generate the hash of the basic safety message content and timestamp using the same NIST defined formula used for generating the signature.
(b) Input the message hash, public key, and digital signature into the signature verification function (ECDSA) to verify the BSM digital signature is valid.
(c) Verify the pseudonym certificate (from the sending device) is within the validity period.
(d) Verify the digital signature of the pseudonym certificate back to the root certificate authority ensuring the SCMS issued the credentials.
(e) Verify the pseudonym certificate is not listed on the Certificate Revocation List.
Start Printed Page 3909
As discussed in the next section, the agency is considering a potential test method that would mimic many of the functions of the receiving device in order to assess whether devices are properly signing their messages with valid credentials when they are transmitting basic safety messages.
(2) Potential Requirements and Testing for Message Signing and Authentication
The agency is currently considering evaluating a device's ability to properly sign the basic safety message by utilizing a test device to receive basic safety messages during a static test. The test device would perform the key functions described above to verify the authenticity of the sender and of the message. Following is discussion of the general testing framework and the potential performance requirements that the agency is considering within the context of such a test.
(a) Potential Message Authentication Test Method
The agency currently envisions testing message authentication for compliance as executing a message security and signage protocols test in a static test environment (i.e., a “security credentials test”). The test would be conducted using a vehicle resident V2V device and an agency developed test device positioned in close proximity to each other.
In effort to replicate real-world conditions, the agency's current strategy is to define a test device that can perform the following functions as described in SAE J2945/1 v1.0 
(which itself references specific clauses and sections of relevant IEEE P1609 and 802.11 standards).
- If the full pseudonym certificate is included in the BSM, then the device will need to extract the public key from the pseudonym certificate of the test vehicle.
- If the certificate digest (hash of the full certificate) is included in the BSM, then the device will need to perform a look-up in cached memory of the full certificate and then extract the public key from the pseudonym certificate of the device under test.
- Confirm that the public key and the credentials in general are indeed from the SCMS (i.e., verify the pseudonym certificate authority all the way up to the root certificate authority).
- Use the public key to verify the signature section of the basic safety message (i.e., execute the ECDSA verification algorithm).
In terms of specific procedures, we tentatively believe that using many of the test conditions from our static test evaluating the transmission range and content of the basic safety message would be appropriate. In essence, we believe that the same test could be used to also evaluate whether the vehicle is appropriately signing its basic safety messages. Tentatively, we believe that including the following additional step in the static test would be sufficient to evaluate this area of performance.
- Collect basic safety messages from a transmitting device for at least 100 minutes and repeat the test at least seven days later.
- Using the messages collected in this test, the agency's test device should be able to verify the device under test is properly signing the basic safety message.Start Printed Page 3910
- The data collected should also reveal that the device under test is sending the required certificate (from the pseudonym certificate authority) or the certificate digest.
- The agency's test device should also be able to determine whether the device under test is using credentials issued by the appropriate authority (i.e., is the root certificate ultimately one that is authorized by the SCMS?).
- Finally, the test duration timeframes of this additional step should enable our test device to determine whether the vehicle is changing its certificates at the required interval.
We request comment on this test method and commenter's input on a potential test device that could be used to execute this proposed test schema. Would a test device that performs all of the functions outlined above sufficiently mimic real world conditions and also define those conditions sufficiently to achieve a repeatable test method? What other details should the agency explore and define? Are there other test methods that the agency should consider that can confirm that the transmitting vehicle signs the basic safety message properly with a less complex test?
The agency is also proposing to adopt a static test to evaluate the transmission range and other requirements (see Section III.E.1.a)). As testing experienced is gained, it may prove more efficient to combine the security credential, RF transmission, and possible other tests. The agency invites comment on the potential to combine and streamline test where possible.
(b) Signing the Message
Using the potential test method described in the previous section, we believe the agency would be able to verify that V2V devices are properly signing their basic safety messages, authenticating themselves as accurate sources of information. In essence, by using a test device that would be able to verify the digital signature using the ECDSA algorithm, the proposed test schema confirms that:
- The sending device produced the correct hash of the message content/timestamp;
- the sending device appropriately sent its pseudonym certificate; and
- the public key could decode the signature created by the sender's private key.
By comparing the hash created by our test device to the hash decoded from the basic safety message we received from the device under test, our test procedure should be able to confirm the device under test is correctly signing the basic safety message. Further, we anticipate that the test device would also identify the root certificate authority and validate up to the root certificate authority.
(c) Certificates and Certificate Digests
The agency is considering including requirements to reduce the size of the basic safety message by requiring that vehicles not transmit parts of the basic safety message when they are not necessary. In theory, this could potentially conserve bandwidth in higher volume scenarios. The pseudonym certificate included in the basic safety message is an area under evaluation where message size could be reduced.
A receiving V2V device requires pseudonym certificates to decode the signature and confirm the identity of the sender. However, the agency does not anticipate that every message will need to carry the full certificate as the pseudonym certificate does not change for every message. This allows a period of time where the same certificate and potentially allowing for messages to only part of the entire pseudonym certificate. Therefore, the agency believes it would be appropriate, under certain circumstances, for devices to transmit a certificate digest which would be a hash of the full certificate.
A potential challenge to this approach is requiring a receiving device to support capture and storage of full certificates and certificate digests, as transmitting only a digest necessitates relating the digest to a full certificate. In addition to the capture and storage of certificates, the agency is also evaluating a potential requirement for the interval between the transmission of a full certificate and certificate digests. Current research suggests that the vehicle should transmit the full certificate twice per second and the digest the remaining times. However, if there is an event flag (e.g. hard braking event) in the BSM, the agency believes the full certificate should be transmitted at the next immediate opportunity. At this time our current proposed requirements do not cover this aspect of the device and but the agency requests comment concerning the need to employ certificate digests in place of the entire certificate.
We tentatively believe that a final rule on V2V would need to establish at least a minimum interval for transmitting the full certificate so that surrounding vehicles will know the maximum amount of time that they will need to wait in order to be able to confirm the identity of a transmitting vehicle. Without such a requirement, we question whether the standard would be able to ensure that vehicles transmitted their pseudonym certificate at a sufficient frequency to support the safety applications that other vehicles may use. However, we request comment on whether a minimum requirement for transmitting the full certificate is necessary. If so, what the minimum time should be and whether a maximum time (or a specified interval such as 1 time per second) would be appropriate for this aspect of performance.
Thus, for this aspect of performance, our final performance requirements could specify minimum (and potentially maximum) times for transmitting the full certificate and requirements for what types of information need to be in the certificate digest. Thus, in addition to the testing method that we described above, our test device for that test method would also need to ensure that:
- The vehicle is transmitting the full certificate at the required interval;
- the vehicle is transmitting the certificate digest (which identifies the full certificate and when the full certificate was transmitted with all other messages that do not have the full certificate; and
- the certificate or digest transmitted along with a basic safety message is valid (i.e., it is a valid certificate issued by the SCMS/has the appropriate credentials from the root certificate authority).
(d) Changing Certificates and Privacy
As part of the process of signing a V2V message using the proposed SCMS approach, a vehicle could use a single certificate that is valid for a long period of time (e.g., years) to sign all basic safety messages that it transmits. This would help ensure that safety applications would be able to differentiate between authenticated sources of information and other less reliable sources of information when making judgements about their surroundings.
However, this approach could create additional privacy risk for consumers, as use of a single certificate could enable an observer collecting V2V transmissions to associate the basic safety messages coming from a single V2V device with a single sender. While associating a group of messages with a specific driver would need additional information outside of the V2V system, additional information would not be needed to know that all messages using the same certificate come from the same vehicle. To help mitigate this risk, we propose that vehicles frequently change or rotate certificates so that it will be more difficult to associate a large Start Printed Page 3911number of basic safety messages with the same V2V device or vehicle. Also, we are proposing that certificates not be valid for long periods of time to reduce the risk that they be collected and used to identify a specific vehicle at a future date and time.
(i) Current Research on Changing Certificates
Recent research evaluated several models for changing certificates. In the Safety Pilot Model Deployment, certificates had a validity period of 5 minutes and were completely discarded after use. Changing certificates on a more frequent basis helps to minimize potential privacy risk for individuals, it requires a large volume of certificates for a vehicle to manage, approximately 100,000 certificates for one year of operation. Model Deployment researchers determined that this approach would be inefficient as the majority of the time a vehicle is not in operation but certificates were still expiring even when the vehicle was not in operation. Based on the experiences learned from this project, the researchers developed a more efficient design where a vehicle will have 20 valid certificates per week and changes certificates at least once every 5 minutes. Under this design, only 1,050 certificates would be needed per year. This is believed to strike a balance between privacy and efficiency by using certificates that rotate every five minutes and are valid only for one week. This alternative certificate usage model is currently under development and will be tested in the field as a part of the SCMS Proof-of-Concept projects.
(ii) Potential Performance Metric
We recognize that methods of changing certificate credentials exist on a spectrum between the competing interests of maximizing privacy protections and technological practicability. For example, it would afford the most privacy protection for consumers to use a different set of credentials with every basic safety message (i.e., change certificates 10 times per second). However, this would be impracticable because it is unreasonable to expect the SCMS to produce enough certificates to service all V2V devices when they use ten new certificates every second.
On the other hand, using the most technically simplistic method for authenticating the sender of the message would be to use one set of credentials for every message. However, as we described above, that would create significant privacy risk by associating all basic safety messages sent from a single source with each other.
In order to balance these competing interests, our tentative conclusion is that the current method for changing certificates used in the research would be a reasonable compromise that protects privacy in a technically feasible way. By rotating among 20 certificates every five minutes, we are ensuring that no group of basic safety messages will be linked to more than 5 minutes of other safety messages at a time. In other words, a person obtaining basic safety messages from a device may not be able to associate those messages with each other because their certificate is only used for 5 minutes out of every 100 minutes. Further, a device shutting off at one particular location would unlikely use the same certificate upon startup. Finally, in order to ensure that a person could not obtain all 20 certificates for a particular device, we are proposing for devices to completely discard their certificates each week and replace them with 20 new certificates.
We request comment from the public on our proposed method for changing certificates and privacy concerns. Have we appropriately balanced the privacy interest with the interest in maintaining the technical feasibility of producing and storing certificates in vehicles? Is periodically rotating certificates the right approach to limiting the privacy impact of having signed messages? Have we established the appropriate thresholds for the method for changing certificates (i.e., have we selected the correct duration for when devices need to rotate certificates and change the certificates to new ones altogether?). Further, should the agency establish requirements for rotating the 20 certificates (i.e., should the device rotating among 20 certificates every five minutes use the same order for rotating through the certificates or should the device use a different order the next time it cycles through the 20 certificates? What method should the agency choose for changing the cycling order of the 20 certificates?).
(iii) Test Method
As we discussed in Section III.E.3.b)(2)(a), our static test method for assessing whether a device is appropriately signing their basic safety messages can also assess whether a device is changing its security credentials as required if our test lasts for an appropriate amount of time. Based on our proposed requirements, we believe that it is appropriate to test the device for 100 minutes twice, separated by 7 days.
Testing the device for a 100 minute duration would sufficiently assess whether the device is rotating certificates every five minutes and using a different certificate every five minutes for the duration of 100 minutes (i.e., 20 certificates × 5 minutes per certificate). Finally, conducting this test twice (separated by 7 days) would allow the test to confirm whether the device is using 20 new certificates that are different from the certificates the device used in the first test.
(e) Preventing Message Transmission Without Valid Certificates From a SCMS
The agency is also considering whether to require that devices stop transmitting basic safety messages if they lack valid security credentials, i.e. device transmission problems or being identified as a misbehaving device. The purpose would be for devices to avoid sending basic safety messages due to incorrect credentials. However, at this time, the agency does not have performance requirements or a test method for assessing this aspect of performance. In order to test this aspect of performance, the agency would need a method for exhausting the certificate supply of a vehicle and observing whether the vehicle would continue to transmit basic safety messages. We request comment on whether there is a practicable and repeatable way for producing these conditions in a vehicle under test. We also request comment as to whether this aspect of performance should be included in the final rule.
(3) Potential Regulatory Text for SCMS Based Message Authentication
The agency has included no regulatory text for SCMS-based message authentication and instead has a bracked placeholder for where it would be if this were to be part of a final rule. The agency expects that regulatory text in any final rule would include:
- Additional definitions in S.4 Definitions for ” SCMS-based message authentication, which would be consistent the discussion in this proposed rule and any public comments.
- A provision on signing the BSM, which would require that the device must generate a signature for each BSM.
- A provision on rotating certificates.
(c) Alternative Approach—Performance-Based Message Authentication
The agency is also bringing forth potential alternatives to the SCMS-based Start Printed Page 3912proposal for V2V message authentication. This first alternative takes a far less prescriptive approach to authentication and defines a performance-basedbased approach but not a specific architecture or technical requirement for message authentication. The basis of this alternative is to let V2V device implementers define their own approach for improving the integrity and authenticity of V2V messages.
The fundamental approach to this first alternative only requires that the receiver of a basic safety message be able to validate the contents of a message such that it can reasonably confirm that the message originated from a single valid V2V device, and the message was not altered during transmission. This alternative would broadly require that implementations utilize government-audited and approved cryptographic algorithms, parameters, and approaches.
(2) Illustrative Example
For illustrative purposes, consider the following example technical implementation. The sender of a BSM could use a security certificate issued by a certificate authority to digitally sign each BSM. The security certificate could be composed of the following elements:
- A date range describing the validity period for the certificate
- A Public key corresponding to a private key
- Digital signature from a certificate authority
(3) Potential Requirements Under This Alternative
(a) Test Method and Test Device
This alternative's less prescriptive approach for message authentication results in a general testing requirement that would similar in context as the proposed PKI based authentication but leaves the extent of the proposed requirement undefined, or yet to be defined, static test procedures. This approach is inherently aligned with recognizing that potential future communication and their potential message authentication needs would be varied and, therefore, requires varied test methods for message signing and authentication.
NHTSA seeks comment on potential test methods and the test devices that could accommodate other, future, or yet-to-be-developed message signing and authentication schemas that could be applied to V2V communications. The agency is interested in details on how a test device could fulfill the general requirement to sufficiently reflect real-world conditions and also define those conditions sufficiently to achieve a repeatable test method that ensure verified communications between V2V devices, using varied communication mediums? What other details should the agency explore and define? Are there other test methods that the agency should consider that can confirm that a transmitting V2V device signs the basic safety message properly?
(d) Alternative Approach—No Message Authentication
This second potential alternative set out for comment does not specify any message authentication requirements for devices participating in a V2V communications. Under this second potential alternative, BSM messages would still need to be validated with a checksum or other integrity check and employ some form of through a misbehavior detection system to attempt to filter malicious or misconfigured messages. However, there would be no specific message authentication requirement. Implementers would be free to include such a feature as an optional function. The agency would not establish any performance requirements or test procedures under this potential alternative. The agency seeks comment on this no message authentication approach.
4. Misbehavior Reporting
(a) Proposal—Misbehavior Reporting to a SCMS
NHTSA is proposing to establish practices and procedures for devices participating in V2V communications to recognize device misbehavior, both internally and by other devices. The fundamental purpose of misbehavior detection is to provide a means for V2V devices to identify and block messages from other misbehaving or malfunctioning V2V devices. V2V devices would be required to report device misbehavior to a central authority, namely the Security Credential Management System, once misbehavior is confirmed via a series of self-diagnosis or plausibility checks on incoming messages. This includes identifying methods for device self-diagnosis of both hardware and software to ensure that the device has not been altered or tampered with from intended behavior.
If an anomaly is detected and confirmed by a series of secondary plausibility checks, a “misbehavior event” would be identified, and a sample of BSM information such as geo-location, time-stamp, and a digitally signed (encrypted) certificate from the misbehaving device would be recorded as “evidence” of the event. The reporting device would then transmit its misbehavior report to the SCMS misbehavior authority (MBA) using a secondary communications channel.
The intent of the MBA is to gather misbehavior reports by all devices participating in the network. These reports would be analyzed in accordance with established and governed policies for global misbehavior detection determine if and when a particular vehicle should be placed onto a Certificate Revocation List (CRL). More accurately, is and when information related to a particular device's certificates should be placed onto the CRL such that other vehicles can use the information to identify the misbehaving device, assume it cannot be a trusted device, and ignore its messages. The CRL would be updated periodically by the MBA and distributed to participating V2V devices.
The agency views misbehavior detection as a key feature of the proposed security architecture: That misbehaving devices are able to be efficiently detected, and their identity made available to other devices participating in the network. At the highest level, confidence in the V2V messaging could be eroded if misbehaving devices are not detected and reported to a centralized authority.
As indicated in Table II-5, additional research is being conducted to better understand the data, processing, and algorithm development necessary to implement misbehavior detection at both the local (device) level and global (SCMS) level. For misbehavior to be effective, techniques must be identified, developed, and implemented in both devices and at a central authority for the system to secure V2V messages. The proposed requirements concerning detection and reporting support misbehavior detection functionality, but do not include at this time the actual techniques to detect and identify misbehavior. Research is being conducted; however, the actual nature of misbehavior in the V2V ecosystem has yet to be defined given the lack of misbehavior data to support actual development of techniques and algorithms. Initial data will be available once the SCMS Proof-of-Concept (Section V.B.6.e) is operational and supporting the security of the Connected Vehicle Pilot activities. The agency seeks comment regarding the requirements to support misbehavior detection, the investigation of detection and identification techniques, and possible implementation issues including the need to evolve detection Start Printed Page 3913and identification algorithm capabilities over time.
The agency has worked extensively with its research partners to develop a comprehensive set of proposed reporting requirements for misbehavior detection. The reporting requirements attempt to strike a balance between frequency, the amount of data reported, and the need to effectively and efficiently identify misbehavior to mitigate any potential effects. As described previously, the purpose of the misbehavior reports is to:
- Indicate potential misbehavior and misbehaving devices, and
- indicate suspicious activities around the reporting device.
(a) Report Content
The agency is proposing that a misbehavior report is a message signed by the reporting device and shall include at a minimum the following data:
- The reporter's certificate.
- GNSS coordinates (latitude, longitude and elevation) at the location where the misbehavior was initially identified.
- The GNSS coordinates where the misbehavior appears to have ended. This field is optional as it may not apply to all misbehavior. This could be useful for indicating where a DoS attack begins and where it ends.
- BSMs from both host device and remote threat device.
- Warnings present at time of misbehavior detection, if any.
- List of neighboring devices.
- The Coordinated Universal Time (UTC) at which the misbehavior was detected.
- Information identifying the detection method that triggered the report.
The agency seeks comment on the proposed inclusion of the above data in a misbehavior report. Specifically, we would appreciate commenters providing any potential additional data that should be included. The agency also asks commenters to provide feedback on the potential for inclusion of any personally identifiable information (PII) related to misbehavior and the potential positives and negatives of such an inclusion.
Additionally, the agency is also seeking comment on the potential inclusion of the following items in the misbehavior report:
- The average Channel Busy Percentage observed if a Denial of Service is detected
- List of vehicles (device/certificate IDs) within communication range when misbehavior is detected
- Abstracted (non-V2V related) sensor information if such sensor information is available to the device
- Averaged speed of vehicles within communication range of the reporting vehicle
(b) Misbehavior Report Generation and Transmission
A misbehavior report shall be generated as follows:
- A misbehavior report shall be created at the time a misbehavior is detected
- Misbehavior reports shall be signed and transmitted with the same credentials as those of BSMs
- A misbehavior report shall be signed by the reporting device at the time of the report creation
- The misbehavior reports shall be encrypted with the public key of the misbehavior authority and transmitted to the central authority through a secured communication channel
(c) Misbehavior Report Storage
Misbehavior reports shall be stored as follows:
- The V2V device shall allocate sufficient persistent memory storage for 1600 KB of misbehavior event reports
- Misbehavior reports shall be stored persistently in non-volatile memory to avoid report erasure during vehicle shut-down and start-up cycles
- A misbehavior report shall be stored in persistent memory for at least 20 weeks
- If the allocated misbehavior report memory capacity is to be exceeded due to a new incoming misbehavior report, the oldest report or reports shall be overwritten to allow the storage of the newest report
- If misbehavior reports are to be stored in unencrypted storage medium, the content shall be encrypted
(2) CRL Processing
- If the credentials of a locally detected misbehaving device are already on the locally stored CRL it shall not be re-reported to the central authority
(3) SCMS Security
The agency recognizes the misbehavior mechanism identifies anomalies that could indicate malfunctions or malicious activities that could adversely impact proper operation of individual devices or the system; possibly causing unsafe or unreliable operation if trusted. Misbehavior operations and subsequent device requirements ensure that the device perpetrating the misbehavior can be rendered innocuous by revoking the device's security certificates effectively making them an untrusted source to properly functioning devices. The agency is therefore proposing the following the requirement is applied to a central authority, namely the SCMS, responsible for global misbehavior and management:
- The agency requires that a central authority employ protocols that establish a disposition based on reporting from various sources to mitigate the potential for misbehavior detection to become a gateway for an easy cybersecurity threat for denial of service.
(4) Request for Comment
The agency believes the proposed misbehavior reporting requirements could help reduce the number of misbehaving devices whose messages would be accepted by the V2V network and thus help reduce the chance of false safety warnings. The agency seeks comment on the misbehavior reporting approaches describe in this section along with potential other approaches the agency should consider.
More specifically, the agency appreciates thorough explanation of any suggested alternative approaches to misbehavior reporting, as well as sufficient description of why you believe that the proposed approach is, or is not appropriate. Additionally, the agency would appreciate suggestions on how to properly and reasonably test for misbehavior in a V2V system.
(5) Potential Regulatory Text for SCMS-Based Misbehavior Detection and Reporting
The agency has included no regulatory text for SCMS-based misbehavior detection and reporting and instead has a bracked placeholder for where it would be if this were to be part of a final rule. The agency expects that regulatory text in any final rule would include:
- A provision on detecting misbehavior related to both malfunctioning sensors and physical tampering.
- A provision addressing a BSM failing any plausibility check, which would require the device to generate a misbehavior report that meets certain minimum requirements.
- A provision concerning creating and sending misbehavior reports. This provision would set requirements about what data would need to be included in a misbehavior report (which would include the information listed above). Start Printed Page 3914Further, it would include provisions on how a misbehavior report must be generated and transmitted, which would include that it would need to be created within 2 seconds after the misbehavior is detected, and thensigned,encrypted and transmitted to SCMS.
- A provision detaling how misbehavior reports would need to be stored
- A provision concerning the credentials of a locally-detected misbehaving device already on the locally-stored CRL.
- A provision concerning communicating with the SCMS.In addition, the agency would need to include additional regulatory text on test procedures including the ability to detect misbehavior and receive certificates from the SCMS.
(b) Alternative Approach—No Misbehavior Reporting
In contrast to the primary misbehavior detection proposal, the agency is seeking comment on an alternative approach to misbehavior detection where there are no requirements to report misbehavior or implement distribution of information to facilitate blocking based on misbehavior reports to an authority. Implementers would be free to include such features as reporting the detection of any misbehavior or a malfunction as optional functions. Independent of this alternative approach, the agency is proposing to require that implementers identify methods that would check the functionality, including hardware and software, of a V2V device ensuring that the device has not been altered or tampered with from intended behavior.
The agency appreciates commenter's views on this potential alternative approach including reasons why or why not this potential would be appropriate for identifying misbehaving or malicious devices participating in V2V communications. We also encourage commenters to provide any suggested alternative approaches to misbehavior reporting, as well as sufficient description of why you believe that the proposed approach is, or is not appropriate. Additionally, the agency would appreciate suggestions on how to properly and reasonably test for misbehavior in a V2V system.
5. Proposed Malfunction Indication Requirements
The agency is proposing to require that all V2V devices be equipped with a mechanism for notifying users that the device and/or its supporting equipment is not operating normally and some form of repair is necessary. The requirements proposed in this section are consistent across any potential technology employed in V2V communications. The agency is not specifying a format for the notification mechanism, as elaborated below—it can be an illuminated telltale, a message in the message center, or something else—but it must be presented in the vehicle itself for OBE or on the device itself for non-integrated aftermarket products. This proposed requirement aligns with the proposed misbehavior requirements and cost estimates, in that misbehavior detection requires devices to perform self-diagnostics and report to users a failure condition. Likewise, the cost estimates for the proposal include costs for some type of malfunction indicator and reflect what we would consider to be a “minimalist” approach.
The agency has a long history of requiring both diagnostics and malfunction indicators. FMVSSs for electronic stability control (No. 126), tire pressure monitoring systems (No. 138), and air bags (No. 208), among others, include requirements for indicating when the system is in a failure condition. In these cases, the agency believed, and therefore required, that proper maintenance to ensure system operation is vitally important to driver and passenger safety. The agency has no reason to believe any differently for V2V devices, other than potentially strengthening those beliefs based on the cooperative nature of V2V and how the benefits are a “networked good,” where one device has the potential to benefitting many others.
(b) Malfunction Indication Requirements
- Any device participating in the V2V system shall clearly indicate to their users a malfunction condition occurring in the device, its supporting equipment or the inputs used to form, transmit, and receive a basic safety message. Malfunction indication shall be provided in instances such as:
○ Device components not operating properly
○ Input sensor data not within appropriate tolerances
○ On Board memory failures
○ GPS receiver failures
○ Unable to transmit or receive basic safety messages
○ Any other failure that could prevent normal operation
- Malfunction indication shall be clearly presented to device users in the form of a lamp or message
- Owner's information shall clearly describe the malfunction indication, potential causes, and if needed, the need to have the device serviced
- The malfunction indication shall remain present until the V2V device is returned to normal operating state
- The malfunction indicator shall illuminate the malfunction indicator as part of power up initial system diagnostics to confirm the indicator is operating properly
The agency seeks comments on these proposed requirements. More specifically, the agency would like commenters to give their views on malfunction indication, the best ways to convey device malfunction to users, and why they believe this to be the case.
6. Software and Security Certificate Updates
The agency anticipates that, over time, V2V devices and the system overall will require periodic updates to address functionality, potential security, or potential privacy issues as they arise after a vehicle owner or operator takes possession of a vehicle. The agency is proposing that V2V devices allow for over-the-air (OTA) software and certificate updates and those device users be notified of any consent required for periodic device updates.
The agency believes that over-the-air devices updates will be viable and commonplace by the time a final rule to this proposal is finalized.
We anticipate this highest potential for periodic updates will come in two primary forms: Device software updates and security credential updates. In either case, the agency believes user notification and consent would be required to execute the update. The approach of this proposal is provide the basic platform to enable V2V communications where the hardware needed is the most technologically basic enabler, essentially a radio transmitter and receiver. The device complexity, intellectual property and overall V2V operation is primarily rooted in the firmware and software loaded into a V2V device's hardware. The agency Start Printed Page 3915anticipates any updates to the device hardware would be manifested by a malfunction, device failure that would be subject a recall and/or warranty provisions if the device warranty is still valid.
Over the air updating will provide significant flexibility for updates, not only to V2V devices but many vehicle-resident components, to fundamental device operation but also, following suit of smartphone devices, enable “pushing out” new applications to automotive devices. The agency believes this approach can and will best exploit the V2V communications “platform” contained in this proposal.
As discussed throughout the proposal and more specifically, the legal authority section, the agency believes V2V device users will need to consent to both software and security certificate updates. Therefore, the agency is proposing to require that devices participating in the system provide users with indication, in the form of a descriptive telltale or text message displayed in a vehicle message center that is in clear view of the driver, that device software or security certificate updates are available and that users need to consent before the update can occur. The indication and consent mechanism must reside in the vehicle or device.
The agency seeks comment on this proposed requirement for software and certificate update. Do commenters agree with the proposed approach, why or why not? Do commenters have alternative suggestions for how V2V device users can seamlessly consent, without burden, to software and/or certificate updates? More specifically, how do commenters perceive potential mechanisms for receiving notification and consenting, or not, to any potential updates. What potential implications may result from the anticipated need for updates and consent? What real-world experience do commenters have performing over the air updates for devices? Please provide any supporting information that may help the agency explore and finalize an approach.
(a) Cybersecurity Overview
Today's electronics, sensors, and computing power enable the deployment of vehicle safety technologies, such as forward-collision warning, automatic-emergency braking, and vehicle-to-vehicle technologies, which can keep drivers from crashing in the first place. NHTSA strongly believes in the need for cybersecurity, which is essential to the public acceptance of increasingly computerized vehicle systems, to the safety technology they govern, and to the realization of the safety-enhancement potential they offer.
Cybersecurity, within the context of road vehicles, is the protection of automotive electronic systems, communication networks and nodes that interface with vehicles, control algorithms, software, users, and underlying data from malicious attacks, damage, unauthorized access, or manipulation. The agency has been taking a holistic approach to vehicle cybersecurity, considering that all access points into the vehicle could potentially be compromised, and is focused on solutions to harden the vehicle's electronic architecture against potential attacks and to ensure vehicle systems take appropriate and safe actions, even when an attack may be successful.
A layered approach to vehicle cybersecurity within a risk-based framework reduces the probability of an attack's success and mitigates the ramifications of a potential unauthorized access.
NHTSA's vehicle cybersecurity approach is built upon the following principles:
- Based on the risk-based prioritized identification and protection of safety-critical vehicle control systems and personally identifiable information;
- Provides for timely detection and rapid response to vehicle cybersecurity incidents in the field;
- Designs-in methods and measures to facilitate rapid recovery from incidents when they occur, and;
- Institutionalizes methods for accelerated adoption of lessons learned across the industry through effective information sharing, such as through participation in the Auto ISAC.
Our vehicle cybersecurity research program considers all access points into the vehicle, more broadly than, but also including V2V. This approach makes a distinction between
(1) how vehicle architectures should be designed that interface with the outer world such that risks to safety-critical system functionality could be effectively mitigated; and
(2) how each unique access point could be protected such that an appropriate relationship could be established for the messages exchanged over that medium.
(b) Agency's Cybersecurity Approach To Hardening Vehicle Architectures in General
Related to hardening the vehicle architectures to be cyber-resilient agnostic of the type of communications interface, NHTSA is pursuing a best-practices approach, which is based on the National Institute for Standards Technology's (NIST) proven cybersecurity framework that includes five principal functions: Identify, Protect, Detect, Respond, and Recover.
This approach suggests that all interfaces between the vehicle electrical architecture and the external world (personal or aftermarket devices, cars, infrastructure, cloud, etc.) need to be carefully considered for risks and appropriate mitigation strategies be implemented. These include not only protection methods, but also intrusion detection techniques, rapid remediation strategies and fast adoption of new lessons learned, because we assume that all entry points into the vehicle, such as Wi-Fi, infotainment, the OBD-II port, V2V, and other points of potential access to vehicle electronics, could be potentially be or become vulnerable over time. We suggest that the industry should make cybersecurity a priority by using a systematic and ongoing process to evaluate risks. And, this process should give explicit considerations to privacy and cybersecurity risks through the entire life-cycle of the vehicle. Further, safety of vehicle occupants and other road users should be an overriding consideration when assessing risks.
We continually monitor the industry as they move towards a more cyber-aware and cyber-resilient posture and will take necessary actions to ensure that there are no unreasonable safety-risks.
(c) V2V-Specific Cybersecurity Considerations
NHTSA does not overlook the potential risks of interfacing the V2V vector with vehicle systems; however, we believe that the holistic approach we are taking in the broader sense as outlined above apply to the common characteristics of various different communications interfaces in the same manner.
In this section, we will primarily focus on the unique attributes of the V2V communications interface and present key steps that are being taken to mitigate the potential incremental risks they could pose.
Key attributes of V2V communications interface, as they relate to cybersecurity risks include the following:Start Printed Page 3916
(1) Security and privacy by design through a message authentication,
(2) Broadcast-listen protocol,
(3) Well-defined and fairly limited message structure,
(4) Communications range is limited to about 1000ft,
NHTSA's primary proposed message authentication alternative for V2V communications employs a PKI-based security. Each broadcast message is signed with cryptographic keys to facilitate a method for the receiving units to validate the authenticity and integrity of the transmitted message from its source.
Both the primary and performance-based alternatives for message authentication seek to ensure the integrity of messages between communicating units to help assert that the message has not been altered during transmission or been sent from a malicious sender. It is important to note that this approach does not necessarily validate the accuracy of the message content received.
We consider the cybersecurity risks associated with
(1) the PKI authentication method, and the infrastructure supporting it,
(2) the contents of the messages received, and
(3) the V2V communication interface as a potential channel to inject malware
(1) PKI-SCMS Cybersecurity Requirements
In Section V, the primary message authentication proposal describes the SCMS. The system described is focused on the security functions and requirements necessary to help secure the V2V communications environment. Implementations of the performance-based alternative for message authentications may also need similar compensating approaches depending on the approach taken. While the proposed primary message authentication architecture provides well-recognized security protections, we further consider the potential cybersecurity vulnerabilities and discuss how they are expected to be mitigated.
(a) On-Vehicle Security Materials (Cryptographic Information)
- The OBE will contain security materials that are critical to the operation of the V2V device, and the system as a whole. This includes long term enrollment certificates, short term pseudonym certificates, public/private keys, SCMS security policies, and misbehavior reports. All of this data, if retrieved by unauthorized parties, could allow potential “bad actors” to transmit messages that may appear valid to the general ecosystem of devices because these messages are using actual credentials given to a trusted device.
- Attempts to retrieve valid security materials could involve targeting physical OBEs. In addition to having access to OBEs on personal vehicles, OBEs on vehicles that are at their End-of-Life (EOL) decommissioning phases (such as those that can be taken from vehicles in junkyards) could also create a pathway. In the event that a vehicle with a device has met with the end of its useful life, it is foreseen that the device could have up to three years' worth of valid security certificates, assuming that it has regular communication with the SCMS.
- One method that could mitigate the risk associated with retrieval of security information through physical access to the OBE would involve hardware security against tampering such as the use of FIPS 
Level 3 hardware security module. This specification level is consistent with requiring the zeroisation of cryptographic information in the event that the device is tampered with. While this would protect against malicious attempts, it would likely result in managing the legitimate serviceability needs of the units, likely incurring additional costs for maintenance.
- The agency believes that the current environment regarding cybersecurity and protecting the public warrants a level of hardware security that goes beyond evidence of tampering to actually protecting cryptographic information in the event of a device breach with malicious intent. Therefore, the agency is proposing to require that V2V devices have a minimum of FIPS-140 Level 3 security protection. The agency also believes that at, a minimum, the following information shall be stored in FIPS-140 Level 3 storage:
All individual pseudonym certificates
RA, Intermediate CA, and PCA certificates
the RA address
system configuration files
Root CA certificate
Device Enrollment certificate
All system private keys
The System CRL
All unsent misbehavior reports
- The level of security requirements defined by FIPS-140 Level 3 is somewhat different than the historical regulatory authority approach exercised by NHTSA. NHTSA issues performance based requirements which can be found in the many safety standards issued and managed by the agency, although we can be specific in equipment requirements if it is necessary to meet a safety goal. Evaluating security protection ability does not necessarily conform to a performance requirement and compliance test paradigm followed by the agency. As such, NHTSA anticipates device compliance to be conducted by the agency through third party testing laboratories with expertise in confirming the appropriateness of device's hardware security.
- NHTSA seeks comments on this approach (FIPS-140 Level 3 requirement) and on what constitutes tampering, applicable triggers for zeroisation, and how the triggers could be implemented such that routine vehicle maintenance activities can be accomplished without undue burden on the V2V device. The agency seeks comment on the proposed FIPS-140 Level 3 device security requirements. In specific, the agency seeks comment on the FIPS and CCP security approaches briefly described in this section and the pros/cons of each, potential compliance approaches including verification schema for information that should be contained in a functioning, secure device, and views on the whether the proposed level of protection is sufficient for anticipate cybersecurity needs.
- Another approach that could address the more specific EOL OBE security exposure could be for the SCMS to establish a process and procedure by which responsible entities could notify the SCMS of end-of-life devices (entities that deal with old, junked, crashed or otherwise unusable vehicles that contain OBEs.) This would require the entity that determines the device is at its EOL be able to report to the security certificate information the SCMS would need to remove the device from the system by including the Start Printed Page 3917device's security credentials on the system “blacklist,” rendering the security information useless. This approach could pose challenges in practical application where the vehicle or device may not be operating properly. Secondly, enabling a method to obtain security information from a device could open up a potential security vulnerability that could be used by others to obtain security materials
We request comments on whether a process approach can succeed and whether there may be other means to secure the on-unit security information.
(2) Potential Regulatory Text for Physical Security for SCMS-Based Message Authentication Proposal
The agency has included no proposed regulatory text to support the cybersecurity requirements discussed in the primary proposal for message authentication based on the SCMS. However, the agency expects that regulatory text in any final would include a provision requiring that V2V devices have a minimum security protection of FIPS-140 Level 3, as described above.
NHTSA seeks comments regarding the cybersecurity needs and requirements and how regulatory language could be crafted to appropriately express the requirements in terms that industry can implement and in terms by which performance can be objectively evaluated.
(3) Performance-Based Physical Security Alternative
The agency has included no proposed regulatory text to support the cybersecurity requirements discussed for a performance-based message authentication alternative. However, the agency expects that regulatory text in any final rule would include a provision requiring that V2V devices have a minimum security protection of FIPS-140 Level 3 for storage of cryptographic certificate, key, and other sensitive data. In addition, a V2V device connected to a vehicle data bus would need to incorporate isolation measures (firewalls) to prevent the V2V module from being a conduit allowing malicious outside actors to gain access to the vehicle data bus and other vehicle modules connected to the data bus.
(4) No Physical Security Alternative
The agency has included no proposed regulatory text to support the cybersecurity requirements discussed for a no message authentication alternative. However, the agency expects that regulatory text in any final rule would include a provision requiring that a V2V device connected to a vehicle data bus would need to incorporate isolation measures (firewalls) to prevent the V2V module from being a conduit allowing malicious outside actors to gain access to the vehicle data bus and other vehicle modules connected to the data bus.
(d) SCMS Cybersecurity Considerations
For the primary message authentication proposal, the SCMS provides key services and security. Key functions of the SCMS include:
- Communications with DSRC devices to transfer of security certificates,
- CRL maintenance and communications to the vehicles.
Section III.E.3.b) explained how security certificates are obtained, when and why certificates are changed, and how additional certificates would be requested and obtained. SCMS provides this service and uses encryption methods to facilitate secure communications to protect security information in transit.
CRLs are distributed to appropriate end-points in the same manner. The credentials and message encryption protect the communication between devices and the SCMS.
The security system of the SCMS is complex and intricate; due in part to privacy protection, therefore the agency requests comments regarding the cybersecurity viability of V2V security and invites comments concerning the relationship of V2V security to the larger vehicle security universe.
(e) Cybersecurity and V2V Message Content
While the security overlay of the V2V communications establishes confidence between authentic entities, the message content indicating the vehicle's behavior is obtained from sensors (such as GPS) and vehicle data buses. It would be possible to manipulate the sources of data to the OBE, which could send a BSM message with inaccurate message content to its surrounding. In cases, the message could be constructed intelligently that could make the messages sent from that vehicle not correspond to the sending vehicle's physical behavior.
Such manipulation could result in surrounding vehicles responding with warnings to the driver early on. The misbehavior detection mechanisms set out in this proposal are designed to detect the anomaly, however it is possible that specifically crafted messages could be delivered and accepted by safety applications.
In the case of the primary misbehavior detection proposal, the misbehaving sender would also hopefully be detected and the sender added to the CRL. However, it is important to examine what could happen if the message is not detected as misbehavior and the time period before the sending vehicle is added to CRL. OEMs treat V2V as a new sensor for the vehicle and applications designed using this message would assess the safety-risks associated with this sensing mechanism being wrong. Generally, warning systems imply less severity than active control. OEMs indicate that they would take safety-conscious approach, which would be different for different applications. They further indicate that for active control, they tend not to rely on any single sensor even in modern systems and expect that to be the same when V2V becomes available to get in the mix of their sensor suite. The impact of such malicious act would be limited vehicles within the communications range of the unit (~1,000 ft).
The broader impact on GPS or timing spoofing/jamming may have similar impacts, or result in limited denial of service. Misbehavior detection is projected to help in such cases and could also help identifying and enforcing rules against jammers.
Given there has been more reports of GPS jammers being used,
we seek information and comment regarding how industry is addressing the GPS jamming issue. Are there techniques to identify when GPS jamming is occurring? If the GPS signal is being jammed or spoofed, does industry have plans to notify the driver, and what will be the context of the notification? During GPS jamming, will industry suspend operation of systems that rely on GPS information?
In addition, we solicit comment on whether our assessment of cybersecurity risks due to spoofed and potentially malicious BSM message data is reasonable. We also solicit input from OEMs and Suppliers on how they expect to handle potential single point failures associated with BSM signal contents. What risk-based criteria and process would be appropriate for V2V safety applications to help ensure the validity of the BSM message data received from other vehicles relative to vehicle-local sensor readings? If data from a vehicle's onboard sensors suggest a different outcome as compared to data from an incoming BSM message, how Start Printed Page 3918might V2V safety applications balance the trust on conflicting data? How should V2V safety applications handle a situation where incoming BSM message data is the only source of information available to make a safety decision? How does the nature of the systems' planned reaction (warning vs nature of control) impact such a decision? What new vehicle sensors may be possible in the next 15-20 years that may significantly improve such sensor fusion and decision processes?
(f) Cybersecurity and Potential Malware
One of the cybersecurity risks that needs considered is whether V2V communications could be used to insert malware to the OBE, unexpectedly change configuration, or result in unwanted behavior. Since the V2V channel will be mandated on all new cars, this medium would likely become one of the dominant wireless access points on the vehicle fleet in the field over time.
Further, it should be considered that, since the V2V protocol is based on broadcast and listen methodology, and does not establish networks between participating units the way a traditional network protocol does. Instead, communications takes place through a well-defined BSM message structure.
- It is well established that many software and hardware vulnerabilities occur at the communications interfaces of systems. Security of the interfaces must be the highest priority when developing a system. Therefore, we believe that implemented systems should provide adequate controls to prevent malformed, incomplete or erroneous messages that do not fit the specifications to pass to the OBE.
- The DARPA HACMS program has shown that formal verification can be used to mathematically prove the correctness of systems or interfaces. Formal verification uses mathematical techniques to formalize software as a mathematical proposition to be proved. While testing provides incomplete evidence of correctness, a proof guarantees correctness of the system. In an active project, we are pursuing the development of a formally verified reference parser for the V2V communication interfaces that could provide the industry guidance on one way to ensure that only expected range of BSM Part 1 and Part 2 would be accepted by the OBE. While we do not anticipate requiring the use of a formally verified parser, we expect that industry will pay attention and utilize such tools or other means to ensure that common communication interface vulnerabilities do not exist in implemented V2V units.
- NHTSA also anticipates pursuing fuzz-testing of production-level implementations of V2V hardware with and without the use of a formally verified parser. We also intend to develop a framework of test protocols and message sets that manufacturers could use to test their implementations.
- We reemphasize the importance of securing the V2V communication channel. If the V2V interface is not properly secured (whether by design or in implementation), we need to consider the possibility of a “worm” 
type malware where the malware could potentially self-replicate and propagate in an epidemic manner to other systems with the similar vulnerability (e.g. systems from the same manufacturer) that come into communications range. The potential imminent-safety impact of such malware would depend on many factors and most certainly depend of how the vehicle databus interfaces are designed. Even if the impact may not be safety-critical, this risk could potentially lead to large scale denial of service for the mandated V2V technology. The manufacturers should plan for detection and rapid remediation methods to address such issues. This need is similar for other wireless channels. For example, in the 2014 hacking of a Fiat-Chrysler vehicle,
which led to eventual recall 
of approximately 1.5 million vehicles, the researchers documented that they could have designed a vehicle worm for the cellular communication based vulnerability in that particular case.
We solicit input on whether the overall need for rapid remediation methodologies would imply different requirements for the V2V communication interfaces as opposed to others (such as cellular, Bluetooth, Wi-Fi). Further, we solicit comment that exploitation of a potential vulnerability in the V2V OBE does not immediately imply safety-critical system compromise.
The cybersecurity environment changes continually and at times rapidly. Capabilities designed into systems should take the whole lifecycle of the vehicle into account and provide for rapid response methods to potential incidents in the field. These methods could take various forms but should consider both the issue containment and practical remediation needs.
Generally, first important step is having a method to identify cybersecurity issues and share them with the broader community. We and the industry believe that the Automotive Information Sharing and Analysis Center (Auto ISAC) established in 2015 will have a major role in this respect. We anticipate that V2V related intelligence sharing through Auto-ISAC will accelerate the identification of issues and remediation actions. As part of this process, it should be foreseen that various aspects of the V2V design may need updates over the life of systems in the field, such as:
- Security certificates and protocols,
- Misbehavior detection algorithms and policies
- CRL contents and policies
- Device firmware
In the case of primary message authentication approach, the SCMS can update certificate and security protocols that are inputs to each device, but the actual software that performs the security management for different devices can and will be implemented differently by different manufacturers. Each device supplier will need to manage handling of potentially required security updates. It is likely that there will need to be coordination among the SCMS and various devices suppliers to facilitate such updates. It may be the SCMS through the Misbehavior Authority that identifies the need for an update and communicates this to suppliers so that updates can be prepared.
There are many methods by which updates can be implemented. As seen with the different kind of devices that exist today, like tablets/iPads, there are various options and issues. Automated updates to computer systems can be implemented wired or wirelessly. Some of the updates; however, require consent; that screen that asks if you agree to the terms related to the update that may go on for pages. Some methods (personally updating device firmware) require technology savvy that many consumers do not possess. Others require owners bringing their cars to dealers, which are not often followed well.
The growing trend is towards building in capabilities for remote software updates.
Start Printed Page 3919
According to a study released by IHS in September of 2015,
OEMs are going to begin implementing software updates over-the-air (OTA); similar to how smart phones are updated currently. In fact the study estimated that software-related repair might soon be able to be wirelessly installed on the vehicle without the owner ever leaving home.
Japanese OEMs pioneered navigation map updates in Japan via their telematics systems. BMW, VW, and Tesla have announced OTA procedures for updating navigation maps. In fact, both Tesla and BMW have already documented utilizing OTA updates to fix security issues onboard their vehicles.
With new vehicles having more connectivity with the Internet and other wireless media, IIHS is predicting that upwards of 160 million cars will partake of OTA updates globally by 2022. In fact many of these may already be available to cars now. XM radios can potentially be utilized to download OTA updates to vehicles and in fact are pre-installed on upwards of 70 percent of all new light vehicles. 4G services, as well as onboard Wi-Fi units are penetrating further into the vehicle fleet as well.
Given that V2V operational and security software may need to be updated securely and widely while systems are in service, it may be unreasonable to expect that non-OTA software updates may have the desired impact and effectiveness (based on experiences in non-OTA domains for recalls). As such, NHTSA is soliciting feedback on whether it should consider requiring that V2V enabled vehicles have built-in OTA capability to have critical software updates, and seeks comment on the practicability of requiring this in future vehicles. NHTSA also solicits feedback on whether vehicle owners should be given the option to decline critical security updates.
In addition, there will be situations when a security vulnerability may be known to NHTSA and manufacturers but not all V2V-equiped vehicles will have installed the patches or updates to mitigate the flaw. During this period, vehicles in the fleet may be vulnerable until the patch or update is installed. NHTSA is seeking comment on how this period of vulnerability should be managed, the time period over which updates or patches should be installed, how the number of patched and unpatched vehicles should be measured to determine patch adoption, and how to manage the situation when vehicles do not receive patches or user refuse to accept or agree to the update.
(g) Enforcement Mechanisms
The National Highway Traffic Safety Administration (NHTSA), under the U.S. Department of Transportation, is the U.S. government agency that was established to carry out safety programs under the National Traffic and Motor Vehicle Safety Act of 1966, re-codified as Title 49 U.S.C. Chapter 301, Motor Vehicle Safety (the Vehicle Safety Act). Under that authority, NHTSA issues and enforces Federal motor vehicle safety standards (FMVSS) that apply to motor vehicles and to certain items of motor vehicle equipment. Associated regulations are found in Title 49 of the Code of Federal Regulations (CFR), Parts 500-599.
The Vehicle Safety Act requires that motor vehicles and regulated items of motor vehicle equipment as originally manufactured for sale in the United States be certified to comply with all applicable FMVSS. NHTSA does not play any part of the certification process. NHTSA does not approve any motor vehicles or motor vehicle equipment as complying with applicable FMVSS. Instead, under 49 U.S.C. 30115, each vehicle manufacturer and equipment manufacturer is ultimately responsible for certifying that its vehicles and equipment comply with all applicable FMVSS.
When establishing the FMVSS, NHTSA must ensure requirements are practicable, meet the need for motor vehicle safety, and are stated in objective terms. Each FMVSS specifies the minimum performance requirements and the objective test procedures needed by the agency to determine product compliance with those requirements.
The Office of Vehicle Safety Compliance (OVSC) is the office within NHTSA's Enforcement Division that is responsible for compliance verification testing. OVSC funds independent test laboratories throughout the United States to execute the verification tests. The verification tests are not certification tests since the vehicle manufacturers are ultimately responsible for vehicle certification, but are used to verify that tested motor vehicles appear to meet the requirements of the FMVSS. OVSC utilizes the test procedures specified in each FMVSS as the basis for developing a more detailed test procedure that includes test conditions, set-ups, test equipment, step-by-step test execution, and data tables. Each funded test laboratory is required to utilize the OVSC test procedure to establish even more detailed test procedures with step-by-step approaches documented including check-off lists and data tables.
In most cases, when OVSC and a contracted test laboratory perform FMVSS tests, the test vehicle appears to meet the requirements of the applicable standard; however, in some instances, test failures are identified. When an apparent test failure is identified, the following steps will be followed by OVSC to resolve the possible noncompliance.
- The contracted test laboratory notifies OVSC of any potential test failure.
- The test laboratory verifies that the test procedure was executed exactly as required and that all laboratory test equipment utilized has up-to-date calibration information attached.
- The test laboratory provides detailed test results to OVSC for evaluation.
- The laboratory may be directed to recalibrate any critical test equipment to ensure proper operation.
- The vehicle manufacturer is notified of the test failure and the test data is shared.
- OVSC requests the manufacturer provide documentation and its basis for certification.
- The vehicle manufacturer may choose to conduct additional internal testing to gather additional data for evaluation.
- Meetings will be held as required with test laboratory and vehicle manufacturer personnel to identify test execution related problem or possible vehicle noncompliance.
- Additional verification tests on same vehicle or identical vehicle may be executed to validate test results.
- If noncompliance is identified and confirmed by vehicle manufacturer, the manufacturer is required to submit a 49 CFR part 573 report of noncompliance report within five working days after a noncompliance has been determined.
- The manufacturer will work with NHTSA to ensure a fix has been developed to correct the identified noncompliance.
- Follow-up tests may be executed to verify the fix does in fact correct the problem.
- The vehicle manufacturer will work with NHTSA to ensure no new noncomplying vehicles are sold and that the vehicles on the road are recalled to fix the confirmed noncompliance.
The above steps are not necessarily in the exact order they may occur based upon the type of test failure and because Start Printed Page 3920many of the steps are occurring simultaneously. Furthermore, the actual steps required to resolve any potential test failure will be predicated on the technical attributes of the failure and the difficulties associated with the ultimate resolution of the problem.
(h) Compliance Test Procedures
To ensure that light vehicles equipped with a V2V communications system, On Board Equipment (OBE), is interoperable and compliant with the minimum performance requirements, the regulatory text of this proposal includes static, dynamic, and simulated performance tests. These tests have the potential for evaluating the performance of the V2V Radios and verifying the accuracy of the Basic Safety Message (BSM) safety message, Part I.
Overall, we anticipate devices being tested will be instrumented with independent measurement sensors, devices, and a data acquisition system (DAS) in order to collect V2V system data. The independent measurement equipment will collect Differential Global Positioning System (DGPS) information, vehicle speed, vehicle 3-axis accelerations, vehicle yaw rate, vehicle systems status information, and radio performance data.
IV. Public Acceptance, Privacy and Security
A. Importance of Public Acceptance To Establishing the V2V System
In the Readiness Report, NHTSA extensively discussed the importance of consumer acceptance to the success of V2V, given that as a cooperative system that benefits from network effects, V2V depends on drivers' willingness to participate. V2V needs vehicles to be equipped in order to broadcast messages that other vehicles can “hear,” but in order for equipped vehicles to join the roads, consumers must be willing to recognize the benefits of a V2V system and support its adoption by the U.S. vehicle fleet via the purchase of the new, equipped vehicles, or by adding V2V capability to their existing vehicles through aftermarket devices. Thus, consumers must want V2V in order for V2V to reach its full potential. If consumers avoid the technology for some reason, it will take longer to achieve the network effect, and safety benefits will be slower to accrue.
Additionally, the courts have determined that public acceptance of a mandated technology is necessary to ensure that the mandate fulfills the requirements of the Safety Act. As discussed further in Section V.C below, if the public rejects a technology that the agency has required for new vehicles, the courts have found that the standard may neither be practicable nor meet the need for safety in the absence of public acceptance. If vehicle manufacturers literally cannot sell V2V-equipped vehicles because consumers en masse refuse to buy them, then it is possible that a court would conclude that the standard was not consistent with the Safety Act.
NHTSA must therefore consider the potential elements of a V2V requirement that may affect public acceptance, and do what we can to address them, both through carefully considering how we develop the mandate, and through consumer education to improve understanding of what the technology does and does not do. Additionally, we expect, simultaneously, that vehicle manufacturers subject to the eventual mandate will likewise work to improve public understanding of the benefits of V2V, boosting consumer acceptance overall. We also seek comment on the extent to which an if-equipped approach potentially may alleviate some consumer acceptance concerns.
B. Elements That Can Affect Public Acceptance in the V2V Context
Based on our review of the research conducted so far and the responses to the ANPRM and Readiness Report, NHTSA believes that the several elements of the V2V system discussed below may affect public acceptance.
1. False Positives
A “false positive” occurs when a warning is issued to a driver and the warning is unnecessary (or when the driver believes the warning is unnecessary), because there is no immediate safety risk that the driver has not already accounted for. False positives can startle and, if there are too many, annoy a driver, causing drivers to possibly lose confidence in the system's ability to warn them properly of danger and desire to have the warning disabled; reducing overall system benefits. If the driver does not notice immediately that a false positive is in fact false, the driver might carry out an unnecessary evasive maneuver, potentially increasing the risk of an accident.
In the SPMD, we initially saw fairly high numbers of false positive warnings for some V2V applications.
Further analysis indicated this was due largely to the fact that the safety applications under evaluation were still prototypes. Part of the goal of the SPMD was to provide vehicle manufacturers with the opportunity to gain real-world experience with V2V safety applications; providing the opportunity to improve their “tuning” to maximize safety while minimizing false positives. Driver complaints, particularly regarding IMA warnings triggered by cloverleaf highway on-ramps and elevated roads that crossed over other roadways, led manufacturers to adjust the safety applications to accommodate the these originally-unexpected “warning” conditions. The SPMD experience proved that these adjustments significantly reduced false positive warnings for this application.
At this time, NHTSA cannot account preemptively for the possibility of future false positive warnings. Given that we are only proposing today to mandate V2V transmission capability and are not yet requiring specific safety applications, we are not developing requirements for how safety applications must perform, and we recognize that doing so would be a significant undertaking. We do expect, however, that manufacturers will voluntarily develop and install safety applications once V2V communications capability is required available. As with existing advanced crash avoidance systems and as in the SPMD, we expect manufacturers to address false positive issues that arise in use in order to improve customer satisfaction. Because false positive issues with V2V-based safety applications are typically a software issue rather than a hardware issue Manufacturers may even be able to solve by deploying solutions to such problems through over-the-air software updates, rather than requiring vehicles to be brought in for adjustment. Data from the SPMD suggests that it is possible to reduce false positives in production safety applications and thus we believe it should not pose a significant public acceptance issue for V2V. Additionally, if NHTSA determines in the future that false positives in the field create an unreasonable risk to safety, NHTSA could pursue remedies for them through its enforcement authority.
If consumers fear that V2V communications will allow their movements to be “tracked,” either for government or private purposes, and that such information could be used to their detriment, they may avoid buying new cars with V2V systems installed, or attempt to disable the V2V systems in Start Printed Page 3921their own vehicles. Concerns about privacy directly implicate consumer acceptance. For this reason, in addition to NHTSA's obligation under federal privacy law to identify the privacy impacts stemming from its regulatory activities,
the Agency also must consider consumer privacy carefully in our development of V2V requirements. For example, as discussed above, SAE J2735 BSM specification contains a series of optional data elements, such as vehicle identification number (VIN), intended to be broadcast as part of the V2V transmission that enables safety applications. Because the Agency has determined that transmission of VIN and other information that directly identifies a specific vehicle or its driver or owner could create significant privacy risks for private consumers, this proposal contains performance requirements that exclude from the BSM such explicitly identifying data. The Agency also is concerned that other data elements in the BSM potentially could be used to identify specific individuals when combined over time and with data sources outside of the V2V system. For this reason, we have proposed a more general exclusion of “reasonably linkable” data elements from the BSM to minimize consumer privacy risk that could result from associating BSMs with specific individuals. We discuss our privacy risk analysis in more in detail in Sections IV.C and IV.D, and in the draft PIA published concurrent with this NPRM.
NHTSA expects manufacturers to pursue a privacy positive approach to implementing the proposed V2V requirements. In furtherance of the Fair Information Practice Principles (FIPPs), especially those of transparency and notice, we have developed a draft privacy statement that we will require manufacturers to provide to consumers, included in the regulatory text below. In order to ensure effective notice, we intend for manufacturers to provide this statement to consumers in understandable, accessible formats and at multiple easily identifiable locations and times, including but not limited to the time of sale. We seek comment from the public on the most effective time and means of providing such multi-layered notice to individuals purchasing new and used vehicles with V2V systems. We note that the industry has developed a set of voluntary privacy principles for vehicle technologies and services, which have been accepted by members of both the Alliance and Global Automakers, covering the significant majority of motor vehicle manufacturers.
We also seek comment from the public on how these principles would apply to V2V communications, as detailed in this NPRM, and the extent to which application of these voluntary minimum principles in the V2V context would provide adequate notice and transparency to consumers.
To date, vehicle technologies that have raised privacy concerns for consumers have been “opt-in,” meaning that either consumers expressly agree to the use of these technologies in their vehicles (and thereby provide explicit consent) or consumer purchase vehicles containing technologies not mandated by NHTSA (and thereby, arguably, provide implicit consent). V2V presents a somewhat different situation, as we are proposing that at least 50 percent of new vehicles will be required to have V2V devices starting in model year 2021. Since this would be a mandated technology, consumer choice will be limited to the decision of whether or not to purchase a new car (all of which eventually would contain V2V technology, if mandated). From a privacy perspective, such implicit consent is not an optimal implementation of the FIPPs principle of consumer choice. However, as discussed below in Section VI.C., the agency has determined that there are no viable alternatives to a mandate of V2V technology. In the agency's view, the absence of consumer choice is required to achieve safety in the V2V context, increasing the significance of ensuring that industry deploys V2V technology in a privacy positive, transparent manner and provides consumers with effective, multi-layered privacy notice. Consumers who are privacy-sensitive tend to feel more strongly when the government is mandating something that creates potential privacy risks to individuals, as compared to when they voluntarily choose whether to purchase and use such technology. NHTSA and vehicle manufacturers will continue to work to ensure that V2V does not create the type of privacy impacts frequently raised in comments, and will need to educate consumers about the potential privacy impacts and privacy-enhancing controls designed into the V2V system. That said, NHTSA seeks comment on the extent to which an if-equipped approach potentially may provide consumers with more of a choice to “opt in” to V2V technology—or whether, if mandated, consumers should be provided an “opt out” option for privacy reasons.
3. Hacking (Cybersecurity)
If consumers fear that V2V will allow wrongdoers to break into their vehicle's computerized systems and take control of vehicle operation, then, as with privacy concerns, they may avoid purchasing new vehicles equipped with V2V or attempt to remove already-installed V2V in their own vehicles. This fear is really a two-part concern: (1) That V2V equipment can be “hacked,” and (2) that if V2V equipment can be hacked, the consumer's safety may be at risk.
Regarding the concern that V2V equipment can be hacked, as discussed in much more detail in Section III.E.7 above, counter measures have been identified using a risk-based approach to determine the types of threats and risks to the equipment that may occur. We are proposing to require additional hardening of the on-board V2V equipment beyond normal automotive-grade specifications to help reduce the chance of physical compromise of V2V. In addition we have included alternatives for message authentication and misbehavior reporting to solicit comment regarding to further reduction of cybersecurity risk in V2V message exchange. We seek comment on what additional requirements, if any, we might consider adding to the standard to mitigate infiltration risk yet further. If commenters believe additional steps are needed, we ask that they describe the protection mechanism and/or approach as fully as possible, and also provide cost information to accomplish them—or whether, if mandated, consumers should be provided an option to disable V2V for cybersecurity reasons.
Regarding the concern that V2V equipment, if hacked, can create a safety risk, NHTSA expects manufacturers to ensure that vehicle systems take appropriate safe steps to the maximum extent possible, even when an attack may be successful.
These can include protective/preventive measures and techniques like isolation of safety-critical control systems networks or encryption and other hardware and software solutions that lower the likelihood of a successful hack and diminish the potential impact of a successful hack; real-time intrusion Start Printed Page 3922detection measures that continually monitor signatures of potential intrusions in the electronic system architecture; real-time response methods that mitigate the potential adverse effects of a successful hack, preserving to the extent possible the driver's ability to control the vehicle; and information sharing and analysis of successful hacks by affected parties, development of a fix, and dissemination of the fix to all relevant stakeholders. In July 2015, in response to NHTSA's challenge, the auto industry created an Information Sharing and Analysis Center (“ISAC”) to help the industry proactively and uniformly address cybersecurity threats, and we would expect that such a body could be a useful forum for addressing V2V-related security risks, if any. A number of auto manufacturers are also rapidly ramping up internal teams to identity and address cybersecurity risks associated with new technologies.
In March 2014, researchers from Galois, Inc. issued a white paper with specific recommendations for reducing security risk associated with V2V communications, which they stated would “automatically rule out a whole class of security vulnerabilities” at low cost with known technologies.
The recommendations were as follows:
- All legal inputs shall be specified precisely using a grammar. Inputs shall only represent data, not computation, and all data types shall be unambiguous (i.e., not machine-dependent). Maximum sizes shall be specified to help reduce denial-of-service and overflow attacks.
- Every input shall be checked to confirm that it conforms to the input specification. Interface messages shall be traceable to mission-critical functionality. Non-required messages should be rejected.
- Parsers and serializers shall be generated, not hand-written, to ensure they do not themselves introduce any security vulnerabilities. Evidence should be provided that
○ parse(serialize(m)) = m, for all messages m, and
○ parse(i) = REJECT, for all non-valid inputs i.
- Fuzz testing shall be used to demonstrate that implementations are resilient to malicious inputs.
- A standardized crypto solution such as AES-GCM shall be used to ensure confidentiality, integrity, and the impossibility of reply attacks.
DARPA staff, in discussing V2V cybersecurity issues with DOT researchers, recommended these techniques be included in any V2V requirements going. NHTSA seeks comment on whether these specific techniques should be incorporated into the proposed FMVSS requirements, and if so, how; alternatively, NHTSA seeks comment on whether these techniques should be incorporated prior to vehicle manufacturer certification with the FMVSS, and if so, how, and how NHTSA would verify their incorporation.
As discussed in more detail below in Section IV.E, a number of individual citizens commented to the ANPRM and Readiness Report that they were concerned about what they believed to be potentially negative health effects that could result from a DSRC mandate. As discussed in Section IV.E below, NHTSA has considered this issue carefully, and whether there are ways to mitigate these concerns without obviating the very real safety benefits that a V2V mandate will enable. We believe that consumer education, undertaken both by the Federal government and by vehicle manufacturers, may help to alleviate some of these concerns.
5. Research Conducted on Consumer Acceptance Issues
Working with Booz Allen Hamilton, NHTSA has conducted additional research on consumer acceptance issues since the ANPRM and Readiness Report. The objective of the research was to conduct both qualitative and quantitative research to broaden our understanding of consumers' acceptance of V2V technology and to inform future outreach and communication efforts to the public. The qualitative phase included focus groups held in Spring of 2015. Focus group participants were shown a brief video on what V2V communications are, how they work, and how they contribute to vehicle safety, and then asked to discuss a series of questions about the technology, their understanding of it and interest in it, and benefits and drawbacks. Overall, on a scale of 1 to 10, the majority of focus group participants rated their interest in V2V as a 5 or higher for the next car. However, participants also expressed concern that the technology would not be effective if it were not universally adopted, and that over-reliance on or distraction by V2V warnings could cause drivers to become less attentive and increase risk. Although most focus group participants believed that V2V would allow drivers to be tracked, few were concerned with the privacy implications of tracking.
Following the conclusion of the focus groups and analysis of their findings, a survey was developed for online quantitative testing to examine these issues further. The survey was conducted by Ipsos, under contract to BAH. The survey sought to evaluate several objectives:
- What is the degree of public acceptance of V2V?
- What proportion of people are concerned about each barrier? How much importance is attached to that concern?
- What proportion of people agree with the potential benefits of V2V? How much importance is attached to that benefit?
- How does the population differ on the above viewpoints (age, gender, urbanicity, etc.)?
- What are predictors of acceptance of V2V technology (age, gender, urbanicity, etc.)?
Over 1,500 people responded to the survey, and the sample was matched to the target population on age, gender, ethnicity, income, and region. Respondents viewed a brief informational video about V2V, and then answered 35 questions. Approximately half of respondents were interested in having V2V in their next car, with “accepters” tending to be male, older, urban, and more educated. All responses had a margin of error of ±2.5 percent
In terms of barriers or concerns, 69 percent of respondents believed that V2V would encourage other drivers to be too reliant and less attentive to the driving task, and over 50 percent expressed concern about cybersecurity and the need for enough vehicles to be equipped for the benefits to accrue. Between 30 and 40 percent expressed concern about tracking by the government or law enforcement and about the risk that they themselves could become too reliant and inattentive to driving. Only 20 percent expressed concern about health risk from electromagnetic activity. Of those concerns, however, some were deemed Start Printed Page 3923more important than others (that is, simply because respondents identified a risk, did not necessarily mean that they considered it an important risk). Respondents viewed law enforcement and government tracking as less important, but cybersecurity, other drivers' inattentiveness, and health risks as more important, when they were concerned about them.
In terms of benefits of V2V, 55 percent of respondents believed that V2V would reduce the number and severity of vehicle crashes, 53 percent believed that it would make driving more convenient and efficient, and 50 percent believed that V2V could lower insurance rates. As for barriers, respondents tended to believe that benefits for others would be somewhat greater than the benefits that they themselves would experience. Importance did not vary as much for benefits as it did for barriers.
In terms of how opinions about benefits and barriers correspond to whether a respondent wanted V2V in their next car, the survey results found that, on balance, all respondents were concerned about barriers, but “accepters” of V2V rated the benefits more highly. When asked how much they would be willing to pay for V2V, 78 percent of respondents were willing to pay less than $200.
Based on the research conducted thus far and assuming that the survey respondents are, as intended, reasonably representative of the nation as a whole, it appears that while there may be work yet for the agency and manufacturers to do in order to reassure consumers of V2V's benefits, there may not be a sufficient public acceptance problem that an FMVSS requiring V2V communications in new vehicles would face clear legal risk on that issue. NHTSA intends to continue researching approaches to consumer outreach on V2V and will work with industry and other relevant stakeholders in doing so. We seek comment on what the agency should consider in developing those approaches to best ensure the success of a future V2V system.
6. User Flexibilities for Participation in System
In the ANPRM, we sought comment on whether there were any issues relating to consumer acceptance that the agency had not yet considered, and asked how the agency should consider them for the NPRM. In response, a number of individual commenters expressed concern that they experience extreme sensitivity to electromagnetic radiation, and that therefore DSRC should not be mandated, or that if it was mandated, that the agency should allow drivers to disable it. Health issues raised in comments are covered below in Section IV.E, but the question of whether the agency should require or permit an “off switch” for V2V communications arose when commenters suggested it as a way to mitigate concerns over health effects. A handful of other individual commenters stated that the agency should allow drivers to turn off DSRC for privacy or security reasons, out of concern that DSRC transmissions could allow their movements to be tracked, or that the device could be hacked by malicious third parties to obtain personal information about the driver. A number of individual commenters raising these concerns about health or tracking suggested that they would attempt to disable V2V in their vehicles, or only purchase older vehicles without V2V.
While NHTSA had asked in the ANPRM whether commenters had thoughts regarding whether V2V-based warnings should be permitted to be modified or disabled,
in the interest of maximizing safety benefits, NHTSA had not considered allowing manufacturers to provide consumers with a mechanism to disable V2V itself, whether temporarily or permanently.
Generally, if NHTSA concludes that a vehicle system or technology provides sufficient safety benefits that it should be required as an FMVSS, NHTSA has not permitted it to be disabled. In fact, Congress expressly prohibits manufacturers, distributors, dealers, and motor vehicle repair businesses from knowingly making inoperative any part of a device or element of design installed on or in a motor vehicle in compliance with an applicable motor vehicle safety standard prescribed by NHTSA.
In some cases, however, NHTSA has established FMVSSs that permit system disablement or alteration when there is a clearly-defined safety need for doing so.
For example, FMVSS No. 126 for electronic stability control (ESC) allows manufacturers to include an “ESC Off” control that puts the system in a state where ESC does not meet the FMVSS performance requirements, as long as the system defaults to full ESC capability at the start of the next ignition cycle and illuminates a telltale in the meantime to warn the driver that ESC is not available.
NHTSA allowed the ESC Off control because we were aware that in certain driving situations, ESC activation could actually make driving less safe rather than more safe—if a driver is stuck in deep snow or sand and is trying to free their vehicle, quickly spinning wheels could cause ESC to activate when it should not. Additionally, the agency was concerned that drivers who did not have the option of disabling ESC when absolutely necessary might find their own, permanent way to disable ESC completely. Having an off switch that reverted to full functionality at the next ignition cycle at least allowed ESC to continue providing safety benefits the rest of the time. NHTSA concluded that allowing temporary disablement was better than risking the permanent loss of safety benefits.
As another example, FMVSS No. 208 for occupant crash protection allowed manufacturers to include a device up until September 1, 2012, that deactivated the right front passenger seat air bag, but only in vehicles without a second row of seating, or in vehicles where the second row of seating is smaller than a specified size.
Like the ESC Off function, the “passenger air bag off” function also requires a telltale to illuminate to warn the driver that the air bag is disabled; unlike the ESC Off function, the passenger air bag off function, if present, remains deactivated until it is reactivated by means of the deactivation device (i.e., the driver presses the button again, rather than the air bag simply reactivating at the start of the next ignition cycle).
In establishing this option, the agency noted public acceptance issues with advanced air bags, and stated that allowing on-off switches for some period after all vehicles were equipped with advanced air bags would help parents feel more confident about the system's reliability based on real-world experience.
Start Printed Page 3924
Thus, in prior instances when NHTSA has allowed drivers the option of changing or disabling the functionality of a required safety system, it has been in the interest of providing more safety. Similarly, were V2V to impose substantial new safety risks, there could be a safety reason to disable transmission and reception of messages. To the extent that consumers may wish that the agency allow a way for them to disable V2V because of concerns about privacy or cybersecurity, we reiterate our position as discussed in Sections IV.B and IV.C on privacy and Section V on security we have worked to design requirements that reduce the possibility of such threats. To the extent that consumers wish a mechanism to disable V2V devices out of concern over potential health effects, we note simply that disabling your own V2V unit would not help you avoid V2V transmissions, because other light vehicles will also be equipped with the technology, and if you have your own vehicle it is presumably for the purpose of traveling to places where other vehicles also go. Turning V2V off for this reason would forfeit the safety benefit of being “seen” by other vehicles” and “seeing” other vehicles, without providing any other benefit.
Moreover, unlike for most of the prior technologies in which NHTSA allowed drivers the option of changing or disabling the functionality of a required safety system, allowing V2V communications to be disabled would affect the safety of more drivers than just the driver who turned off their own V2V device. A cooperative system like V2V protects you by making you more “visible” to other drivers and by letting you know when they pose imminent risks to you. A driver who disables V2V on their vehicle makes their vehicle less visible to other drivers, potentially affecting their own relative safety risk and the safety risk to those around them. The safety benefits from a cooperative system could be undermined by allowing drivers to opt out. If there is no safety benefit from opting out, and doing so would undermine safety benefits both for the driver who opts out and for drivers around them, opting out may not be justified.
However, V2V is a novel technology concept in the transportation context, which differs in some ways from other technologies covered by the FMVSS. NHTSA recognizes that, as discussed elsewhere in this notice, any technology that is required to transmit and receive information on a persistent basis creates potential privacy and cybersecurity risks. NHTSA is making every effort to reduce these risks while setting requirements that would provide life-saving benefits. That said, we acknowledge that there may be circumstances when there could be a need to deactivate the V2V device on a vehicle. These may include individuals or groups with specific privacy needs, the emergence of unanticipated cybersecurity threats, or other reasons. To address these cases, NHTSA is requesting comment on possible approaches to deactivating V2V related hardware and software as and when appropriate, as well as the costs and benefits of such approaches. These could include deactivations initiated by drivers, manufacturers, or the government; with different scopes, such as vehicle-specific or broader deactivations; with different lengths, such as for a single key start or more long-lasting; and with different levels of ease, such as an accessible consumer-friendly method or one that would require mechanical expertise.
C. Consumer Privacy
NHTSA takes consumer privacy very seriously. Although collection of data by on-board systems such as Event Data Recorders and On-Board Diagnostic systems is nothing new, the connectivity proposed by the Agency will expand the data transmitted and received by cars. V2V systems will create and transmit data about driver behavior and the surrounding environment not currently available from most on-board systems. For this reason, V2V and future vehicle to infrastructure and pedestrian (V2X) technologies raise important privacy questions.
The agency is committed to regulating V2V communications in a manner that both protects individuals and promotes this important safety technology. NHTSA has worked closely with experts and our industry research partners (CAMP and the VIIC) to design and deploy a V2V system that helps protect consumer privacy. As conceived, the system will contain multiple technical, physical, and organizational controls to reduce privacy risks—including those related to vehicle tracking by individuals and government or commercial entities. As proposed, V2V messages will not contain information directly identifying a vehicle (as through VIN, license plate or registration information) or its driver or owner (as through name, address or driver's license number), or data “linkable, as practical matter,” or “reasonably linkable” to an individual. NHTSA intends for these terms to have the same meaning, specifically: Capable of being used to identify a specific person on a persistent basis without unreasonable cost or effort, either in real time or retrospectively, given available data sources. Our research to date suggests that using V2V transmissions to track the path and activities of identified drivers or owners, while possible, could be a complex undertaking and may require significant resources and effort.
The Agency has concluded that excluding “reasonably linkable” data elements from the BSM will help protect consumer privacy appropriately and meaningfully while still providing V2V systems in vehicles with sufficient information to enable crash-avoidance safety applications.
We request comment on the proposed mandate that the BSM exclude data elements “reasonably linkable” to an individual (as that term is defined above) and whether this appropriately balances consumer privacy with safety. Additionally, will exclusion from the BSM of “reasonably linkable” data elements undermine the need for a standard BSM data set in furtherance of interoperability or exclude data required for safety applications?
NHTSA, with the support of the DOT Privacy Officer and NHTSA's Office of the Chief Information Officer, conducted an interim privacy risk assessment of the V2V system prior to issuance of the Readiness Report and ANPRM. The interim assessment was intended to provide the structure and serve as a starting point for NHTSA's planned PIA, which is a more in-depth assessment of potential privacy impacts to consumer privacy that might stem from a V2V regulatory action, and of the system controls that mitigate those risks. On the basis of then available information and stated assumptions, NHTSA's interim privacy assessment identified the system's business needs, relevant system functions, areas of potential risks, and existing/other risk-mitigating technical and policy controls.
NHTSA received a significant number of comments on the issue of privacy in response to the ANPRM and Readiness Report. Generally, the privacy comments related to consumer acceptance and reflected consumer and industry concerns that the V2V system would be used by government and Start Printed Page 3925commercial entities to track the route or activities of individuals, or would be perceived by individuals to have that capability. A vast majority of the privacy comments addressed one or more of the following areas:
1. NHTSA's privacy impact assessment;
2. “privacy by design” and data privacy protections;
3. data access and privacy;
4. consumer education; and
5. Congressional or other government action related to V2V data.
Since receiving these comments, NHTSA has worked closely with privacy experts to identify and prioritize for further analysis specific areas of potential privacy impact in the V2V system. Additional privacy research, such as dynamic modeling related to location tracking and analysis of PKI best practices, is underway that will refine NHTSA's approach to mitigating potential privacy impacts stemming from the V2V system. On the basis of the PIA, comments received on the NPRM and PIA, and ongoing privacy research, agency decision-makers will be in an informed position to determine whether any residual risk (i.e., risk in the system that cannot reasonably be mitigated) is acceptable—and, in the alternative, whether functionality should be sacrificed in order to achieve an acceptable level of residual risk, and if so, what functionality.
1. NHTSA's PIA
Over a dozen organizations requested that NHTSA conduct a privacy impact assessment (PIA) of the V2V system as proposed in the NPRM. Many of these commenters noted additionally that a PIA will be critical to consumer acceptance of V2V. Several organizations requested that NHTSA take steps (in addition to conducting a PIA) to help enhance and speed consumer acceptance of V2V technologies. Comments relating to the scope of NHTSA's PIA included a request that NHTSA broaden the scope of its privacy analysis to include privacy impacts associated with vehicle to infrastructure (V2I) and vehicle to “other” (such as pedestrians) (V2X) applications, and also that NHTSA release privacy research underlying its PIA.
The Alliance of Automobile Manufacturers (Alliance) suggested that NHTSA hold public workshops with the Federal Trade Commission (FTC) to thoroughly investigate privacy issues related to the V2V system. It also recommended that NHTSA expand the scope of the PIA so that it “considers all possible uses of the envisioned transportation communications network including all potential internal and external abuses, and other challenges not solely those concerned with safety, mobility and the environment.” The Automotive Safety Council recommended that an independent third party review the PIA. Finally, the Electronic Frontier Foundation (EFF) and Privacy Rights Clearinghouse requested that NHTSA release all initial risk assessments and research on which its initial risk assessment and PIA are based, including those related to location tracking and identification capabilities. Additionally, the Alliance took the position that PIA should analyze the privacy concerns relating to the broader V2X communications infrastructure, which includes commercial venture, law enforcement, and taxation issues. The FTC requested that NHTSA take into account the Fair Information Practice Principles (FIPPs) framework in regulating the V2V system.
NHTSA agrees with commenters emphasizing the critical importance of issuing a PIA detailing the agency's analysis of the potential privacy impacts of the V2V system as proposed in the NPRM. Not only is NHTSA required by law 
to do so, but the FIPPs-based privacy-risk analysis documented in the PIA has informed NHTSA's proposal significantly, and helped to refine the privacy controls that NHTSA and its research partners designed into the V2V system to mitigate potential privacy impacts, including that related to vehicle tracking. NHTSA intends to work closely with the FTC, which is the primary federal agency with authority over consumer privacy and data security, on consumer privacy issues related to the V2V system. Such intra-governmental collaboration is likely to include coordination on the PIA and ongoing privacy research. It may also include conducting joint public meetings or workshops with stakeholders following issuance of the NPRM and PIA, which has undergone intra-governmental review. For a variety of reasons, NHTSA did not (and could not) have it reviewed by non-governmental third parties prior to publication. However, NHTSA looks forward to receiving comments on the privacy issues discussed in the NPRM and PIA from a broad range of stakeholders and other interested entities.
With regard to the scope of NHTSA's PIA, the agency wishes to emphasize that, to the extent possible in the context of a still evolving V2V ecosystem, our PIA intentionally is scoped to take into account potential internal and external threat actors and potential abuses of the V2V system—not solely those directly related to safety, mobility or environmental applications. As discussed in the PIA Summary section below, NHTSA's PIA focusses not on specific V2V system components or applications. Rather, it focuses on data transactions system-wide that could have privacy impacts, and the controls that mitigate those potential impacts. To the extent that specific V2V data transactions might be vulnerable to privacy impacts, our risk-analysis broadly considers potential threats posed by a wide range of internal and external actors, including foreign governments, commercial non-government entities, other non-governmental entities (such as research/academic actors and malicious individuals or groups). Additionally, our analysis takes into account potential privacy impacts posed by internal V2V system actors.
2. Privacy by Design and Data Privacy Protections
Many commenters requested that NHTSA deploy the V2V system in a way that ensures drivers' privacy and the security of the system. Some sought specific privacy protections, such as “total anonymity” if drivers cannot opt out of the V2V system, the protection of any PII associated with the system, and avoidance of using any PII at all. Commenters also sought end-to-end encryption of any PII, no local or remote V2V data storage, and limitations on V2V data collection, as well as technical and administrative safeguards on any V2V data collected.
Mercedes-Benz commented that the security entity envisioned to secure the V2V system, called the Security Credential Management Server (SCMS), must have security and privacy controls to protect against external threats and internal abuses. Fiat Chrysler Automobiles (FCA) expressed concern about the potential privacy impacts of the security system's design, called the certificate revocation list (CRL). The National Motorists Association emphasized safeguarding V2V messages sent via mandated V2V devices. Infineon Technologies pointed out that the unique cellular subscriber number would defeat the privacy and tracking requirement in the system, as proposed, to the extent that cellular is used as a V2V communications media. American Trucking Association requested that NHTSA protect the confidentiality of proprietary information, such as lane Start Printed Page 3926density, vehicle specifications, and trip origin and destination. The Association of Global Automakers (Global) and GM stated that V2V, as envisioned, does not pose significant risks to the privacy of individuals. By contrast, EFF stated the exact opposite, noting its concern that the V2V system as discussed in the ANPRM and Readiness Report does not protect the privacy of drivers adequately.
Based on our exploration of privacy impacts and analysis of the V2V system design to date, we respectfully disagree with the position espoused by EFF that the V2V system fails to protect driver privacy. The system contains multiple technical and organizational controls to help mitigate unreasonable privacy risks posed by external actors including those posed by SCMS insiders. V2V transmissions would exclude data directly identifying a private motor vehicle or its driver or owner and reasonably linkable to an individual via data sources outside of the V2V system or over time. V2V devices would transmit safety information in only a limited geographical range. Neither the V2V system, nor its components (including OBEs) would collect or store the contents of messages sent or received, except for a limited time to maintain awareness of nearby vehicles for safety purposes or case of device malfunction. Additionally, the system described in our proposal would be protected by a complex PKI security infrastructure designed specifically to help mitigate privacy impacts and create a secure V2V environment in which motorists who do not know one another can participate in the system without personally identifying themselves or their vehicles.
As discussed in the PIA and demonstrated by the data flows detailed in that document, the CRL discussed in the misbehavior reporting section of our primary proposal also would be designed to mitigate privacy impacts to individuals. It would contain specific information sufficient to permit V2V devices to use certificate information to recognize safety messages that should be ignored, if received. However, the CRL would not contain identifying information about specific vehicles or specific certificate numbers—nor would the information on the CRL permit third parties or SCMS insiders to identify specific vehicles or their owners or drivers.
The Agency understands that concern about whether the V2V system can or will be used by government and commercial entities to track the route or activities of individuals is critical to consumer acceptance and the viability of NHTSA's proposal. DOT is continuing to work with privacy experts to identify additional controls that might further mitigate any privacy risks (including that of tracking) in the V2V system, no matter how remote. The planned implementation by DOT of a proof of concept (PoC) security entity (discussed in Section V.B.6.e)) and related policy research will provide an operational environment in which to continue to explore the viability of additional privacy controls applicable to the V2V system, as currently envisioned and designed.
That said, as we noted in the Readiness Report, it is important to emphasize that residual risk stemming from the V2V system will never be zero due in part to the inherent complexity of the V2V system design and the diversity/large number of interacting components/entities, both technological and human. Additionally, technology changes at a rapid pace and may adversely impact system controls designed to help protect privacy in unforeseen ways. For these reasons, as is standard practice in both the public and private sectors, NHTSA has performed a PIA to identify potential areas of residual risk and resulting privacy consequences/harms that might result from its proposal. The current status of NHTSA's PIA is summarized below. The technical framework for the V2V system has gone through many iterations and adjustments during the conduct of the V2V research program, as the system has evolved to meet revised or additional needs and to incorporate the results of research. For this reason, while the current technical framework is sufficient for purposes of NHTSA's rulemaking proposal, DOT's assessment of the potential privacy impacts that could result from the V2V proposal necessarily will be an ongoing process that takes into account future adjustments to the technology and security system required to support the technology, as well as ongoing privacy research. After reviewing comments on the NPRM and PIA and working closely with the FTC and stakeholders to address privacy concerns, NHTSA will issue an updated PIA concurrent with its issuance of a V2V final rule.
3. Data Access, Data Use and Privacy
The issue of data ownership arose in the comments of Ford, Auto Care Association, and others. All of these commenters requested clarification of who owns the data generated by the V2V system. Many commenters asserted that vehicle owners should own V2V and other data generated by motor vehicles, generally. Systems Research Associates requested a specific regulation vesting ownership in vehicle owners, not manufacturers. Another commenter expressed concern about ownership of data inherent in the context of car sharing and rentals arrangements.
The inherently related concept of consumer consent also appeared in many privacy comments. Civil liberties organizations suggested that NHTSA mandate that consumers provide “active consent” in the form of express written consent before manufacturers may collect data containing personally identifiable information (PII). Manufacturers requested that NHTSA ensure transparency by requiring that consumers authorize collection of PII through either consent or contract, and that manufacturers inform vehicle owners of what information will be collected and how this information will be used. This approach to transparency is consistent with industry privacy principles adopted in 2014 by members of the Alliance and the Association of Global Automakers, entitled “Consumer Privacy Protection Principles for Vehicle Technologies and Services” (OEM Privacy Principles or Principles), discussed in prior sections. Several manufacturers and civil liberties organizations, including EPIC and EFF, suggested that these voluntary industry principles should serve as a baseline for data privacy protections in the V2V context. EPIC also suggested that NHTSA follow the White House's Consumer Privacy Bill of Rights.
NHTSA feels strongly that in the context a V2V system based on broadcast messages, the critical consumer privacy issue is not that of data ownership, but that of data access and use—ensuring that the consumer has clear, understandable and transparent notice of the makeup of the V2V message broadcast by mandated V2V equipment, who may access V2V messages emanating from a consumer's motor vehicle, and how the data in V2V messages may be collected and used. For this reason, NHTSA proposes that motor vehicle manufacturers, at a minimum, include the following standard V2V Privacy Statement (set forth below) in all owner's manuals (regardless of media) and on a publicly-accessible web location that current and future owners may search by make/model/year to obtain the data access and privacy policies applicable to their motor vehicle, including those specifically addressing V2V data and functions. We also seek the public's assistance in identifying additional formats and methods for providing this privacy statement to consumers that Start Printed Page 3927with the goal of achieving the timely and effective notice desired—notice that has increased significance in the context of a V2V mandate that effectively (and by design to achieve safety ends) limits consumer choice and consent.
4. V2V Privacy Statement
(a) V2V Messages
The National Highway Traffic Safety Administration (NHTSA) requires that your vehicle be equipped with a Vehicle-to-Vehicle (V2V) safety system. The V2V system is designed to give your vehicle a 360 degree awareness of the driving environment and warn you in the event of a pending crash, allowing you to take actions to avoid or mitigate the crash, if the manufacturer of your vehicle has installed V2V safety applications.
Your V2V system periodically broadcasts and receives from all nearby vehicles a V2V message that contains important safety information, including vehicle position, speed, and direction. V2V messages are broadcast ten times per second in only the limited geographical range (approximately 300 meters) necessary to enable V2V safety application to warn drivers of pending crash events.
To help protect driver privacy, V2V messages do not directly identify you or your vehicle (as through vehicle identification number or State motor vehicle registration), or contain data that is reasonably or, as a practical matter, linkable to you. For purposes of this statement, V2V data is “reasonably” or “as a practical matter” linkable to you if it can be used to trace V2V messages back to you personally for more than a temporary period of time (in other words, on a persistent basis) without unreasonable expense or effort, in real time or after the fact, given available data sources. Excluding reasonably linkable data from V2V messages helps protect consumer privacy, while still providing your V2V system with sufficient information to enable crash-avoidance safety applications.
(b) Collection, Storage and Use of V2V Information
Your V2V system does not collect or store V2V messages except for a limited time needed to maintain awareness of nearby vehicles for safety purposes or in case of equipment malfunction. In the event of malfunction, the V2V system collects only those messages required, and keeps that information only for long enough to assess a V2V device's misbehavior and, if a product defect seems likely, to provide defect information to your vehicle's manufacturer.
NHTSA does not regulate the collection or use of V2V communications or data beyond the specific use by motor vehicles and motor vehicle equipment for safety-related applications. That means that other individuals and entities may use specialized equipment to collect and aggregate (group together) V2V transmissions and use them for any purpose including applications such as motor vehicle and highway safety, mobility, environmental, governmental and commercial purposes. For example, States and localities may deploy roadside equipment that enables connectivity between your vehicle, roadways and non-vehicle roadway users (such as cyclists or pedestrians). These technologies may provide direct benefits such as use of V2V data to further increase your vehicle's awareness of its surroundings, work zones, first responders, accidents, cyclists and pedestrians. State and local entities (such as traffic control centers or transportation authorities) may use aggregate V2V safety messages for traffic monitoring, road maintenance, transportation research, transportation planning, truck inspection, emergency and first responder, ride-sharing, and transit maintenance purposes. Commercial entities also may use aggregate V2V messages to provide valuable services to customers, such as traffic flow management and location-based analytics, and for other purposes (some of which might impact consumer privacy in unanticipated ways). NHTSA does not regulate the collection or use of V2V data by commercial entities or other third parties.
While V2V messages do not directly identify vehicles or their drivers, or contain data reasonably linkable to you on a persistent basis, the collection, storage and use of V2V data may have residual privacy impacts on private motor vehicle owners or drivers. Consumers who want additional information about privacy in the V2V system may review NHTSA's V2V Privacy Impact Assessment, published by The U.S. Department of Transportation at http://www.transportation.gov/privacy.
If you have concerns or questions about the privacy practices of vehicle manufacturers or third party service providers or applications, please contact the Federal Trade Commission. https://www.ftc.gov.
5. Consumer Education
Many commenters emphasized the need to educate consumers about the V2V system to enhance public acceptance through a coordinated and wide-spread information campaign utilizing traditional print and television outlets and the web, including the AAA, Global, Arizona Department of Transportation, Cohda Wireless, GM, Infineon Technologies, National Motorists Association, Pennsylvania Department of Transportation, Toyota, TRW Automotive, Automotive Safety Council, and Delphi Automotive.
Comments from the Automotive Safety Council, TRW Automotive, and Delphi Automotive suggested that such education should focus on the V2V safety message, what it contains, and how any information in the BSM will be used. The National Motorists Association recommended that NHTSA educate motorists on the system's privacy protection assurances. AAA recommended educating the public on how the V2V system will benefit them, and on the privacy and security protections built into the system. Toyota suggested that NHTSA educate the public about the fact that the V2V system will not transmit or store PII. The Privacy Rights Clearinghouse suggested that NHTSA educate the public on how the V2V system works. Honda focused more on educating the public on the security designed into the V2V system.
NHTSA agrees with commenters that educating the public about this important new safety technology, and the security and privacy protections designed into the V2V system, will be critical to consumer acceptance. For this reason, as suggested by many commenters, the agency plans to work closely with the FTC, motor vehicle manufacturers, privacy advocates and other stakeholders to design a comprehensive public education strategy on the topic of privacy in the V2V system for consumers. Any claims regarding security or privacy made as part of NHTSA's public outreach will necessarily be justified by evidence based on the best scientific knowledge regarding security and privacy. Development of a consumer education strategy will likely be among the privacy-specific topics addressed in public meetings and/or workshops held by the agency after issuance of the NPRM and PIA.
6. Congressional/Other Government Action
NHTSA received comments from civil liberties groups and manufacturers that included calls on Congress to take action to protect consumer privacy in the V2V system. EFF and Privacy Rights Clearinghouse took the position that Start Printed Page 3928Federal legislation is imperative to protect driver privacy. The Alliance called on Congress to coordinate the relevant Federal agencies “to articulate a framework for privacy and security before further rulemaking proceeds” because, in its view, NHTSA alone does not have the authority to address V2V privacy and security issues. Honda and EPIC emphasized the need for ensuring that data is legally protected from third party access, and that unauthorized access is legally punishable. EPIC's comment focused on legal protections from OEM access, while Honda's comment focused on legal protections from government access.
NHTSA understands why legislation making it illegal for third parties or government agencies to collect V2V messages, or limiting those parties' retention or use of V2V messages, would be attractive to stakeholders—and the Alliance is correct in its assertion that such government action is outside the scope of the agency's regulatory authority over manufacturers of motor vehicles and motor vehicle equipment. As noted above, the introduction of V2V technology creates new privacy risks that cannot be fully mitigated. That said, in the agency's view, the V2V system is protected by sufficient security and privacy measures to mitigate unreasonable privacy risks. NHTSA seeks comment on these tentative conclusions—and on whether new legislation may be required to protect consumer privacy appropriately.
D. Summary of PIA
1. What is a PIA?
Section 522 of the Consolidated Appropriations Act, 2005 (Pub. L. 108-447) requires that Federal agencies conduct privacy impact assessments (PIAs) of proposed regulatory activities involving collections or system of information with the potential to impact individual privacy. A PIA documents the flow of information and information requirements within a system by detailing how and why information is transmitted, collected, stored and shared to: (1) ensure compliance with applicable legal, regulatory, and policy requirements regarding privacy; (2) determine the risks and effects of the proposed data transactions; and (3) examine and evaluate protections and alternative processes for handling data to mitigate potential privacy impacts. It is a practical method of providing the public with documented assurance that the agency has identified and appropriately addressed potential privacy issues resulting from its activities. A PIA also facilitates informed regulatory policy decisions by enhancing an agency's understanding of privacy impacts, and of options available for mitigating those potential impacts.
After reviewing a PIA, members of the public should have a broad understanding of any potential privacy impacts associated with a proposed regulatory action, and the technical and policy approaches taken by an agency to mitigate the resulting privacy impacts.
2. PIA Scope
The V2V system is complex and involves many different components, entities, communications networks, and data flows (within and among system components). For this reason, NHTSA opted not to analyze the potential privacy impacts in the V2V system on a component-specific basis. Rather, NHTSA focused its PIA on discrete data flows within the system, as an organic whole. NHTSA worked with privacy experts to zero in on discrete aspects of the V2V system most relevant to individual privacy for impact assessment purposes, identify and prioritize potential privacy impacts requiring further analysis (such as dynamic modeling), and validate the privacy-related requirements in NHTSA's regulatory proposal.
The V2V NPRM PIA identifies those V2V transactions involving data most relevant to individual privacy and the multiple technical, physical and policy controls designed into the V2V system to help mitigate potential privacy impacts.
To place our discussion of potential V2V privacy issues in context, NHTSA's PIA first briefly discusses several non-V2V methods of tracking a motor vehicle that currently exist.
3. Non-V2V Methods of Tracking
For comparative purposes, it is useful to consider the potential privacy impacts of the V2V system in the context of tracking mechanisms that do not involve any aspect of the V2V system (non-V2V tracking methods). These non-V2V methods of tracking inform the Agency's risk analysis because, to the extent that they may be cheaper, easier, and require less skill or access to a motor vehicle, they are relevant to our assessment of the likelihood of an individual or entity attempting to use V2V as a method of tracking. Examples of mechanisms that currently may be used to track a motor vehicle target include physical surveillance (i.e., following a car by visual observation), placement of a specialized GPS device on a motor vehicle, physical access to Onboard GPS logs, electronic toll transactions, cell phone history, vehicle-specific cell connections (e.g., OnStar), traffic surveillance cameras, electronic toll transponder tracking, and databases fed by automated license plate scanners. As compared to the potential approaches to V2V tracking discussed below, many of these non-V2V tracking methods appear may be cheaper, easier, require less (and/or no skill) under certain scenarios.
4. V2V Data Flows/Transactions With Privacy Relevance
As a starting point for the analysis that underlies this PIA, NHTSA identified and examined all data flows within the V2V system to determine which included data fields that may have privacy impacts, either alone or in combination. We identified three data flows relevant for privacy impact purposes:
- Broadcast and receipt of V2V messages (also called Basic Safety Messages (BSMs)
- Broadcast and receipt of Misbehavior Reports
- Distribution of Certificate Revocation List (CRL)
Below, we describe these three data flows and detail the technical, policy and physical controls designed into the system to mitigate potential privacy impacts in connection with each flow. We then discuss the potential privacy impacts that remain, notwithstanding existing privacy controls. These constitute potential areas of residual risk for consideration by decision-makers.
(a) Broadcast and Receipt of the Basic Safety Message (BSM)
BSMs are one of the primary building blocks for V2V communications. They provide situational awareness information to individual vehicles regarding traffic and safety. BSMs are broadcast ten times per second by a vehicle to all neighboring vehicles and are designed to warn the drivers of those vehicles of crash imminent situations.
Under NHTSA's proposal and any future adaptation of the technology, BSMs would contain information regarding a vehicle's GPS position, speed, path history, path trajectory, breaking status and other data, as detailed above in Section III.E. As discussed below, some data transactions necessitated by the security system may result in additional potential privacy impacts, some of which may be residual.Start Printed Page 3929
(b) Broadcast and Receipt of Misbehavior Messages
Under NHTSA's proposal, when a vehicle receives a BSM from a neighboring vehicle, its V2V system validates the received message and then performs a cross check to evaluate the accuracy of data in the message. For example, it might compare the message content with other received messages or with equivalent information from onboard vehicle sensors. As a result of that cross check, the vehicle's V2V system may identify certain messages as faulty or “misbehaving.” NHTSA's primary proposal for misbehavior reporting proposes that the V2V system then prepares a misbehavior report and sends it to the V2V security entity. The security entity evaluates the misbehavior report and may identify a defective V2V device. If it does, the V2V security entity will update the Certificate Revocation List (CRL) with information about the certificates assigned to the defective V2V device. The CRL is accessed by all V2V system components and vehicles on a periodic basis and contains information that warns V2V system participants not to rely on messages that come from the defective device. The security entity also might blacklist the device, in which case it will be unable to obtain additional security credentials from the security entity.
Also under our proposal, organizational and/or legal separation of information and functions within the security entity are important privacy impact-mitigating controls that are designed to prevent a single component or insider from having sufficient information to identify certificates assigned to a specific vehicle or owner. NHTSA plans to work closely with stakeholders to develop policies and procedures to institutionalize appropriate separation of data and functions within the National SCMS.
Under the second alternative for misbehavior reporting, the no misbehavior reporting proposal would not involve any additional broadcast or transmission of reports to V2V security entities. This means that no additional privacy risk would be imposed under the no misbehavior reporting alternative.
(c) Misbehavior Reports
As described above, NHTSA's primary proposal for misbehavior reporting proposes that the V2V equipment in vehicles send misbehavior reports to the V2V security entity. Such reports will include the received BSM (which appears to be faulty) and other information, such as:
- Reporter's pseudonym certificate
- Reporter's signature
- Time at which misbehavior was identified
- 3D GPS coordinates at which misbehavior was identified
- List of vehicles (device/pseudonym certificate IDs) within range at the time
- Average speed of vehicles within range at the time
- Suspicion type (warning reports, proximity plausibility, motion validation, content and message verification, denial of service)
- Supporting evidence
○ Triggering BSM(s)
○ Host vehicle BSM(s)
○ Neighboring vehicle BSM(s)
○ Neighboring devices
○ Suspected attacker
(d) Distribution of Certificate Revocation List
As explained above, by evaluating misbehavior reports, the security entity envisioned may identify misbehaving V2V devices in vehicles and place information about those devices on the CRL. The security entity then would make updated CRLs available to V2V system participants and other system parts on a periodic basis to alert OBEs to ignore BSMs coming from the defective V2V equipment. There is only one type of CRL. Current system design plans do not include placing individual security certificates on the CRL. Rather, each CRL would contain information (specifically, linkseed1, linkseed2, time period index, and LA Identifiers 1 and 2) that OBEs could use to calculate the values of the certificates in messages that should be ignored.
5. Privacy-Mitigating Controls
From the inception of the research program that would result in V2V technology over a decade ago, NHTSA has worked with its research partners, CAMP and the VIIC, to purse an integrated, privacy positive approach to the V2V system. For this reason, the V2V system described in our proposal would contain multiple layers of technical, policy and physical controls to help mitigate potential privacy impacts system-wide. Below, we discuss the privacy impact-mitigating controls that would apply to each of the three privacy-relevant data flows discussed above. In the course of this discussion, we detail some of the key privacy controls that we expect to see in a National SCMS (based on the current SCMS technical design, see Section V.B.2).
(a) Privacy Controls Applicable to the Broadcast and Receipt of the Basic Safety Message (BSM)
(1) No Directly Identifying or “Reasonably Linkable” Data in V2V Transmissions
Under our proposals, the BSM would not contain information that directly identifies a private motor vehicle (as through VIN, license plate or registration information) or its owner or driver. BSM transmissions also would exclude data “reasonably linkable” or “as a practical matter” linkable to a specific individual.
(2) Rotating Security Credentials
Another critical control would help mitigate privacy risks created by signing messages. At the time of manufacture, a vehicle's V2V equipment would receive 3 years' worth of security certificates. Once the device is initialized into the V2V security system, the security system would send to the device keys on a weekly basis that will unlock 20 certificates at a time. During the course of the week, a vehicle's V2V equipment would use the certificates on a random basis, shuffling certificates at five minute intervals. These certificates would enable a vehicle's V2V system to verify the authenticity and integrity of a received BSM or, in the alternative, identify V2V messages that should be ignored (i.e., those that the security entity has identified as coming from misbehaving V2V equipment and placed on the CRL). The shuffling and random use of certificates every five minutes also will help minimize the risk of vehicle tracking by preventing a security certificate from becoming a de facto vehicle identifier (also referred to as a “quasi-identifier”).
(3) Limited Transmission Radius
V2V equipment in vehicles would transmit safety information in a very limited geographical range, typically only to motor vehicles within a 300 meter radius of a V2V device. This limited broadcast is sufficient to enable V2V crash avoidance applications in neighboring vehicles, while limiting access by more geographically distant vehicles that cannot benefit from the safety information.
(4) No BSM Data Collection or Storage Within the V2V System
Neither V2V devices in motor vehicles, nor the V2V system as a whole would collect or store the contents of V2V messages sent or received, except for the short time period necessary for a vehicle to use messages for safety applications or in the limited case of Start Printed Page 3930device malfunction. These technical controls would help prevent in-vehicle V2V equipment or the V2V system, as a whole, from after-the-fact tracking of a vehicle's location by accessing and analyzing a vehicle's BSMs. Although specialized roadside and mobile equipment would be able to access and collect BSMs, the V2V data collected would contain no information directly identifying or reasonably linkable to a specific private vehicle or its driver or owner, because the transmission of such information would not be allowed by the V2V rule. Research is ongoing on the methods, cost and effort required to use collected BSMs in combination with other available information or over time to track a specific, targeted vehicle or driver. The Agency believes that such linkage between collected BSMs and a specific vehicle or driver is plausible, but has not yet determined whether it is practical or reasonable, given the resources or effort required. This additional research will help to ensure that our proposed V2V FMVSS incorporates all available, appropriate controls to mitigate unreasonable privacy risk related to collection of BSM transmissions by roadside or mobile sensors. We acknowledge that introduction of this technology will result in residual privacy risk that cannot be mitigated. We seek comment on these tentative conclusions.
(5) FIPS-140 Level 3 HSM
NHTSA has proposed performance requirements that include use of FIPS-140 Level 3 hardware security module (HSM) in all V2V equipment in motor vehicles. This physical computing device would safeguard and manage a vehicle's security certificates and guard against equipment tampering and bus probing. This type of secure hardware provides evidence of tampering, such as logging and alerting of tampering, and tamper resistance such as deleting keys upon tamper detection.
(6) Consumer Notice
NHTSA would require that motor vehicle manufacturers, at a minimum, include a standard V2V Privacy Statement in all owner's manuals (regardless of media) and on a publicly accessible web location that current and future owners may search by make/model/year to obtain the data access and privacy policies applicable to their motor vehicle, including those specifically addressing V2V data and functions, as detailed in Section IV.C. As discussed above, NHTSA also considering the possibility of requiring additional methods for communicating the V2V Privacy Statement to consumers and seeks comment on the most effective methods for providing such notice.
(b) Privacy Controls Applicable to Broadcast and Receipt of Misbehavior Messages
When a V2V device in a motor vehicle appears to malfunction, the V2V system would collect and store only BSMs relevant to assessing the device's performance, consistent with the need to address the root cause of the malfunction if it is, or appears to be, widespread.
(1) Encryption of Misbehavior Report
Like all security materials exchanged between V2V equipment in vehicles and a security authority, misbehavior reports would be encrypted. This would help limit but not prevent potential privacy risks that could stem from unintended or unauthorized access to data in misbehavior messages. Specifically, this would reduce the possibility that BSMs contained in misbehavior reports may provide information about the past location of a reporting vehicle (and thereby of the vehicle owner's activities and relationship between the two vehicles), or of vehicles located nearby the reporting vehicle.
(2) Functional/Data Separation Across SCMS Components
A key privacy-mitigating control applicable to this data stream is the technical design for the security entity proposed by NHTSA, which provides for functional and data separation across different organizationally and/or legally separate SCMS components. This technical control is designed to prevent individual SCMS entities or insiders from using information, including from misbehavior messages, for unauthorized purposes. The technical separation of information and functions within the security entity could be overcome only by a specific entity within the security organization (called the Misbehavior Authority or MA) after determining, based on misbehavior messages, that a vehicle's V2V equipment is malfunctioning and needs to be blacklisted (i.e., prevented from obtaining any additional security certificates). In order to do so, the MA would need to gather information from the various independent, separate parts of the security entity to identify the device to be blacklisted.
(3) Misbehavior Reports Are Stripped of Geographic Location Information
An example of information separation serving as a privacy control is evident in one particular component of the security organization—the Location Obscurer Proxy (LOP). Misbehavior messages (like other communications between a vehicle's V2V equipment and the security entity) travel through the LOP entity to get to other parts of the security organization. The LOP would strip out information from the misbehavior message that otherwise would permit other parts of the security organization (like the MA) to associate a vehicle's V2V messages with its geographic location. This technical separation of geographic information from messages transmitted between vehicle's V2V systems and the security entity is designed to prevent individual security entities or V2V security organization insiders from colluding to use BSM information inappropriately or to track individual vehicles.
(4) Separation of Security Organization Governance
The design for the V2V security entity (or SCMS) calls for the separation of some critical functions into legally distinct and independent entities that, together, make up the SCMS. This legal separation of security entity governance is designed to prevent individual entities or V2V security organization insiders from colluding to use information for unauthorized purposes such as tracking individual vehicles.
(c) Privacy Controls Applicable to Distribution of the CRL List
(1) Misbehaving V2V Equipment in a Vehicle Stops Broadcasting
It is possible that information regarding a vehicle's revoked security certificates could enable all revoked certificates to be associated with the same vehicle. This might be used to persistently identify a vehicle during the vehicles' activities. In order to mitigate this potential privacy risk, once a vehicle's V2V system determines that information about it is on the CRL and that the security organization has revoked its security certificates, it would stop broadcasting the BSM.
6. Potential Privacy Issues by Transaction Type
Based on our analysis of the privacy relevant data flows and controls discussed above, we identified five potential privacy scenarios for further research and/or consideration by the Agency. Table IV-1 below summarizes the scenarios and corresponding system transactions identified for further analysis.Start Printed Page 3931
Table IV-1—Transactions Identified for Further Analysis
|BSM Broadcast Transaction||1. Can data elements, such as location, in the BSM be combined to form a temporary or persistent vehicle identifier?|
|BSM Broadcast Transaction||2. Can data elements in the BSM be combined to identify vehicles temporarily so that different security certificates can be associated with the same vehicle during the vehicle's activities?|
|BSM Broadcast Transaction||3. Do the physical characteristics of the carrier wave (i.e., the wave's fingerprint) associated with a vehicle's BSM serve as a vehicle identifier?|
|Broadcast and Receipt of a Misbehavior Message||4. Do BSMs in misbehavior reporting provide sufficient information about the past location of the reporting or other vehicles to retrospectively track the vehicle's path?|
|Certificate Revocation List (CRL) Distribution Transaction||5. Does information regarding blacklisted vehicles' security certificates enable all vehicle security certificates to be associated with one another and thus, with the same specific vehicle?|
As noted above, based on our exploration of privacy impacts and analysis of the V2V system design to date, it is NHTSA's expectation that the multiple technical, policy and physical controls incorporated into the design of the V2V system detailed will help to mitigate privacy risks to consumers. Methods of tracking vehicles, such as surveillance and use of specialized GPS devices already exist and may be easier, less expensive, and require less skill and access than would vehicle tracking using V2V messages or other information in the V2V system in certain conditions. Nevertheless, DOT is continuing to work with privacy experts to perform dynamic modeling and explore the viability of additional controls that might further mitigate any potential impacts demonstrated in the privacy-relevant transactions identified above for further analysis. The planned implementation by DOT of a PoC security entity (SCMS) and related PKI policy research will provide an operational environment in which to continue to explore the viability of additional privacy-mitigating controls applicable to the V2V System, as currently envisioned and designed. We seek comment on whether there are other potential privacy risks stemming from the V2V systems proposed that the agency should investigate and, if so, what specific risks.
E. Health Effects
NHTSA received numerous comments from individuals in response to the ANPRM concerning the potential for V2V technology to contribute to electromagnetic hypersensitivity (“EHS”). Overall, the comments focused on how a national V2V deployment could potentially disadvantage persons that may be electro-sensitive.
In response, NHTSA engaged the DOT Volpe Center to review available literature and government agency actions regarding EHS in support of this NPRM. More specifically, NHTSA needed to learn more about the potential conditions causing EHS, actions taken by other federal agencies that have been involved in similar technology deployments or whose mission is primarily human health-focused, and any qualifying actions granted by the Americans with Disabilities Act (ADA) related to EHS among other potential externalities that may affect a potential V2V technology deployment.
According to the World Health Organization (WHO), EHS is characterized by a variety of non-specific symptoms that are attributed to exposure to electro-magnetic frequencies (“EMF”) by those reporting symptoms. The symptoms most commonly experienced include dermatological symptoms (redness, tingling, and burning sensations) as well as neurasthenic and vegetative symptoms (fatigue, tiredness, difficulty concentrating, dizziness, nausea, heart palpitation, and digestive disturbances). The collection of symptoms is not part of any recognized syndrome. Reports have indicated that EHS can be a disabling problem for the affected individual; however, EHS has no clear diagnostic criteria and it appears there is no scientific basis to link EHS symptoms to EMF exposure. Further, EHS is not a medical diagnosis, nor is it clear that it represents a single medical problem.
2. Wireless Devices and Health and Safety Concerns
The Federal Communications Commission (FCC), federal health and safety agencies such as the Environmental Protection Agency (EPA), the Food and Drug Administration (FDA), the National Institute for Occupational Safety and Health (NIOSH) and the Occupational Safety and Health Administration (OSHA) have been actively involved in monitoring and investigating issues related to radio frequency (“RF”) exposure. Federal, state, and local government agencies and other organizations have generally relied on RF exposure standards developed by expert, non-government organizations such as the Institute of Electrical and Electronics Engineers (IEEE) and the National Council on Radiation Protection and Measurements (NCRP).
Several U.S. government agencies and international organizations are working cooperatively to monitor research on the health effects of RF exposure. The World Health Organization's (WHO) International Electromagnetic Fields Project (IEFP) provides information on health risks, establishes research needs, and supports efforts to harmonize RF exposure standards. Some health and safety interest groups have interpreted certain reports to suggest that wireless device use may be linked to cancer and other illnesses, posing potentially greater risks for children than adults. While these assertions have gained increased public attention, currently no scientific evidence establishes a causal link between wireless device use and cancer or other illnesses.
3. Exposure Limits
In the U.S, IEEE has developed limits for human exposure to RF energy, and these limits have been widely influential around the world and require periodic updates. Internationally, the exposure limits for RF energy vary widely in different countries. A few countries have chosen lower limits, in part due to differences in philosophy in setting limits. IEEE and most other Start Printed Page 3932Western exposure limits are designed on the basis of identified thresholds for hazards of RF and thus are science-based. Switzerland, Italy, and a few other countries have adopted “precautionary” exposure limits for RF energy. These are not based on identified hazards, but reflect the desire to set exposure limits as low as economically and technically practical, to guard against the possibility of an as-yet unidentified hazard of RF exposure at low levels.
4. U.S. Department of Energy (DOE) Smart Grid Implementation
Many comments to the ANPRM were related to the implementation and expansion of “smart grid” or “smart meter” technology being deployed in the United States. The “smart grid” generally refers to a class of technology used to bring utility electricity delivery systems into the 21st century, using computer-based remote control and automation. These systems are made possible by two-way communication technology and computer processing that has been used for decades in other industries.
Federal legislation was enacted in both 2005 (Energy Policy Act, or “EPAct”) and 2007 (Energy Independence and Security Act, or “EISA”) that contained major provisions on demand response, smart metering, and smart grids.
The primary purpose of using smart meters and grids is to improve energy efficiency—very precise electricity usage information can be transmitted back to the utility in real-time, enabling the utility to better direct how much electricity is transmitted, and when, which in turn can improve power generation efficiency by not producing more power than necessary at a given time. According to a report prepared by the Federal Energy Regulatory Commission (FERC) in December 2014, approximately 15.3 million advanced meters were installed and operational through the Department of Energy (DOE) Smart Grid Investment Grant (SGIG) program. Ultimately, 15.5 million advanced meters are expected to be installed and operational under SGIG. All SGIG projects are expected to reach completion in 2014, with continued reporting requirements through 2016.
In the last several years, some consumers have objected to deployment of the “smart” utility meters needed for DOE's Smart Grid implementation. Smart meters transmit information via wireless technology using electromagnetic frequencies (EMF). Smart utility meters operate in the 902-928 MHz frequency band and the 2.4 GHz range, which is where the human body absorbs energy less efficiently and the Maximum Permissible Exposure (MPE) limits for RF exposure are less restrictive.
Smart utility meters in households or businesses will generally transmit data to an access point (usually on utility poles) once every four hours for about 50 milliseconds at a time. Once the smart grid is fully active, it is expected that smart utility meters will transmit more frequently than once every four hours, resulting in a higher duty cycle.
A 2011 report from the California Council on Science and Technology (CCST) showed minimum and maximum exposure levels for various sources, including a smart meter that is always on at two distances from the body. The CCST concluded that RF exposure levels for smart meters in either scenario would be less than microwave ovens and considerably less than cell phones, but more than Wi-Fi routers or FM radio/TV broadcasts.
It should also be noted that a 2011 report from the Electric Power Research Institute (EPRI) assessed exposures in front of and behind smart utility meters. It determined that the average exposure levels from smart utility meters, measured from a single meter and from an array of meters, were at levels similar to those from other devices that produce RF in the home and surrounding environment.
A typical “smart” utility meter device uses a low power one watt wireless radio to send customer energy-usage information wirelessly.
The V2V DSRC devices used for NHTSA research in the Safety Pilot activities are allowed to transmit at up to 33 dBm 
(approximately 2.0 watts of power output), as defined by FCC specifications.
The “normal” operating transmission output range for these devices is 20 dBm (or approximately 100mW) for devices operating in the allocated DSRC frequency range. For additional comparison purposes, the typical cellular phone operates at higher power output levels of 27 dBm (approximately 500 mW). Cellular phones are capped at the same maximum transmission power output of 33 dBm.
The public objections to these deployments have been based on concerns over potential health effects. Specifically, some consumers are concerned about exposure to wireless RF emissions emanating from smart meters in their homes, which has led to legal challenges for smart meter programs. Due to these objections, several state commissions authorized an “opt-out” provision for individual consumers who do not wish to have smart meters installed in their homes. In response to public perception of the technology, the Department of Energy pursued development of outreach materials citing current scientific and industry evidence that radio frequency from smart grid devices in the home is not detrimental to health. The materials are being provided to state commissions, utilities in the DOE Smart Grid Program, and other community-based organizations in effort to convey Start Printed Page 3933these messages to the end-user community.
5. Federal Agency Oversight & Responsibilities
Many consumer and industrial products use or produce some form of electromagnetic energy. Various agencies within the Federal Government have been involved in monitoring, researching, or regulating issues related to human exposure to radio frequency radiation. A summary of the federal Government's role is provided below: 
Federal Communications Commission (FCC): The FCC authorizes and licenses most RF telecommunications services, facilities, and devices used by the public, industry, and state and local governmental agencies. The FCC's exposure guidelines that V2V devices are anticipated to follow, and the ANSI/IEEE and NCRP guidelines upon which they are based, specify limits for human exposure to RF emission from hand-held RF devices in terms of specific absorption rate (SAR). Additionally, under the National Environmental Policy Act of 1969 (NEPA), the FCC has certain responsibilities to consider whether its actions will “significantly affect the quality of the human environment.” To meet its NEPA obligations, the Commission has adopted requirements for evaluating the impact of its actions (47 CFR 1.1301, et seq.). One of several environmental factors addressed by these requirements is human exposure to RF energy emitted by FCC-regulated transmitters and facilities. The FCC's rules provide a list of various Commission actions that may have a significant effect on the environment. If FCC approval to construct or operate a facility would likely result in a significant environmental effect, the applicant must submit an Environmental Assessment (EA). The EA is reviewed by FCC staff to determine whether an Environmental Impact Statement (EIS) is necessary.
National Telecommunications and Information Administration: NTIA is an agency of the U.S. Department of Commerce and is responsible for authorizing Federal Government use of the RF electromagnetic spectrum. Like the FCC, NTIA also has NEPA responsibilities and has enacted similar guidelines and processes to those of FCC to ensure compliance.
Food and Drug Administration (FDA): by authority of the Radiation Control for Health and Safety Act of 1968, the FDA's Center for Devices and Radiological Health (CDRH) develops performance standards for the emission of radiation from electronic products including: X-ray equipment, other medical devices, television sets and microwave ovens, laser products, and sunlamps. The CDRH has not adopted performance standards for other RF-emitting products. The FDA is the leading federal health agency in monitoring the latest research developments and advising other agencies with respect to the safety of RF-emitting products used by the public, such as cellular and mobile devices.
Environmental Protection Agency (EPA): EPA activities pertaining to RF safety and health are presently limited to advisory functions. EPA has chaired an Interagency Radiofrequency Working Group, which coordinates RF health-related activities among federal agencies who have regulatory responsibilities in this area.
Occupational Safety and Health Administration (OSHA): OSHA is responsible for protecting workers from exposure to hazardous chemical and physical agents. In 1971, OSHA issued a protection guide, which V2V devices are anticipated to operate within, for exposure of workers to radiation (29 CFR 1910.97). The guide covers frequencies from 10 MHz to 100GHz. The guide was later ruled to be only advisory and not mandatory.
National Institute for Occupational Safety and Health (NIOSH): NIOSH is part of the U.S. Department of Health and Human Services, Centers for Disease Control and Prevention (CDC) and conducts research and investigations into issues related to occupational exposure to chemical and physical agents. NIOSH research is focused on radio frequencies, extremely low frequencies (ELF) and static magnetic fields. CDC/NIOSH provides various guidance documents related to the focused research areas.
The Architectural and Transportation Barriers Compliance Board (Access Board): The Access Board is the federal agency devoted to the accessibility for people with disabilities. In November 1999, the Access Board issued a proposed rule to revise and update their accessibility guidelines. During the public comment period on the proposed rule, the Access Board received approximately 600 comments from individuals with multiple chemical and electromagnetic sensitivities. The Board issued a statement recognizing that people with these sensitivities may be considered disabled under the ADA if conditions perceived to be caused by these sensitivities “so severely impair the neurological, respiratory, or other functions of an individual that it substantially limits one or more of the individual's major life activities.” The Board contracted with the National Institute of Building Sciences (NIBS) to establish the Indoor Environmental Quality (IEQ) Project. The overall objectives of the IEQ project were to establish a collaborative process among a range of stakeholders to recommend practical, implementable actions to both improve access to buildings for people with EMS while also improving indoor environmental quality to create healthier buildings for the entire population. The NIBS IEQ Final Report was issued in July 2005 and provides recommendations for accommodations for people with chemical and/or electromagnetic sensitivities. The agency is unaware of any further actions by the Access Board on this issue.
Department of Defense (DOD): The DOD conducts research on the biological effects of RF energy.
6. EHS in the U.S. and Abroad
(a) Americans With Disabilities Act
The Americans with Disabilities Act (“ADA”) does not contain a lengthy list of medical conditions that constitute disabilities. Instead, the ADA provides a general definition for “disability,” which requires a showing of a having a physical or mental impairment that substantially limits one or more major Start Printed Page 3934life activities, a history or record of such an impairment, or being perceived by others as having such an impairment. Several states have enacted even more liberal policies on disability rights that afford greater potential protections than the ADA as it relates to EHS.
To date, the agency is unaware of any finding that EHS constitutes a disability. As mentioned above, the NIBS IEQ provided some recommendations, but did not conclude the EHS was in fact a disability. The agency is unaware of any further actions, either by the Access Board or some other entity, which recognized EHS as a disability or any science that would prove this.
(b) Global Recognition
Globally, some nations have heightened awareness of EHS by requiring provisions to accommodate those claiming its effects. In Sweden, for example, these provisions could include unique lighting fixtures and/or computer monitors for places of employment. The Canadian Government, The Canadian Human Rights Commission (CHRC) has also recognized EMS, describing environmental sensitivities as follows: “The term “environmental sensitivities” describes a variety of reactions to chemicals, electromagnetic radiation, and other environmental factors at exposure levels commonly tolerated by many people.” 
The CHRC published a series of recommendations for building environments in effort to reduce potential EMS conditions.
In 2009, the European Parliament urged member states to follow Sweden's example to provide people with ES protection and equal opportunities.
The agency appreciates the ANPRM comments bringing attention to V2V technology and a potential relationship to EHS. The agency takes these concerns very seriously. The literature review conducted by the agency highlighted long, and still ongoing, activities to better understand the relationship to electromagnetic radiation and the symptoms of individuals reporting electromagnetic hypersensitivity. As a Federal government agency focused on automotive safety, NHTSA acknowledges the expertise of our sister agencies such as the Federal Communications Commission and the Food and Drug Administration, among others, which have been involved with electromagnetic fields, in parallel with the pervasiveness of cellular phone deployment in the United States and globally.
The FDA currently states in response to the question, “Is there a connection between certain health problems and exposure to radiofrequency fields via cell phone use?” that “The results of most studies conducted to date indicate that there is not. In addition, attempts to replicate and confirm the few studies that did show a connection have failed.” 
However, NHTSA acknowledges that research is still ongoing and, as technology evolves; wireless communications will most likely continue to increase. The agency believes the continued efforts of the Radiofrequency Interagency Work Group (RFIAWG) 
may yield any potential future guidance for wireless device deployment and usage.
V2V devices are currently certified for use in the 5.9 GHz frequency allocation by the FCC, and the agency additionally anticipates any future certifications by the FCC will ensure that V2V devices will comply with all criteria related to RF emissions.
Currently, the FCC publishes a very helpful guide on “Wireless Devices and Health Concerns,” 
in which the Commission states, “While there is no federally developed national standard for safe levels of exposure to radiofrequency (RF) energy, many federal agencies have addressed this important issue.” The Commission acknowledges the efforts the interagency working group, its members, and their ongoing monitoring and investigating issues related to RF exposure.
V2V devices would operate at distances to humans significantly further that the distance relationship of a portable cellular phone to its operator, where the device is generally carried on a person or pressed directly to the ear. V2V devices used in the Safety Pilot operated at similar power levels to handheld cellular phones and the agency expects power levels for production deployment to remain consistent with the levels used in the Safety Pilot activities. Based on these two conditions, we believe it is reasonable to anticipate that any new guidance issued by the RFIAWG and its participating federal agencies on future cellular phone or wireless device usage could potentially be relevant to V2V devices, albeit in a somewhat diminished magnitude based on the distances the devices will operate in relation to persons.
V. Device Authorization
A. Approaches to Security Credentialing
As part of exploring different methods of authenticating V2V messages, the agency has examined in addition to the primary message authentication proposal's PKI base SCMS (single-root approach), two potential approaches to ensuring V2V messages are secure. These include a vehicle based approach, and an approach where multiple roots of confidence would be utilized. Each approach is described in the following sections.
B. Federated Security Credential Management (SCMS)
1. Overview 
For V2V communications to work effectively and as intended to facilitate crash avoidance safety applications, it is critical that users of the network have confidence in the validity of basic safety messages received from other system users—indistinct users whom they have never met and do not know personally. For this reason, DOT and its research partners have developed a sophisticated security system that allows for the creation and management of digital security credentials (referred to as “certificates”) that enable users to have confidence in one another, and the system as a whole. In fact, the security system designed to create confidence in the V2V environment is a more complex and sophisticated version of the same public key infrastructure (PKI) system that consumers and merchants use every day to verify credit card transactions at the supermarket or make on-line purchases (any time you see the “https,” for example). PKI systems also have long been used by the Federal government and corporate America, Start Printed Page 3935successfully and securely, to verify the identity of their employees for access and security purposes.
In the V2V context, system participants use digital certificates to validate the integrity of safety messages exchanged 10 times per second by V2V devices in motor vehicles. The body of each safety message is unencrypted; the sender signs the message with a digital certificate and the receiver checks to ensure that the signature is valid before relying on the message content. This PKI verification process requires an organization referred to as a Security Credential Management System (SCMS) to provide those necessary signing credentials (i.e., digital certificates) and conduct related security functions, such as identifying and removing malfunctioning V2V devices from the system. The V2V Readiness Report details the SCMS component of the V2V system.
When NHTSA issued its V2V Readiness Report, for a variety of reasons discussed therein, the agency envisioned that the SCMS would be established, funded, and governed primarily by one or more private entities—possibly a consortium of automobile and V2V device manufacturers—with limited Federal involvement. Through comments to the ANPRM, the SCMS RFI process, collaborative research with the VIIC, and additional DOT policy research, NHTSA now has developed several different potential processes by which a V2V SCMS might be stood up, owned, operated, and governed. DOT is committed to playing a central pre-deployment role in developing the organizational framework of a viable and sustainable V2V SCMS, as well as the policies and procedures required to support the SCMS—depending on comments received in response to this NPRM. In order to do so, DOT has expanded the scope of its pre-deployment policy research significantly to include several additional critical activities. DOT intends to work closely with experienced PKI and organizational management consultants and stakeholders to:
- Deploy a Proof-of-Concept SCMS based on the current design to support additional privacy and security research, as well as the certificate needs of CV Pilots funded by DOT and early industry adopters of V2V;
- Develop a model for, and then prototype a private, multi-stakeholder governance entity (on the basis of existing multi-stakeholder models) that could support deployment of an operational SCMS.
- Develop one or more public-private governance models (on the basis of existing comparable organizations) that could support deployment of an operational SCMS, given appropriate funding.
We are hopeful that this critical technical and policy research will provide government and private stakeholders with a detailed blueprint of several viable options for standing up an SCMS. One promising path that DOT actively will continue to explore is that of working with a private sector, multi-stakeholder entity that could serve as an SCMS Manager to deploy, govern, and coordinate operation of a fully-operational V2V SCMS, in which DOT would play an ongoing advisory role. However, DOT's planned research also encompasses robust exploration of other paths that could support the deployment of a sustainable, operational V2V SCMS, given appropriate public and/or private funding.
We begin this discussion with a description of the technical and organizational design of the SCMS that will support V2V, V2I, and V2X communications. We then summarize and address comments on the technical design received by NHTSA in connection with the ANPRM, V2V Readiness Report, and RFI process. As the foundation to a discussion of SCMS governance, we identify the diverse group of public and private entities and stakeholders with interests in deployment of a V2V SCMS (together described in this document as members of a “SCMS ecosystem” or “SCMS industry” requiring governance for successful deployment of V2V communications). We summarize and address governance comments received in response to the ANPRM, V2V Readiness Report, and during the RFI process. We detail DOT's planned deployment of the proof-of-concept (POC) SCMS. We then detail planned work with experts and SCMS “industry” participants to develop policies and procedures for the National SCMS, and to flesh out one or more a viable model for organization, ownership, and governance of the National SCMS. Following is a discussion of ICANN as a comparative industry example of successful, private sector multi-stakeholder governance, the evolution of which is instructive to government and private sector stakeholders in the SCMS ecosystem. Finally, we outline NHTSA's plan to issue, on the basis of this additional PKI and organizational research, a policy statement on SCMS governance on which we will seek comment from stakeholders representing all aspects of the SCMS ecosystem.
2. Technical Design
The technical design for a SCMS reflects the processes associated with certificate production, distribution, and revocation, and illustrates how these SCMS functions interact with each other and with OBE. Several functions work together in a PKI system. The V2V SCMS is based on a standard PKI design to which additional functions have been added specifically to address the identified security and privacy needs of V2V, V2I, and V2X technologies. The term “pseudonym functions” is used to refer to those functions responsible for creating the short-term certificates used by the OBE in V2V messaging. The term “pseudonym” is used to indicate that short-term certificates contain no unique or personally-identifying information about users or their vehicles, but still allow users to participate in the system, in essence allowing use of a pseudonym. The pseudonym functions differ from those functions that take part in the “bootstrap” process, described later in this section. Pseudonym functions create, manage, distribute, monitor, and revoke short-term certificates for vehicles.
These functions are listed below in alphabetical order:
- Intermediate Certificate Authority (Intermediate CA)
- Linkage Authority (LA)
- Location Obscurer Proxy (LOP)
- Misbehavior Authority (MA)
- Pseudonym Certificate Authority (PCA)
- Registration Authority (RA)
- Request Coordination
- Root Certificate Authority (Root CA)
- SCMS Manager
Distinct from the pseudonym functions that execute the short-term certificate processes are the functions that carry out the “bootstrap” process (the initialization of the device into the system). The bootstrap process establishes the initial connection between OBE and the SCMS. This process is characterized by its chief Start Printed Page 3936component, the Enrollment Certificate Authority (ECA), which is responsible for assigning an enrollment certificate to each OBE. The bootstrap functions remain separate from the pseudonym functions because of the potential connection to individual identifying information (like a VIN) during bootstrap.
The functions within the bootstrap process are listed below in alphabetical order:
- Certification Lab
- Device Configuration Manager (DCM)
- Enrollment Certificate Authority (ECA)
A brief description of each SCMS function is provided in Table V-1.
Table V-1—SCMS Components and Description
|Certification Lab||Certification Lab||Tests OBE and informs ECA that units of a particular type are eligible for enrollment certificates.|
|DCM||Device Configuration Manager||Coordinates initial distribution with OBE and enables OBE to request certificates from RA.|
|ECA||Enrollment Certificate Authority||Activates OBE and credentials users.|
|Intermediate CA||Intermediate Certificate Authority||Shields Root CA from system and provides more flexibility for trust management.|
|LA||Linkage Authority||Each pair of LAs communicates with the RA to provide linkage values necessary for certificate production, and assists the MA in misbehavior processes.|
|LOP||Location Obscurer Proxy||Obscures the locations of requesting devices (e.g., OBE requesting certificates) from other functions, such as the RA.|
|MA||Misbehavior Authority||Collects misbehavior reports from OBE and analyzes system-wide misbehavior. Coordinates with PCA and RA to produce CRL. Other activities include CRL generation, broadcast, and store; internal blacklist manager (IBLM); and global detection.|
|PCA||Pseudonym Certificate Authority||Generates and signs short-lived certificates.|
|RA||Registration Authority||Coordinates certificate production with other functions; sends certificates to OBE (during full deployment).|
|Request Coordination||Request Coordination||Coordinates certificate requests from OBE to RA.|
|Root CA||Root Certificate Authority||Provides system-wide confidence through CME certificates issued to all CMEs; represents the basis of confidence in the system.|
|SCMS Manager||Security Credentials Management System Manager||Defines and oversees standards and practices for the SCMS, related to both technical and policy issues.|
The technical design of the SCMS is focused on communications and activities of the various PKI functions. Among other fundamental principles, the technical design for the system incorporates a “privacy by design” approach that separates information and organizational functions in order to mitigate potential risks to consumer privacy. The model depicted in Figure V-1 below illustrates one way these functions could be grouped into legal/administrative organizations within the larger SCMS “industry,” while still protecting consumer privacy appropriately and ensuring secure, efficient communications.
Start Printed Page 3937
Blue boxes in the diagram represent Certificate Management Entities (CMEs), or groupings of SCMS functions. Functions carried out within the CMEs are represented by the white boxes. For purposes of this illustrative model, these groupings clarify those functions that may be owned by multiple organizations, versus those that may be best handled in a more centralized manner. However, as noted in the V2V Readiness Report, ultimately, the decision as to which SCMS functions may be perform by a single entity and whether central and non-central functions may be combined are matters of governance defined by the system's Certificate Policy. For this reason, if this PKI technical design for the SCMS is implemented, the final decision on which organizations can be owners/operators and how scope and responsibility will be divided among the CMEs will likely be a central policy issue determined jointly by NHTSA and the entity that takes the lead in governing and coordinating operation of the V2V SCMS.
3. Independent Evaluation of SCMS Technical Design
The design of the Security Credential Management System has gone through many iterations and adjustments throughout V2V research program as the system has evolved to meet revised or additional needs. Additionally, evolutionary changes have occurred as a result of implementation and operation in support of the USDOT's Safety Pilot Model Deployment.
To better understand maturity and robustness of the SCMS, the USDOT retained the MITRE Corporation to conduct an independent evaluation and risk assessment of both security and privacy design features of the SCMS. This work was used to inform continuing refinements and provide USDOT with a basis for future policy and technical decisions related to deployment.
MITRE was directed to conduct: (1) An independent and comprehensive evaluation and risk assessment of the July 2013 SCMS design for a V2V connected vehicle environment; and (2) a technical analysis of the potential privacy risks of the entire V2V system that includes security but also focuses on the operation of V2V communications in support of crash avoidance safety applications.
The independent evaluation by MITRE identified security requirements needed to support secure V2V communications, and revisited threats and risks in relation to the design and how the identified requirements addressed the potential risks. The results of the SCMS design evaluation are detailed in Final Requirements Report, September 11, 2015, Report Number: FHWA-JPO-15-235, and Final Design Analysis Report, September 18, 2015, Report No: FHWA-JPO-15-237.
The MITRE evaluation was based on the previous 6 years of research that investigated core issues related to: Securing DSRC communications; privacy implications; achieving interoperability; governance and organizational structure; and identifying and addressing communication threats and risks. The Government provided reports associated with these studies to the MITRE Corporation as a basis to conduct their evaluation and identify the minimum requirements of the SCMS that would support the three primary components of the system that are:
1. V2V devices that support DSRC messages broadcast to and received from other devices; and the ability to send/receive messages to/from the Security Certificate Management System for digital security credentials that provide the means of message authentication;
2. A Security Certificate Management System (SCMS) which is the security organization that issues, distributes, and revokes digital security credentials. The Start Printed Page 3938SCMS is comprised of a number of entities and functions. It is also designed to detect and remove misbehaving devices; and
3. A communications network that facilitates two-way encrypted communications between an SCMS and a DSRC device (to include both vehicles and roadside units).
The MITRE evaluation focused on a revised SCMS technical design that benefited and evolved from knowledge gained during operation of a technical prototype implemented as part of the Safety Pilot Model Deployment. This prototype implementation exercised initial technical functionality needed to produce and manage security certificate material for the deployed devices, and, there was a rudimentary technical organization and management structure. This early SCMS prototype provided technical data related to PKI architecture and functions, and there were new insights gained regarding the over-the-air transmission of security materials and use of alternate communication media that include DSRC and cellular.
Prior to the MITRE evaluation were years of research conducted to understand and develop the SCMS design. The first forma research was conducted in 2010. CAMP commissioned 5 leading communication/internet security entities to assess the security needs and identify a security approach for DSRC communications. Security Innovations, Escrypt, Telcordia Technologies Carnegie Mellon University, University of Illinois at Urbana-Champaign, and General Motors India Science Lab investigated aspects of the system and collaborated on recommendations. Security Innovations and Escrypt conducted a risk analysis and identified initial risks related to broadcast communications among vehicles and devices. These risks included denial of service attacks, Sybil attacks, altered messages, replay of messages, and compromised nodes. The risks were rated and mitigation techniques identified. The risk analysis was combined with investigations by: Telcordia Technologies (design and analysis of applicable and scalable PKI systems); Carnegie Mellon and University of Illinois at Urbana-Champaign (adaptations to address privacy); and General Motors India Lab (misbehavior detection solutions). The overall recommendation was a PKI based system with frequently changing certificates.
Two years later after preliminary work was done on the SCMS design, USDOT and CAMP conducted a risk assessment based on the NIST 800-30 publication, Guide for Conducting Risk Assessments. Using the NIST framework, attackers and attack scenarios were identified. Identified attackers included, for example, a clever outsider and a well-funded foreign hostile organization. Attack scenarios included local and widespread Sybil attacks, Root Compromise, Intermediate Certificate Authority Compromise, Registration Authority Compromise, False Misbehavior Report, False Certificate Requests, and Trust Management Compromise. For various attack scenarios risk was estimated based on likelihood and impact. The estimates were based on a modified NIST risk matrix given the NIST matrix did not rate any scenario as “high”. The risk assessment identified Root Compromise, Intermediate Certificate Authority Compromise, Registration Authority Compromise, and Trust Management Compromise to have high risk even after possible mitigation techniques were considered. This work informed the next stage of SCMS design refinement which included (among other refinements) an objective of finding new innovative techniques to move high risks to medium risks, and medium risks to low risks.
An updated high level SCMS design was completed July 2014 and documented via 4 separate but connected reports that included: (1) Study 1, Security Credential Management System, Final Report, July 2014; (2) Vehicle Safety Communications Security Studies Final Report, July 2014; (3) Study 3 Final Report, Definition of Communication Protocols Between SCMS Components, July 2014; and, (4) Phase 2 Final Report Volume 3: Security Research for Misbehavior Detection, Nov 2014.
These reports formed the base of the information available to MITRE regarding the latest design of the SCMS.
Other reports provided to MITRE included past research findings concerning interoperability, initial communications security needs, and SCMS organizational analysis.
MITRE also had access the standards referenced in the reports that included SAEJ2735, IEEE 1609, and the latest input to SAEJ2945 that was being developed during the MITRE evaluation.
MITRE used the information described above to identify the minimum or essential requirements needed for a SCMS design to support the three primary components identified above (Final Requirements Report—September 11, 2015, Report Number: FHWA-JPO-15-235), and an assessment of how the latest SCMS design aligns with these minimum requirements (Final Design Analysis Report—September 18, 2015, Report No: FHWA-JPO-15-237). The Requirements Report also includes a risk assessment where MITRE reviewed past risk assessments and identified threats, threat actors, attacks, vulnerability, consequence, likelihood, impact severity, and risk in relation to the minimum requirements and latest design information base on the NIST 800-30, Guide for Conducting Risk Assessments.
The risk assessment assessed a number of possible threats to the system, some described by the CAMP reports, others identified by the MITRE team. Of the twenty-one threats identified, MITRE concluded that fourteen may be mitigated by a system design that conforms to the minimum requirements, but for seven of the threats, no system design requirements seemed to apply.
In some cases, threats may be mitigated by additional system design features that perform to the minimum requirements. For other threats, no system requirements are listed. These include threats that involve compromises of or unauthorized access to SCMS or OEM system components or databases. For these, mitigation will depend not on system technical design but rather on implementation of security policies and operational practices that would be part of the SCMS operational governance function. Further, MITRE noted that such Governance functions and policies may be captured in documents such as a Certificate Policy and the Certificate Practice Statement. These documents and other governance policies and protocols will be developed as part of the SCMS PoC operations project that will support V2X deployment projects as discussed in Section V.B.6.e).
The MITRE Final Design Analysis report evaluates the SCMS design (as documented in the above listed Reports from CAMP) against a list of derived minimum requirements from the Final Requirements Report.
MITRE noted that the design of the SCMS has several innovative elements that deserve further development and analysis in future design revisions and system operational implementations. The list below identifies areas Start Printed Page 3939recommended by MITRE for further development:
- Required cyber-resiliency capabilities, such as designs for continuous monitoring for proper operation, anomaly detection functions, and systematic software reset of installed software components.
- Misbehavior Authority (MA) design. The MA constitutes a critical single point of failure as conceived. Additionally, it presents enticing points for adversary compromise against key system objectives surrounding trustworthiness, misbehavior handling, and acceptance.
- Design of capabilities that would enable secure updating of on board equipment (OBE), Security Credential Management System (SCMS), and other component software, especially given the complexity and lifetime of the system and its components.
- Completion and clarification of the specifications of the operation and reporting functions around misbehavior, blacklist, revocation, and of the data elements maintained.
- Evaluation of the reduction of risks in privacy protection with the pseudonym certificate (PC) design instead of other, less complex, yet suitable privacy sensitive designs.
The above areas will be addressed by USDOT and its industry partners as the SCMS design continues to be refined, and as part of the implementation and operation of the first-ever fully representative SCMS proof of concept (PoC).
Further, even though it is not yet clear whether the SCMS should be designated as a “critical national infrastructure”, once the SCMS Proof-of-Concept becomes operational, USDOT intends to apply the NIST Framework for Improving Critical Infrastructure Cybersecurity, (currently, Version 1.0, February 12, 2014). Much of the guidance provided in The Framework for Improving Critical Infrastructure Cybersecurity is directed at organizational practices to identify cybersecurity risks; protect against threats and detect cybersecurity events; and respond to and recover from cybersecurity breaches. As the SCMS PoC organizational design and governance policies mature and are actually being implemented, then USDOT will be able to apply the NIST Framework to help identify and mitigate residual risks.
In should be noted that USDOT (and MITRE) were precluded from applying the NIST Framework for Improving Critical Infrastructure Cybersecurity because the design of the SCMS was only conceptual (not yet implemented) and detailed organizational designs, governance structures, and operational policies and procedures remained to be completed and implemented. However, the risk assessment performed by MITRE did follow the basic process of identifying the state of the current system and developing a target state of cybersecurity to obtain through refinement and additions to technical, operational and governance aspects of the system. Examples include the MITRE risk assessment, the investigation regarding the role, functions, and governance responsibilities of an SCMS manager, and the analysis and evaluation of cybersecurity protection needs that moved the protection requirement from FIPS-140 Level 2 to Level 3. The SCMS design continues to mature to address risks such as Root Compromise 
and software updates. Continued refinement is also evident through the “SCMS Proof-of-Concept End-Entity Requirements and Specifications Supporting SCMS, Software Release Version 1.1, being used by Connected Vehicle Pilots as they prepare to connect to the SCMS PoC for security.
Further, it should be understood that the SCMS PoC is being implemented at this time by USDOT to serve USDOT sponsored demonstrations and early deployments—and to allow for a better understanding both technically and operationally of how the SCMS may be deployed at a national level. To this extent, the designs, methods, policies and procedures implemented to ensure secure communications, manage privacy risks, and address cybersecurity threats will need to be accepted and implemented by the private entities that choose to establish and operate a National SCMS.
We welcome comment concerning: The cybersecurity risks associated with the SCMS; the analysis methods used to date to assess risk; and what framework/assessment methods should be used during SCMS PoC implementation and operation; and any other information regarding possible threats and risk that have not yet be identified.
4. SCMS RFI Comments and Agency Responses
As discussed in Section II.F, NHTSA issued a Request for Information (RFI) 
regarding a potential Security Credential Management System (SCMS) that could support the National deployment of a secure V2V communication system.
The purposes of the RFI were to help the agency: (1) Become aware of private entities that may have an interest in exploring the possibility of developing and/or operating components of a V2V SCMS; (2) Receive responses to the questions posed about the establishment of an SCMS provided in the last section of the RFI; and (3) Obtain feedback, expressions of interest, and comments from all interested public, private, and academic entities on any aspect of the SCMS.
NHTSA received twenty-one responses to the RFI with approximately eleven of the responses indicating an interest in running aspects of, or the entire, SCMS. The respondents included vehicle manufacturers, software component developers and suppliers, cryptography experts, certificate management entities, satellite and cellular service providers, and academia.
Deployment of a V2V communications system, and of an SCMS to support confidence in V2V communications, are unprecedented activities. For this reason, the agency believed it was appropriate to meet with a subset of respondents, the eleven expressing interest in operating aspects of the SCMS or the SCMS as a whole, to ensure there was a shared understanding of respondents' comments, potential role in an SCMS, and the agency's position on a possible SCMS creation and implementation. The agency was able to meet with ten of the eleven respondents that had indicated interest in operating aspects of a potential SCMS. One respondent, Verizon, was not able to meet with the agency. The meetings took place between January and March of 2015 at DOT headquarters either in person or via teleconference.
Overall, the meeting discussions were very informative and the agency greatly appreciated the time and effort the respondents expended following-up their RFI responses. In general, based on the RFI comments and the discussions with respondents, the team identified the following key themes concerning various aspects of the SCMS.
- Government must play a significate role in the establishment and management of the SCMS.
- Business opportunities are seen at the CME and Security services levels.Start Printed Page 3940
- Security system entities understand the relationship of the design to privacy, with some indicating they may be able to find some efficiency as they develop their systems.
- One respondent indicated that the design sets a new paradigm that other regions may adopt in the future.
- An SCMS Board of Directors needs to be initialized by the Federal Government—specifically citing the existing ICANN Model,
charged with managing the world-wide-web domain and server naming allocation and standard, as an example framework that could transcend to V2V.
- Establishment of the SCMS Manager would require capital/initial funding.
- One entity discussed being the SCMS Manager.
- One entity indicated they would build and operate the entire SCMS system but would need another entity to be the SCMS Manager.
- Little information provided about potential financial models.
- Possible revenue sources included: CME license fees, certificate subscription fees, yearly service fees.
- To move forward with development/deployment, all indicated they need more information regarding the Government role, the SCMS Manager, and details about the security design.
- Liability was a major concern, with a strong interest from all participants in some form of Federal indemnification.
(a) SCMS RFI Comments
The University of Michigan's Transportation Research Institute (UMTRI) met with representatives from the NHTSA V2V NRPM Team to discuss their SCMS RFI response. UMTRI's response provided views regarding privacy, governance, potential SCMS component separation and linkage. UMTRI's RFI response indicated other parties may be better suited to respond on specific governance organizational aspects but supported a public-private partnership model for overall governance, a potential model discussed in the V2V Readiness Report. UMTRI went one step further by offering the suggestion of an additional “public-private-academic” model that could potentially benefit from an academic partner's fundamentally neutral stance, little commercial interests and direct access to significant research resources. More specifically, UMTRI expressed interest in participating in the SCMS Manager and potentially being “a proper candidate” for operating the two Linkage Authorities identified in the current system design. UMTRI indicated their regular work on classified projects, existing infrastructure, and their experience “running highly privacy sensitive computer systems such as the University of Michigan Health System support their interest in operating the Linkage Authorities.”
UMTRI indicated other parties may be better suited to provide a response regarding financial sustainability. In our meeting, however, UMTRI indicated they could possibly pose the SCMS financial sustainability proposition to their MBA students as a potential project.
When discussing potential SCMS operational and policy standards, UMTRI indicated support for NHTSA's approach that SCMS components like the CME should be legally distinct. Support for keeping SCMS components legally separate is rooted in the need to ensure privacy and based on the key notions that firewalls within a single legal entity might not be sufficient to ensure privacy, different legal organizations will most likely protect a data center with a differing technologies, and that distinct legal organizations inhibit the possibility of a single point of entry into multiple systems.
UMTRI suggested two types of operational policies, Type 1 for applications that are under governance of SCMS Manager (e.g., V2V safety applications) and Type 2 for applications that are not under the governance of SCMS Manager but are part of the V2X application portfolio (e.g., mobility applications provided by third party providers).
(2) Certified Security Solutions, Inc.
Certified Security Solutions, Inc. (CSS) represented the exposure to new potential stakeholders, suppliers, and services V2V is bringing to NHTSA. CSS supplies security solutions such as security certificate management systems and managed public-key infrastructures (PKI). CSS also provides digital security consulting services related to PKI and identity and access management. Historically, the agency has not interacted with suppliers such as CSS in the course of regulating vehicle manufacturers and, similarly, CSS has been involved with industries far removed from the auto industry, such as supporting digital certificates for surgical devices like heart pacemakers.
CSS indicated interest in three areas of the SCMS: (1) Participation in an advisory board regarding the policy, specifications, and requirements of the SCMS, V2V initiative, and its components, (2) creating components and solutions, such as the Registration Authority or Device Configuration Manager, and (3) creating software and/or managed service offerings for operations and oversight such as “dashboards” used for monitoring system performance.
CSS's response to the RFI centered on the first question related to governance. CSS foresees a large and diverse array of participants involved in the operation of a National SCMS deployment. As such, CSS indicated examples of “self-governance” advisory boards that have, “proven to be relatively effective in improving the interoperability and overall security of their respective areas.” In their view, CSS suggested that this sort of overall model “makes the most sense when considering the magnitude and importance of an initiative such as the SCMS.” These examples included:
- The certification authorities (CA)/Browser forum (https://cabforum.org), comprised of CA and web browser vendors with a focus on defining a coordinated set of guidelines to improve browser and SSL security.
- The Internet Engineering Task Force (IETF) (www.ietf.org) and its collection of specific Working Groups.
- The Industrial Internet Consortium (www.iiconsortium.org), an industry-driven working group aimed at solving the challenges posed by large-scale machine-to-machine (M2M) communication.
The agency's meeting with CSS yielded additional details on their written response along with ideas for potential approaches to a National SCMS deployment. At the highest level, CSS indicated a potential SCMS advisory board would be responsible to define the appropriate certificate policy standards to ensure consistent and successful implementations that will be required for the anticipated multiple CAs deployed across multiple systems.
CSS indicated that utilizing multiple root CAs may benefit from redundancy versus a single root CA, and also brought forth the notion of “bridged” root CAs that could be cross-signed to allow different vehicle or device manufacturers to “trust” each other while maintaining their own “root of trust,” enhancing confidence in message exchanges.
SCMS financial sustainability discussions were limited to existing approaches for certificate management services, where per certificate fees could potentially be avoidable.Start Printed Page 3941
(3) Trustpoint Innovation Technologies, Ltd.
Representatives from Trustpoint Innovation Technologies met with the V2V NPRM Team to discuss their submission to the RFI response. Trustpoint was founded in 2012 by Dr. Scott Vanstone and Sherry Shannon. Mr. Vanstone was also a co-founder of Certicom, whom also provided a response the SCMS RFI, which was acquired by BlackBerry in 2009.
Trustpoint has been involved with the SCMS and security design research conducted with the agency's research partner, CAMP. Trustpoint's response to the RFI focused on their interest in helping to develop deployment-ready SCMS components such as the Pseudonym CA, Registration Authority, Linkage Authority, Enrollment CA, Intermediate CA, and Root CA.
Trustpoint indicated that significant investment and development in software and testing will be necessary to deploy a National SCMS. This is based on their belief the PKI approach used for SCMS research will need to be extended and extensively proven for a production system, based on the need for a new software stack 
built around new cryptography and protocols. Trustpoint is interested in being part of a consortium to deploy production SCMS components.
When meeting with the agency, Trustpoint expanded on their views of a National SCMS deployment. The key discussion points included cryptography approaches, attack vectors, participation in a consortium, and thoughts on production deployment that includes clear policies and procedures, and thoughts on device level security. In addition, Trustpoint reviewed the cost model the agency provided with the ANPRM and V2V Readiness Report.
Trustpoint discussed how Elliptic Curve Cryptography (ECC) is, in their opinion, the only feasible security solution for resource-constrained environments where processing power, power consumption, storage space, and bandwidth are limited. In comparison to RSA,
an early wide-spread remote device security mechanism, ECC is much more compact yet provides a higher level of security. Trustpoint indicated that 500 bits of ECC information is equivalent to nearly 1500 bits of RSA cryptographic information.
Trustpoint supported the development of a “test bed” for components that could operate in a National, deployed system. Successful deployment and verified operation in the test bed could be considered “certified for deployment.” Components certified in the test bed would support an “off-the-shelf” software component approach that, for example, would yield Registration Authorities for each manufacturer. Trustpoint stressed the need to have standardized components for consistent system interaction while allowing each OEM to manage their vehicle fleets individually versus a central management approach. The SCMS Proof of Concept project currently under development by the agency and CAMP, to support connected vehicle test beds that will be deployed regionally along with expansion of the Safety Pilot Model Deployment environment more broadly throughout southeastern Michigan, could potentially serve as a test bed for broader, National system deployment. Trustpoint suggested, however, that additional definition and implementation will be needed in the areas of operation, management, and auditing for a successful National SCMS deployment.
Trustpoint suggested the cost model provided by the agency and used in the V2V Readiness Report cost calculations needed some adjustment in the areas of bandwidth, hardware security module, and software development costs. More specifically, Trustpoint indicated replication for hardware security would be needed for redundancy and continuous, uninterrupted system operation. Trustpoint estimates the annual issuance of 36 million certificates will have additional bandwidth needs beyond that estimated in the cost model. Finally, Trustpoint believed the software development cost used in the cost model was substantially underestimated.
(4) DURA Automotive Systems, LLC
Dura Automotive Systems, LLC is a Tier 1 supplier to the automotive industry supplying structural body systems, mechatronic control systems, and exterior systems including window systems and exterior trim. Dura responded to the SCMS RFI with a vision of how the SCMS Manager could be formed, implemented and sustained. Dura indicated they would like to fulfill the role of developing and implementing the SCMS governance board and participating as a member. Dura was the only respondent indicating interest in taking the role of developing functions at the SCMS Manager level and above.
Dura favored a private model governance approach for the SCMS, excluding some identified issues. In their response, DURA identified two successful examples of both private and public models currently in place that address requirements similar to those identified in the RFI. A private model example is the Internet Corporation for Assigned Names and Numbers (“ICANN”),
a private, not-for-profit corporation established in 1998. The public model cited by Dura is the operating arrangement for the Federal Aviation Administration (FAA) and the national air traffic control system.
DURA specifically suggested, “a policy statement from the Department of Transportation advising the public that the U.S. government is prepared to enter into an agreement with a new, not-for-profit corporation formed by private sector transportation multi-stakeholders to administer the Security Credential Management System” and suggested the corporation be referred to as, “the Inter-Connected Automotive Safety Network (“ICASN”). Additionally, Dura suggested that its incorporation, governance and operation mirror as much as possible to that of ICANN.”
Dura suggested a subscription-based approach for ongoing SCMS sustainability and further recommended “aligning the subscription period with vehicle licensing/annual license plate renewal.” Dura also commented on how liability for system operation could influence costs; more specifically, from an insurance cost perspective.
Robert Bosch LLC affiliate ESCRYPT provided a response to the SCMS RFI with comments on potential governance strategies and expressed interest in implementing the Pseudonym Certificate Authority (PCA) and Linkage Authority (LA) components.
Bosch-ESCRYPT supported a private-public collaboration versus a self-governance model and commented that SCMS ownership should take a multi-layered approach, with high level Start Printed Page 3942policies residing within the USDOT and lower level implementation responsibility given to private organizations. ESCRYPT supported having the SCMS spread amongst differing, distinct organizations to help maintain privacy, and recommended a governance board to fulfill the SCMS Manager function, with membership defined by NHTSA but to include representatives from government, vehicle manufacturers, private organizations, and privacy groups.
ESCRYPT expressed interest implementing a production SCMS PCA and LA based on their support of the Safety Pilot Model Deployment. In their SCMS RFI response, ESCRYPT proposed an architecture that utilizes two types of certificates to ensure privacy. The first is short term pseudonyms, lasting from seconds to hours and being switched frequently. The second is long-term certificates along with three Certification Authorities: Long-Term; Pseudonym; and a Resolution Authority, the latter of which strips anonymity from pseudonym certificates that are believed to be a potential threat.
When meeting with the agency, Bosch-ESCRYPT expressed the importance of regional policy harmonization and stable standards, indicating that, once implemented, these important pieces will be not be changed easily or quickly.
The agency asked ESCRYPT for their experience on device management and how ESCRYPT has handled conditions such as managing and closing security breaches, device “end of life” management, and hardware security to help inform potential approaches for this NPRM. ESCRYPT indicated that over-the-air (OTA) software update is the best approach to closing potential security breaches and in support of NHTSA's vital recall efforts. When discussing device “end of life” scenarios, ESCRYPT suggested the approach of revoking existing certificates for an identified device and preventing future certificate updates allowing, in theory, the device to “fade away” from the system. Finally, when discussing potential hardware security needs, Bosch indicated they have experience with hardware security modules (“HSM”) and secure hardware extensions (“SHE”) successfully deployed in Europe and that, in terms of V2V, a lower-security implementation limits potential use cases of a system. The agency interprets this discussion, overall, that proposing a hardened device could extend a device's capability and contribute to overall system confidence.
(6) Certicom/Blackberry Technology Solutions
Certicom, a wholly owned subsidiary of Blackberry Ltd., provided a response to the SCMS RFI and also met with the agency to follow-up their response. Certicom provides “applied cryptography and security solutions for the embedded market” including engagement with governments and vehicle OEMs. Certicom has experience implementing Elliptic Curve Cryptography (ECC), “which provides the most security per bit of any known public key cryptosystem.” Certicom's parent company, BlackBerry, builds devices used by government and enterprise organizations, and operates a global secure network and mobile messaging platform. BlackBerry Technology Solutions also operates BlackBerry's QNX group which has presence in automotive telematics implementations.
Certicom supported a private consortium to manage a V2V SCMS, indicating that this approach could help “accelerate the deployments of V2X systems” serving both infrastructure and aftermarket devices. They stated that a possible “concern could arise if regulation unnecessarily limits the opportunity for participants to drive commercial innovation.” Certicom expressed interest in the SCMS operational roles of the Certificate Management Entity (CME) such as operating a Certification Authority (CA) and/or a Registration Authority (RA). However, Certicom indicated revenue models and costs would need to be better understood before committing definitively to any portion of the system operation.
Certicom commented that long-term viability of the SCMS is highly dependent on public acceptance. As such, participants in the system need a strong public identification (brand) and experience with successful security, safe, reliable and privacy implementations.
During the agency's meeting with Certicom, the discussion focused on clarifying the RFI responses but also in key areas of revenue generation, security approaches, and certificate and device management approaches used for Blackberry devices and other implementations that Certicom has supported, which includes public utility installed residential “smart meters.”
Certicom indicated there could be many reasons that entities would want to participate in a National SCMS and there could be potential opportunities presented such as the support of the security needs for manufacturing and system operations. In addition, expanded future roadside equipment could lead to yet-unknown revenue generation opportunities. Overall, V2V and a supporting SCMS could, in theory, “create a whole new market.” Certicom also suggested participants in the SCMS could generate on-going revenue by royalties from device manufacturers.
In terms of approaches to device security, Certicom indicated there are at least three security key-scenarios for devices. The following table provides an overview of these approaches and a corresponding, relative level of security provided by each.
Table V-2—Overview of Security Approaches
|Security Method||PKI||Keys/Certificates sent to device at time of manufacture||In device chipset (“silicon”).|
When discussing device and certificate management, Certicom provided an overview of three certificate distribution and management systems: Blackberry PKI, the ZigBee Smart Energy public utility residential meter system, and Certicom's approach to certificate and asset management for device original equipment manufacturers (OEMs).
The certificate service for Blackberry devices is designed for scalability, and secures devices from “birth” where a registration “seed” is embedded in the a device's onboard microchip (“silicon”) at the time of device manufacturer. The registration seed could be viewed like a V2V enrollment certificate, all of which is linked to the “root of trust” for the Blackberry ecosystem.
Certicom's overview of the ZigBee public utility smart meter certificate system varies from Blackberry devices, Start Printed Page 3943in that devices participating in that system are supplied from various manufacturers—similar to how V2V device implementation is envisioned, but the ecosystem itself could be viewed as localized.
In this implementation, ZigBee “Smart Energy” device certificates utilize an EQCV format issued in batches of one million. Certicom indicated they are able to issue approximately one million certificates in approximately one and half hours of processing. Each device participating in the system is identified by unique vendor identification, and verification is performed to confirm that each device's media access control (MAC) 
address is unique. Key pairs for each device are then bound to the device MAC address and vendor ID through the certificate. Figure V-2 shows a graphic representation of the ZigBee certificate management system.
Finally, Certicom provided an overview of a certificate authority and asset management system that they are able to supply for device original equipment manufacturers. The system is designed to enable OEMs and silicon vendors to remotely secure devices that are assembled at geographically-dispersed locations, similar to how vehicles are assembled. The system described provides operational visibility and control of secure key injection into a device at time of manufacture or initialization, secure device serialization and tracking, and support for anti-cloning and anti-counterfeiting. Figure V-3 provides a representation of this system and shows the remote management across various locations. The “tester” would be the point of security key injection into a device.
Start Printed Page 3944
Certicom indicated that this system enables OEMs to manage and distribute the sensitive security keying material, along with potentially other sensitive information, to an untrusted contract manufacturing environment supplying components for their end product. Figure V-4 shows the process flow for loading security information to a device in an untrusted manufacturing environment.
Start Printed Page 3945
As mentioned elsewhere in this section, device management also involves potential updates to device software to support technology updates and, importantly, in support of potential device recall scenarios. Certicom discussed Blackberry's OTA update service used for updating, configuring, and managing software and applications. Their updates leverage the existing Blackberry exclusive secure infrastructure for global distribution. This system also gathers status and data to support fleet monitoring capabilities for device operation. A graphic overview of the system is shown in Figure V-5.
With end-of-life and misbehavior being key elements of a national V2V deployment, the agency inquired about approaches for managing devices under these conditions. Certicom indicated that Blackberry devices can be remotely made non-functional (“bricked”) when a device is determined to be out of service, stolen, not functioning properly or potentially “misbehaving.” Reactivation of a “bricked” device requires interaction with Blackberry.
(7) SiriusXM Satellite Radio
SiriusXM Satellite Radio provided a response to the SCMS RFI and also met with the V2V NPRM team as follow-up. Their written response to the RFI focused on the opportunity for satellite transmission to perform non-safety-critical, “back haul” type operations for a SCMS. This could include certificate distribution, over the air updates, and certificate revocation list distribution, among other potential supporting transactions. SiriusXM commented that employing a satellite network as an alternative distribution path for safety certificates and the CRL would promote the development of a V2V system by enhancing scalability and the SCMS network footprint, and enable faster distribution of security information for V2V-equipped vehicles.
SiriusXM indicated that satellite transmission could potentially “bridge the gap” between initial V2V deployment and roadside unit deployment and, in the longer term, support more remote regions that may not have roadside units deployed. SiriusXM indicated that their infrastructure “could provide the ubiquitous, simultaneous, and robust distribution of security certificates and the certificate revocation list (“CRL”) in a V2V system.” SiriusXM's satellite network covers the contiguous United States and portions or Canada and Mexico, which could possibly assist with potential cross-border challenges. Their network also includes signal repeating equipment to supplement service in urban areas where satellite reception could be blocked by buildings or other obstacles.
According to SiriusXM, 69 million vehicles are currently equipped with their radios, and they expect this to increase to 100 million vehicles by 2017 as approximately 70% of new vehicles are equipped with their receiver.
When discussing privacy, SiriusXM indicated that no subscription would be required to receive satellite V2X data and that it would be available to any vehicle equipped with their satellite receiver. SiriusXM did not present any potential revenue generation concepts during the discussion. Additionally, SiriusXM stated V2X will be a transparent data service on its system, meaning that no V2X-related data is collected on the vehicle, and that the satellite delivery system has no knowledge of which vehicles are active and receiving data or where vehicles are located.
In terms of device management, SiriusXM suggested a hardware security module (HSM) for V2V-enabled devices as part of a trusted, secure data exchange environment. SiriusXM provided very detailed technical descriptions of how device-level security could be implemented and managed using satellite radio service. This included discussing the potential use of group codes, interaction with the HSM, in-use certificate downloads, available service channels, and revoked vehicle identification, all of which leverages its experience with the development and deployment of its satellite radio network that appears to have addressed many similar challenges found in V2V device deployment and management.
(8) Ford Motor Company and Volkswagen Group of America
Ford Motor Company (“Ford”) and Volkswagen Group of America (“Volkswagen”) submitted joint comments to the SCMS RFI. Together, Ford and Volkswagen indicated they are encouraged by the progress made in the collaborative activities between NHTSA and CAMP, in which they participate. However, they state in their comments that remaining items need resolution to enable an effective deployment of a V2V communications system, such as: (1) NHTSA's authority to mandate an SCMS; (2) an acceptable and stable funding model, and; (3) measures to address potential liabilities associated with participating in and/or being subject to a SCMS.Start Printed Page 3946
Ford and Volkswagen commented that the SCMS cannot be a private entity because vital functions of the SCMS cannot be delegated to a “private” entity, “which lacks the authority to require all participants in a V2V (let alone V2X) communication system to adhere to the system's necessarily rigorous operational policies, and enforce revocation based on unacceptable performance.” Ford and Volkswagen stated that they, other OEMs, and others that will necessarily rely on the SCMS must have a role, along with government, in establishing SCMS operational policy. Additionally, they stated that Federal authority over the SCMS is essential and a binding governance board for SCMS management is needed.
Finally, Ford and Volkswagen stated that funding for centralized SCMS components or functions should come from a federal source. They do not support any funding model relying on the sale of data to third parties, and, additionally, the SCMS funding model “should not be based on a potential requirement that specific services must be enabled within the vehicle to offset operational costs.” Conversely, non-centralized components, like the certificate management entity (CME) or registration authority (RA), could be established independently for their own use.
(9) SAE International
The Society of Automotive Engineers (“SAE”) responded to the RFI with interest in playing a supporting role in SCMS deployment. SAE indicated interest in working with SCMS stakeholders in a partnership and/or larger consortium to support the SCMS functions, “through a combination of standards development, conformance programs and training.”
SAE International standards J2735 and J2945 were revised and are being developed to support a national V2V deployment by providing a consistent, standardized approach to V2V device implementation across the industry.
(10) The American Motorcyclist Association
The American Motorcyclist Association (“AMA”) commented to the SCMS RFI by urging DOT to test the V2Vcommunication systems to ensure that motorcyclists' safety and privacy are secure. AMA expressed their support for DOT's position “for further testing before adopting the rule authorizing U-NII devices (e.g., Wi-Fi) to operate in the band to ensure vehicles using advanced crash-avoidance and vehicle-to-vehicle technologies are not compromised.” AMA also expressed concern about the potential for “hacking” into a future V2V network, and specifically, the potential to manipulate traffic signals which could be “especially disconcerting for motorcyclists who comprise the most vulnerable roadway user group.” AMA closed their comments stating that the safety of all highway users should always be a priority whenever new technologies are considered.
(11) Alliance of Automobile Manufacturers, Inc.
The Alliance of Automobile Manufacturers, Inc. (“Alliance”) reiterated their comments to NHTSA's V2V ANPRM where they “agreed with NHTSA's assessment that a strong SCMS is necessary for a properly functioning V2V communications system.” The Alliance also reiterated its ANPRM comments expressing concerns with how a privately-run SCMS could address the broad structural and governance challenges that an SCMS manager would need to address, such as:
- Funding, deployment, operation and maintenance of a DSRC-based V2X security communications network
- Sustainable funding for V2X PKI security system operations and management
- Governance of a V2X security system (Rules of Use, Certification, and system access)
- Protection of consumer privacy
- Liability, risk management, and intellectual property protections
- International considerations including possible Canada-US-Mexico cross-border traffic, international agreements, or standards harmonization.
The Alliance maintained in its RFI response that addressing the above policy issues, which are necessarily national in scope, requires strong unified Federal leadership, not just presence.
(12) Association of Global Automakers
The Association of Global Automakers (“Global Automakers”) provided general comments along with direct responses to the RFI questions. In its comments, Global Automakers strongly supported a public-private partnership model for SCMS operation by stating that “the agency has underestimated the necessary governmental role in managing the SCMS and too narrowly constrained the participation of other agencies in SCMS operations. Contractor operation of many aspects of the SCMS is feasible but must be conducted under the authority and supervision of a significant governmental entity.”
Global Automakers further stated that, to be effective, the SCMS must be a monopoly, which is not allowed under law for a private entity, and that funding for the SCMS should come from the government rather than from revenue generated by consumers; less potential consumer subscription funding opportunities for some potential V2I services. Additionally, the SCMS should be developed to support V2V and V2X holistically, at the outset, in partnership with the Federal Highway Administration (FHWA) and possibly other agencies such as the Federal Communications Commission and the Federal Trade Commission where privacy is of concern. Global Automakers stated that cross-agency coordination and harmonization is critical to the effective operation of the SCMS.
Global Automakers expressed concern with the potential approach for the “Device Non-compliance and Potential Recalls” discussion in the RFI materials, specifically, that it believed that the approach suggested by the agency would undermine consumer privacy, be impractical, and be redundant to systems that are already in place to manage recalls. It commented that the proposed “link between specific installed V2V devices or production lots of devices and enrollment certificates” would create a potential perception that V2V communications could be traced to individual vehicles and drivers.
(13) Verizon Communications, Inc.
Verizon Communications' RFI response focused on potential steps and pathways to achieving a National SCMS deployment and focused on three key approaches to SCMS policies and operations standards and potential adjustments to the PKI implementation. In more detail, Verizon suggested that: (1) NHTSA should define a system of policies, regulations, workflows, and technical interoperability that provides for the management and control of the overall SCMS; (2) implement an “identity PKI” as a baseline and “bootstraps” anonymously allowing linkage between certificates and supporting potential device recalls; and (3) an “anonymity PKI” solution that allows the device to perform any necessary operations anonymously.
(14) General Motors, LLC
General Motors, LLC (“GM”) submitted comments to the SCMS RFI that also included broader V2V rulemaking comments. GM stated, in the Start Printed Page 3947broader context of V2V, that they support NHTSA's rulemaking initiative for all passenger cars and light trucks to be sold in the United States, and that “a comprehensive and connected ecosystem must be developed and implemented offering seamless and trusted communication between vehicles” to obtain all the potential benefits of V2V technology. GM commented that it strongly believes that a NHTSA rulemaking process is the only method to successfully establish a V2V ecosystem; that, as envisioned, the system cannot be established and managed by a single manufacturer or industry group.
Focused comments regarding the SCMS stated its belief in the requirement for Federal oversight of the SCMS Manager, the central root authority organization, direct engagement with the Misbehavior Authority and coordination of certification labs.
(15) CTIA—The Wireless Association
CTIA is an international nonprofit organization representing the wireless communications industry. CTIA's members include wireless carriers and their suppliers, as well as providers and manufacturers of wireless data services and products. CTIA's comments to the SCMS RFI focused on the benefit of leveraging existing authentication and security technology, along with utilizing existing networks and infrastructure to promote standardization and interoperability. CTIA also stated that the private sector is best positioned to address V2V SCMS cybersecurity and privacy concerns and should be utilized to help implement cybersecurity best practices.
(16) Tesla Motors, Inc.
Tesla Motors, Inc. (“Tesla”) commented primarily on the security of the SCMS design presented in the V2V Readiness Report by urging NHTSA “to ensure that all possible security aspects are considered and accounted for when implementing its chosen design.” Tesla commented that much more analysis and consideration needs to be given to the SCMS before it is implemented as proposed. Tesla acknowledges that it has not been involved with the Crash Avoidance Metrics Partnership (CAMP) consortium and that this brings a new perspective to the CAMP SCMS design.
Tesla believes that, as envisioned, the CAMP system fails to consider adequately how the system could be attacked or the vast amounts of information that will necessarily pass between vehicles and that NHTSA's proposed system has gaps that must be addressed before it is implemented.
Tesla narrowed its primary concerns into the following: (1) Because inputs are insecure, false messages are likely, even with secure V2V subsystems; (2) vehicles must have some way to determine whether messages, particularly misbehavior reports, are legitimate; (3) certificate revocation lists (“CRLs”) do not scale well for widespread use; (4) public‐key cryptography is poorly suited to the demands of an embedded, high‐speed environment; and (5) transmitted messages could be the source of privacy breaches.
Tesla concluded their comments by stating that “the Company believes that the CAMP system has fundamental issues and challenges that must be revisited in order to allow for successful implementation of the SCMS.”
(17) Intercede Ltd.
Intercede, Ltd. is a software company solely focused on producing and delivering identity and credential management solutions to entities such as Government, Aerospace and Defense, Finance, Healthcare, Large Corporations and Managed Service Providers. Intercede's response to the RFI focused on the need for the SCMS to provide a secure and trusted environment for V2X, and stated that it will be necessary to consider the V2X communication devices over their entire lifetime, which was defined as:
- Initial manufacture;
- Transfer of ownership;
- Natural end of life.
Intercede's response went on to state that “it is also important to consider the interactions beyond the communication channels that must be established into a secure trust system. Failure to do so would open up potential back doors into this trust system that could allow for compromise to occur from within.” Follow-up discussion with Intercede stressed its views regarding the need for a complete, systems approach to security—encompassing “cradle to grave” for devices. And that, “By adopting a controlled and secure approach to device identity management, NHTSA will enable a strong trust environment to be established that can then be built on for large-scale key generation during the lifetime of the device in the field for V2X communications.”
(b) SCMS RFI Agency Response
The RFI responses and subsequent meetings benefitted NHTSA greatly by providing additional technical perspectives on the SCMS PKI design. For example, DOT had originally dismissed the use of satellites as a viable communications media for transmission of security materials between the SCMS and OBE, but our meeting with Sirius XM Radio brought to NHTSA's attention the fact that, due to advances in technology and the close working relationship between the auto and satellite industries, satellite could in fact be a technologically and economically viable, secure and private media for such security transmissions. Similarly, the PKI technical model put forth by NHTSA in its Readiness Report assumes that a single root must form the basis for trust system-wide. However, as a result of meetings with CSS, NHTSA now is aware of the possibility that, through use of a trust bridge, one or more SCMS organizations, possibly representing different regions or even manufacturers, may be able to co-exist and together, provide more redundancy in security for V2V and V2X DSRC communications.
5. SCMS ANPRM Comments and Agency Response
(a) ANPRM SCMS Comments
With limited exception, comments received in response to the ANPRM generally endorsed the PKI design as an appropriate security solution for V2V and V2I DSRC communications. For example, GM, the Alliance, Toyota, and the Automotive Safety Council all concurred that the SCMS design described in the ANPRM and the V2V Readiness Report should provide the required level of security while also protecting the privacy of the end users. Throughout all the comments there were two major concerns with the SCMS design that were cited by multiple commenters: (1) The overall complexity of the design; and (2) a fallback plan for a compromised root.
One of the recurring comments in the ANPRM focused on the overall complexity of the design of the SCMS and the plan for implementing such a system. The design of the SCMS is more complicated than any existing PKI systems due primarily to the need to protect the privacy of the end users both from outsider and insider attacks. As such the various functions in the system are separated logically and organizationally in an attempt to ensure that one organization does not have access to all the information needed to identify the end users. Therefore, this Start Printed Page 3948level of complexity is necessitated by the system requirements.
The second technical concern highlighted in the comments is the impact on the system if the private key of the SCMS root certificate authority is compromised. If the root CA is compromised, then this would compromise certificates for all V2V devices, roadside infrastructure devices, and SCMS components. Reissuing the certificates for over 350 million end users would require a significant amount of time and resources to complete. For example, all V2V devices would need to be re-initialized in order to receive a new enrollment certificate; however, this process must occur over a secure communications channel. This may require all devices to return to the dealership or service center in order to have access to the secure communications channel required for the initialization process.
(b) ANPRM Agency Response
In response to the first concern, the agency agrees that the level of complexity of the design does increase the risk associated with the implementation and deployment of this system. To combat that risk, one commenter suggested that the system be implemented through a phased development approach where components of the system are developed, tested, and deployed incrementally. This approach would ensure that the deployed components are secure and reliable for additional components are deployed into the system. The agency agrees with this recommendation and is employing in it the development of the SCMS Proof-of-Concept. This system is being developed using an incremental approach that focuses on first implementing and testing the core components of the system, followed by the non-core components. After the system is developed and tested, it will be operated for a significant period of time by DOT. During this operational period, existing V2V and V2I test beds will be integrated with the SCMS POC, and it will provide the necessary security credential materials to these test beds. The knowledge gained from the operation of the SCMS POC will inform the development of the National SCMS that will be required to support an eventual FMVSS.
The agency also concurs that it would be a catastrophic event for the root CA to be compromised, and as such we are exploring various approaches for disaster recovery that can be implemented to mitigate this risk. The SCMS Proof-of-Concept will implement and test root management and disaster recovery solutions that will allow a root CA to be revoked without requiring the recall and re-initialization of all the V2V and V2I devices in a secure environment. One of the solutions to be tested in the SCMS POC is a distributed root management approach that utilizes root electors to manage the trust relationships in the system. Another solution being evaluated includes the use of redundant root CAs where only a single root is active at any one time. These approaches will be tested and evaluated during the operation of the SCMS POC to ensure that in the event of a compromised root, the system can be recovered without the need to recall every V2V and V2I device.
6. SCMS Industry Governance
(a) The SCMS “Industry”
Deployment of an SCMS PKI to secure V2V DSRC communications will require governance of a wide range of complex functions and involve numerous public and private stakeholders, which together we refer to here as the SCMS “industry” or SCMS “ecosystem.” We expect that SCMS stakeholders will include: Manufacturers of OBE, RSU, and aftermarket safety devices (ASD); certification labs that test OBE (and potentially ASDs); organizations supporting V2V communications; auto manufacturers; standards organizations; PKI experts; State and local government users, and others. In Figure V-6, below, the shapes represent different groups of organizations that interact with the SCMS in some way. Some of these organizations will need to be stood up, while others currently exist today and will likely expand their operations to play a role in the SCMS. The overlapping of shapes represents mutual reliance in executing operations, and the arrows represent communication and the need for inter-organizational arrangements. The SCMS is the focal point of the certificate management industry, as it encompasses the CMEs that oversee all PKI functions responsible for establishing the foundation of security in the V2V/V2I/V2X system.
Start Printed Page 3949
Some of the questions that NHTSA raised in the V2V Readiness Report about industry governance structure for the SCMS include:
- How and by whom are decisions made about various policies, standards, requirements, and practices?
- Who has the authority to mandate and enforce compliance with the policies, standards, and industry requirements?
- Who makes up the overseeing financial, legal, management, and executive operations of the entities in the SCMS?
- Is there a central industry body and, if so, who oversees it? Who is part of this central industry body?
- How do the various entities interact with each other?
- How is risk and liability allocated across the organizations?
- Who will own the intellectual property (data and software) of the system and how will it be licensed (allocated) among responsible entities?
In answering these questions, NHTSA continues to explore a variety of governance models (ranging from public to public-private to private) as potential options for governing the SCMS industry. Due primarily to the absence of Federal funds to support a public SCMS, to date NHTSA has focused primarily on fleshing out a model of private SCMS ownership and governance that assumes costs will be covered by increases in the purchase price of new vehicles and V2V safety devices. As we noted our V2V Readiness Report, in a private SCMS industry the organizational structure and operation of the SCMS would be determined largely by private owners and operators of CME components, under oversight of an SCMS Manager (ideally an industry-wide coalition of CME owners and other stakeholder representatives who, together, agree on the terms of self-governance and system-wide rules and policies). The SCMS Manager would provide critical system management by enforcing and auditing compliance with uniform technical and policy standards and guidance system-wide. Uniform standards and guidance would establish and ensure consistency, effectiveness, interoperability, sustainability, and appropriate privacy protections across the CMEs to facilitate necessary communications, sharing of information, and operational connections, and would be based in large part on existing technical and policy standards applicable to PKI systems.
The Readiness Report explained NHTSA's view that, in the context of a privately owned SCMS “industry,” a private model could be a viable mechanism for SCMS governance in which NHTSA would have only a minimal role in ensuring system integrity, largely through its traditional regulatory activities. We also indicated that NHTSA's existing legal authority would accommodate the use of grants, cooperative agreements, or other agreements to facilitate stakeholder—and even DOT—input into governance of a private SCMS.
(b) ANPRM Governance Comments
Comments to the ANPRM and Readiness Report relating to SCMS ownership and governance came mostly from members of the automotive industry and their trade groups. While agreeing with NHTSA's assertion that a V2V system is not complete without a robust SCMS, almost without exception, industry commenters vehemently disagreed that a private self-governing industry coalition could be a viable mechanism for SCMS system governance. Commenters believed that a private SCMS could not provide the security, privacy, certainty, stability, long-term functionality, or management of costs and risk required for a nationwide SCMS to support V2V DSRC communications, and lacked the legal authority to address cross-border issues Start Printed Page 3950or require industry-wide participation and compliance with uniform requirements. For these reasons, virtually all industry commenters took the position that a strong leadership role for the Federal government in the SCMS would be required for successful deployment of V2V and V2X DSRC communications.
For example, both the Alliance and Mercedes described the SCMS as a “core government responsibility.” Noting that “for V2V to work effectively, every vehicle manufacturer will have to participate in the SCMS and abide by its rules,” the Alliance explained that:
a private organization, such as a voluntary coalition of manufacturers, cannot compel unwilling manufacturers to join the organization, and cannot enforce deviations from the organization's rules except by expelling misbehaving members. There is no effective mechanism to ensure the universal participation of all manufacturers and to compel their obedience to the necessary common SCMS requirements. . .
The Alliance also stated that “resolution of policy issues requires coordination among multiple federal agencies (FHWA, FTC, FCC, EPA),” and that “Congress was best positioned to provide the needed coordination and nationwide-scope for addressing infrastructure, governance of networks and SCMS, consumer privacy, sustainable funding, international cross-border and liability/IP policy issues.”
Global commented that “private sector options for operating the Security Credential Management System (SCMS) do not guarantee certainty over the management or the cost of operation the system and its long-term stability.” GM, likening the issuance of security certificates to the minting of coinage by the Federal government, argued that ensuring a secure V2V system would require that the Federal government: (i) Operate or support operation of a central root CA that all V2V certificates must use, or mandate that all V2V certificates use a central root CA; and (ii) review and approve minimum levels of security for the keys and cryptography used by the root CA and subordinate CAs authorized by the root CA. Mercedes described the SCMS as a “backbone infrastructure, which must be set up and controlled with the leadership of state and federal authorities” and echoed the comments of the Alliance that only Federal government oversight would ensure industry-wide participation in an SCMS and compliance with its requirements. Similarly, Honda commented that the federal government should be responsible to ensure the safe and efficient operation of the V2V security framework, and should consider a public-private partnership as an option for the operation and management of the SCMS, with federal oversight, supervision and funding.
The agency agrees with commenters that, for a variety of policy reasons, ideally the Federal government should play a more central leadership role in the establishment and governance of a V2V SCMS. For this reason, as detailed above, DOT now has taken the lead in working with SCMS stakeholders to develop the policies and standards that should form the basis for governance of a National V2V SCMS, as well as to model and prototype organizational options for a governance entity to manage SCMS operations.
(c) A Comparative Industry Example: ICANN
In analyzing SCMS governance options, NHTSA and its research partners have investigated a variety of industries with characteristics similar to those seen as critical for a V2V SCMS governance model, including security, privacy protection, stability, sustainability, multi-stakeholder representation and technical complexity.
We investigated an array of public, public-private and private governance models, with particular emphasis on safety-critical and privacy-sensitive systems. We also examined how risk was managed in the context these models. Some of the industries researched included:
- Internet Corporation for Assigned Names and Numbers (ICANN)
- DTE Energy Company
- Aeronautical Radio Incorporated (ARINC)
- End of Life Vehicle Solutions Corporation (ELVS)
- The FAA's Next Gen Air Transportation System
- The FRA's Positive Train Control
- Smart Grid
- The Rail/Transit Train Control Systems (ATC and CBTC)
- FMCSA's EOBR
- Coast Guard's MSSIS
- Army Corp of Engineer's MRGO
- Medical Devices failure and liability
- Security in nuclear industry and liability
- Warning/Signal Failures
- HIPAA/Health Care industry/Electronic Health Records (EHRs)/CONNECT system
- Credit Card Payment industry and PCI standards
- Hospital/Health care industry
Of the governance models we examined, governance of the internet naming protocol systems (DNS) by the Internet Assigned Numbers Authority (ICANN) possessed numerous characteristics that seem to translate most directly to a private or public-private governance model for the V2V SCMS. ICANN is a private, not-for-profit corporation created by private sector entities in direct response to efforts by the Federal government to privatize certain Internet-related tasks in a manner that permits robust competition and international participation in its management. ICANN is managed by a multi-stakeholder Board of Directors (representative of the functional and geographic diversity of the Internet) that oversees a number of Internet-related functions previously performed directly on behalf of the Federal government by other organizations, notably the Internet Assigned Numbers Authority (IANA) (formerly located within the Department of Commerce but now operated by ICANN). Pursuant to various Memoranda of Understanding with ICANN (ICANN MOUs), the Department of Commerce agreed gradually to transfer to ICANN certain Internet-related functions, with the goal of having ICANN carry out operational responsibility for these functions in a financially self-sustaining manner after a limited transition period. At the same time, the Department of Commerce also entered into a series of funded project agreements with ICANN, on a sole source basis, to perform technical and policy activities required to facilitate the transition of authority for those functions to ICANN.
The ICANN MOUs and project agreements called for the Federal government to exercise significant oversight of ICANN's activities until such time as ICANN was stable and could provide certain stability, sustainability and policy assurances to the Federal government. After 11 years, the Department of Commerce gave up its oversight of ICANN with respect to the operation and governance of specific Internet naming protocol functions, but committed to ongoing participation in ICANN's Governmental Advisory Committee (GAC). ICANN continues to perform certain technical maintenance tasks under contract to Commerce, as do other Commerce contractors. In 2014, Start Printed Page 3951Commerce announced its intention to work with ICANN to privatize key Internet domain name functions still remaining under its control.
How is ICANN relevant to governance of the V2V SCMS? ICANN provides NHTSA with a potential road map for how it can work with public and private stakeholders to develop a successful governance structure for a multi-stakeholder, geographically and functionally diverse technology-intense system not unlike V2V. Like the V2V SCMS, successful deployment of an Internet naming protocol required uniform and consistent application of technical and policy standards enabling interoperability and system-wide confidence. As would be required for enforcement in a privately governed SCMS, ICANN uses a binding Registry Agreement as the enforcement mechanism through which it ensures that its policy and technical standards are applied Internet-wide. Like the SCMS ecosystem or “industry,” the Internet “industry” involves numerous commercial, academic, geopolitical, and other private and public stakeholders involved in a broad range of Internet-related functions, the success of which requires system-wide, coordinated governance. As would be likely in the SCMS context, ICANN was developed and operates on a foundation of the fundamental principles of security, stability, resiliency, multi-stakeholder participation, openness, fairness and robust completion. Additionally, as detailed in the ICANN MOUs, after a period of direct government oversight and funding, the privatized functions governed and coordinated by ICANN were designed to be financially self-sufficient (i.e. financed by fees paid for services).
We agree with Dura and the VIIC that ICANN's organizational structure could translate well to a potential V2V SCMS governance model. The details of ICANN's mission, core values, powers, responsibilities, governing principles and procedures are set forth in its Articles of Incorporation, Bylaws, Charter, and other publicly available documents. In accordance with those documents, ICANN is governed by the binding decisions of a Board of Directors, consisting of both voting Directors and non-voting liaisons. The voting Directors consist of members selected by a functionally and regionally diverse nominating committee that reflects the diversity of Internet ecosystem, as a whole: the Address-Supporting Organization (ASO), the Country-Code Names Supporting Organization (CCNSO), the Generic Names Supporting Organization (GNSO), the At-Large Community and the President ex officio. Directors may not be officials of countries or multinational geo-political entities. Only ICANN's President can be both a Director and ICANN employee. Non-voting liaisons are a means for the Board to obtain input from world-wide governments, through the Government Advisory Committee (GAC), and three function-specific expert committees, the Internet Engineering Task force (ETF), Security and Stability Advisory Committee (SSAC) and Root Server System Advisory Committee (RSSAC). The organization has an Ombudsman appointed by the Board to act as a neutral dispute resolution practitioner and provide an independent internal evaluation of complaints by members of the ICANN community who believe that the ICANN staff, Board or an ICANN constituent body has treated them unfairly.
NHTSA also found quite instructive the procedures used by the Department of Commerce to effectuate the process of successfully privatizing certain Internet-related functions. In July 1997, the Department of Commerce first published a Request for Comments on behalf of an interagency working group examining the appropriate future role of the Federal government in the DNS and other issues related to the administration of the DNS. The following year, in early 1998, based on the 1400 pages of comments it received to its Request for Comments, it issued a rulemaking notice proposing certain actions designed to privatize the management of Internet names and addresses in a manner that allowed for the development of robust competition and facilitates global participation in Internet management.
The proposed rulemaking addressed a variety of issues relating to DNS management including private sector creation of a new not-for-profit corporation (the “new corporation”) managed by a globally and functionally representative Board of Directors. The rulemaking proposed, among other things, the new corporation's authorities, detailed the role of the federal government in policy oversight during the transition, identified funding, and contained a detailed proposed governance structure (specific to the number of seats on the Board of Directors) with substantive stakeholder participation and openness requirements. The rulemaking explained that, the new corporation would:
Act much like a standard-setting body. To the extent that the new corporation operates in an open and pro-competitive manner, its actions will withstand antitrust scrutiny. Its standards should be reasonably based on, and no broader than necessary to promote its legitimate coordinating objectives. Under U.S. law, a standard-setting body can face antitrust liability if it is dominated by an economically interested entity, or if standards are set in secret by a few leading competitors. But appropriate processes and structure will minimize the possibility that the body's actions will be, or will appear to a court to be, anti-competitive.
Later the same year, in July 1998, the Department of Commerce opted to proceed with privatizing management of the internet DNS not through rulemaking but by issuing a Statement of Policy expressing the Government's intent to “recognize, by entering into agreement with, and to seek international support for, a new, not-for-profit corporation formed by private sector Internet stakeholders to administer policy for the Internet name and address system.” 
In a July 7, 2000 report,
the GAO confirmed the appropriateness of the Department of Commerce's actions. The GAO determined, among other things, that:
- Department of Commerce had the authority to support privatization of the DNS on the basis of its general authority 
to foster, promote, and develop foreign and domestic commerce and NTIA's more specific authority to coordinate the telecommunications activities of the executive branch; 
- The APA notice and comment requirements did not apply to the Department of Commerce's general statement of policy, as it contained not substantive regulatory requirements but a general framework for privatizing the DNS;
- Establishment of ICANN by the private sector was not subject to the Government Corporation Control Act or various other legal requirements applicable to entities that are part of or controlled by the Federal Government;
- Department of Commerce had authority to enter into the MOUs, Start Printed Page 3952cooperative agreements and sole source contracts with ICANN based on its general legal authority to work with and enter into these types of agreements with non-profit entities.
It must be noted that the circumstances that led to creation of ICANN are different, in significant respects, than those that now necessitate the creation of an SCMS to support V2V DSRC communications. When it issued its Policy Statement, Department of Commerce had funds dedicated to administration of the DNS it sought to privatize and already had taken on responsibility for performing that function, in accordance with Federal law. For this reason, the Department of Commerce had a legal obligation closely to oversee ICANN's assumption of responsibility for the DNS during a transition period. It also continued to fund ICANN in the performance of certain additional functions previously performed by IANA, even after it ceased to oversee ICANN's policies and operation of the DNS in 2009. By contrast, to date, NHTSA has not assumed responsibility for carrying out any security functions relative to mandated automobile equipment, so no infrastructure or funding for this purpose now exists. Additionally, NHTSA seeks not to privatize existing federal security functions or infrastructure, but to work closely with public and private V2V stakeholders to take the technical design, intellectual property and body of policy developed through DOT's SCMS research and facilitate the creation of a new operational entity—a National SCMS to support V2V, V2I, and V2X DSRC communications.
Despite these differences, NHTSA believes that ICANN serves as a strong comparative industry model of how NHTSA can work with stakeholders in the SCMS ecosystem to facilitate creation and support of a multi-stakeholder private sector entity to govern and coordinate operation of the V2V SCMS.
(d) Potential SCMS Implementation Model
It is clear that there are numerous different paths that government and private stakeholders theoretically could follow in implementing a National SCMS to support the V2V ecosystem—paths the organization, governance and financial viability of which DOT expects its expanded policy research to develop and assess. There may even be other viable security models that could provide sufficient confidence and consumer privacy protection to V2V messages. However, if NHTSA mandates V2V communications equipment in light motor vehicles and moves forward with implementing the SCMS technical design described above, the agency believes that one promising path was that pursued by Department of Commerce when it spurred private sector establishment of ICANN. Specifically, DOT could facilitate the creation of a multi-stakeholder entity capable of governing and coordinating operation of a National SCMS. DOT's expanded policy research, including stakeholder input, modeling, and prototyping of potential governance models, as well as comments on the NPRM, will help determine whether such an SCMS should be a purely private entity in which DOT plays an advisory role—or whether the Federal government should assume control over some critical SCMS functions (for example, ownership of the definitive root).
If appropriate based on the Department's planned research, DOT then could issue a draft V2V SCMC Policy Statement describing a process (similar to that followed by DOC and ICANN) by which the Department could, if it chooses to, work collaboratively with a new multi-stakeholder private entity to develop the binding policies and technical standards required for stable and sustained operation of a V2V SCMS. After an initial period of joint policy development and direct DOT oversight under contract, prior to full SCMS deployment, DOT gradually could terminate some or all its oversight of the new entity's activities, completing the transition of authority prior to full SCMS deployment. Thereafter, representatives of NHTSA and other Federal government agencies, both within DOT (DOT-R, FHWA, FMCSA, and the others) and elsewhere in the Federal Government (FCC, FTC), could serve in an advisory capacity on a Government Advisory Committee or as nonvoting SCMS Manager Board Members.
(e) SCMS Proof-of-Concept Operational Model Development Plan
As a result of a better understanding obtained from operating the prototype security system during Model Deployment, as well as feedback from the SCMS Request for Information, ITS-JPO and NHTSA realized that expanding to a National level SCMS would require an intermediate step. Specifically, that additional research was required to prove the concept and develop a SCMS working model that allows for investigating the full range of technical, policy, and organizational elements involved in deploying and operating the SCMS. Investigating these components includes providing security certificate management services to continuing vehicle communications research activities and early deployments.
As part of developing a working SCMS model, DOT will:
- Develop and implement a proof of concept SCMS (the SCMS PoC) that is fully representative of the Final SCMS design, and which will provide certificate management services to early deployments and demonstrations, including but not limited to CV pilots,
- Act as the overall SCMS PoC Manager, including developing policy and procedures that will govern the interactions between the various entities involved in the V2X eco-system, and
- Based on stakeholder input, will advanced and adapt SCMS PoC policies and protocols such that they would represent possible policies and protocols suitable for the establishment and operations of a SCMS that could support a national deployment of vehicle communication technology.Start Printed Page 3953
The SCMS proof-of-concept (PoC) will be fully representative of a production SCMS in terms of functionality, features, and capabilities. It will support all certificate management “use-cases” envisioned for a production system, and incorporates all elements of the final design developed by DOT and its industry partners. While not intended to be “full-scale”, the SCMS PoC will be capable of servicing up to 17 million vehicles annually. The SCMS PoC is being developed to:
1. Support end-to-end testing of the certificate management use-cases thus demonstrating feasibility and practicality of system;
2. Demonstrate the extensibility of the SCMS design (multiple non-central components);
3. Support scalability testing through modeling, simulation, and real-world deployments;
4. Support integrity, robustness and system vulnerability testing;
5. Will be used in actual connected vehicle operations by servicing a variety of early deployments and demonstrations including the Connected Vehicle pilots (Tampa, NYC, Wyoming), the Smart City Challenge program recipient, as well as other government sponsored (state & local) and private sector deployments that we anticipate emerging over the next several years; and
6. Will be able to support future connected vehicle application demonstrations programs for FMCSA, FTA, and FRA (e.g., wireless roadside inspections; electronic credentialing; grade-crossing safety; transit-pedestrian safety; and other applications).
NHTSA and its industry partners (CAMP) are currently in the process of prototyping an SCMS system that is capable of executing all the core use-cases associated with the security certificate management life cycle including enrollment, certificate generation, certificate request and fulfillment, and revocation. This proof-of-concept SCMS (the SCMS PoC) is being developed to support real-world operations of early V2V deployments at connected vehicles pilots sponsored by DOT (in Florida, New York City, and Wyoming and elsewhere). NHTSA and its industry partners will continue to refine, test and mature the design of the SCMS—including addressing the functions and features listed above—by leveraging this prototype environment. To support these refinement efforts, we are establishing multiple instantiations of the SCMS including Production, Quality Assurance and Development environments. Further, we are in the process of retaining an additional (in addition to MITRE) independent cyber-security testing and evaluation Team to conduct a thorough design review on the Final SCMS design, and to complete focused penetration testing and vulnerability discovery on the actual SCMS prototype by leveraging the Development environment platform.
DOT will develop, operate, and manage the SCMS PoC through multiple contract/agreements with multiple entities, illustrated via Figure 1. Figure 1 identifies five research activities including the SCMS PoC Governmental Management that represent the SCMS PoC Manager Environment. This environment depicts the boundaries of the SCMS PoC Governmental Management activities. DOT has already established an agreement that is currently developing an initial prototype of the SCMS PoC that will be the basis for the operational environment and support ongoing functional (refinement) development. SCMS PoC Governmental Management includes the development of policies that support the technical processes and procedures and the organizational protocols that establish interfaces (communications) between entities that support policy and operational execution. DOT, with the support provided by the Governmental Management contractor, will be the SCMS Manager and set policies and protocols that will address threats in relation to access and change authority. The SCMS Manager will develop and establish a Certificate Policy and Certificate Practice Statement that sets the policies and protocols that must be accepted and followed to be approved to participate in the SCMS environment.
A separate agreement will establish the operational SCMS PoC (provides the technical functions that enables generation, distribution and monitoring of SCMS security materials). Related to the separate agreement that establishes PoC operations is an agreement that provides for the technical management that encompasses the development and documentation of technical process and procedures end entities will use to initialize devices and obtain security materials. Another contract will provide Connected Vehicle Support Service that supports the initial interactions regarding end entity applications for device initiations, technical support questions, and questions about policies and procedures. The Connected Vehicle Support contractor will establish and operate the initial interface with end users.
Beyond the SCMS PoC manager environment, the SCMS PoC Governmental Manager will in most cases indirectly interface with other research activities such as the CV Pilots, and other support entities that include Certification Service entities, and Device Suppliers. The most direct outside relationship will be with the National SCMS Prototype Policy Development research. The SCMS Governmental Management effort will need to interface with the National SCMS Prototype Policy Development research to support national level SCMS prototype policy development.
The SCMS PoC environment, together with the connected vehicle pilot sites sponsored by DOT, will provide an opportunity to refine the SCMS Manager concept and other non-technology related policies and procedures needed to address security threats.
(f) SCMS Request for Comment
NHTSA has invested considerable resources and effort in refining and maturing the Security Credential Management System Design. The Agency has enlisted the assistance of leading PKI experts in developing the design, and the design has been formerly reviewed by MITRE Corporation (see Section V.B.3 for summary of MITRE review) and other Federal Agencies including DARPA and NIST have also reviewed the design. NHTSA believes that the SCMS concept and design offers a practical, efficient and effective means for addressing the need for confidence in V2V and V2I communications—while simultaneously addressing privacy concerns arising from potential vehicle tracking using V2V communications. Nevertheless, a fully representative prototype of the SCMS system has not yet been developed and tested, although NHTSA and the JPO are in the process of doing just that, (see Section V.B.6.e) for details).
In addition, the SCMS concept calls for periodic (or routine) communications between the vehicle and various certificate management entities (which reside in the “infrastructure” on the internet) to execute a variety of certificate management life-cycle services including: re-provisioning of on-board pseudonym certificates; distribution of certificate revocation lists; and potential a component for sending misbehavior detection reports from vehicles to the Misbehavior Authority of the SCMS as described in the Proposal. While NHTSA believes that such periodic vehicle to infrastructure communications can readily be accommodated thru either V2V DSRC communications (using roadside units, or RSUs), or through the rapidly Start Printed Page 3954increasing connectivity of vehicles using commercial wireless services (cellular or satellite services that are either integrated into vehicle or made available through links with an operator's cell phone), NHTSA nevertheless recognizes that security certificate management concepts that inherently minimize the need for such periodic V2I communications may offer advantages relative to maintaining proper on-board certificate credentials.
To manage the normal risk associated with any new and complex information security system, and to address a means for potentially reducing the need for V2I security communications, NHTSA has been, and continues to investigate alternatives to the SCMS concept.
NHTSA seeks comments on all aspects of the SCMS. In technical design, development, and potential deployment, including DOT's proposal to expand its governance role in development of a viable organizational model and policies and procedures applicable to a National SCMS, and the use of ICANN as a possible roadmap for how to facilitate establishment of a private, multi-stakeholder entity to manage and oversee operation of the National SCMS.
C. Vehicle Based Security System (VBSS)
In late 2012 NHTSA began investigating a certificate management concept termed the “vehicle based security system” (VBSS). VBSS is based on principals associated with Group Manager concepts for managing cryptographic materials—and adapted for vehicular application by NHTSA engineers.
The major difference between SCMS and VBSS is in generating short-term certificates. The SCMS approach relies on individual vehicles to periodically request pseudonym certificates from infrastructure-based entities, (most notably a Pseudonym Certificate Authority, or PCA) which in turn generates and signs short-term certificates. Vehicles then download batches of certificates which are used to digitally sign BSM messages. In contrast, the VBSS concept calls for delegating this authority to individual vehicles, and as a result the communications with the infrastructure are reduced.
DOT funded a Feasibility Study of the VBSS concept in 2014 (completed by Oakridge National Laboratory, ORNL) and the first phase of study was completed in December, 2015.
Figure X depicts a high level comparison of the VBSS and SCMS architectures.
Under the VBSS concept, the Pseudonym Certificate Authority (PCA), Registration Authority (RA), Linkage Authorities (LAs) and Request Coordination, that are fundamental components in SCMS, are eliminated. VBSS establishes a Group Manager/Group Managers (GM) to provide credentials that make it possible for each vehicle to act as a certificate authority—an entity that can generate short-term certificates.
Each vehicle is a member of a group and is assigned a unique membership secret, a signing key. All member signing keys for a particular group are associated with a single group certificate. A vehicle generates its own ephemeral pseudonym certificates by signing the public key from a self-generated key pair with its group signing key; vehicles act as subordinate Certificate Authorities and pseudonyms are generated on demand based on travel requirements. Pseudonym verifiers use the group certificate to authenticate the pseudonym certificate, Start Printed Page 3955and then the pseudonym certificate to verify safety messages. The pseudonym generator remains anonymous, since the receiver uses a single group certificate to authenticate signatures made by all members from a particular group. Groups are managed by one or more infrastructure-based authorities. Members may be removed from groups by distributing information that allows participants to update their group credentials; this provides a means to revoke misbehaving vehicles since the pseudonyms they create will no longer be authenticated by vehicles that have updated their group credentials.
Use of pseudonyms (short-lived identifiers) and separation of distributed identifiers are the primary means of achieving an acceptable level of privacy. Within a VBSS, how groups are designed will also affect the preservation of individual privacy. As the number of distinct groups increases within a geographical area, privacy protection decreases; if every vehicle within a geographic area were in its own group (the extreme case); the group identifier becomes a unique vehicle identifier. This situation can be mitigated by ensuring group diversity is minimized regionally.
Misbehavior detection and reporting, and revocation are maintenance operations that are common to both SCMS and VBSS. There are misbehavior reporting alternatives discussed in SCMS security section of this proposal. In relation to misbehavior and revocation, VBSS may offer some advantages relative to managing communications associated with revoked vehicles. With SCMS, as the number of revoked vehicles grows—including those vehicles revoked because they are at the end of their useful life, the CRL list must also grow. NHTSA and its industry partners are investigating mechanisms for managing the size the CRL but nevertheless remains a challenge. With VBSS, instead of sending out CRLs to revoke vehicles, a Group Broadcast (GB) distributes group credential updates to participating vehicles; this occurs when a sufficient number of vehicle misbehavior reports have been validated resulting in one or more revocations; otherwise, group credentials do not change. With comparison to the SCMS using CRL list to remove compromised devices from the V2V communication system, the size of CRL will increase with the number of compromised devices, VBSS revocation mechanism's advantage is that the size of group credential updates will not increase with the number of compromised devices.
The Phase I study of VBSS and comparisons with other approaches suggests VBSS is feasible because group-based credentials provide a means to delegate infrastructure-based operations to vehicles in an effective way while facilitating the basic requirements of authentication, privacy, and maintenance of confidence. However, while Group-based signature schemes are an active area of research they are evolving and much less mature than other cryptographic systems. For this reason, VBSS remains in its preliminary stages.
NHTSA is continuing its research of the VBSS concept and is beginning a Phase II research Study in 2016. This work will focus on modeling a Group Manager and enhancing our understanding of the Group Manager software engineering requirements. NHTSA seeks comment on the viability of the VBSS certificate management approach including potential advantages and disadvantages relative to the SCMS approach. Specifically, we seek comment on the following:
—Could requirements to update an entire group's credentials (to enable revocation of selected vehicles) actually increase V2I communications during early deployment (versus distribution of a CRL)?
—Are there CRL distribution schemes that could limit, or otherwise manage, the growth of the CRL—particular as vehicles reach the end of their life and are place on the CRL?
—How will requirement to self-generate short-term certificates onboard the vehicle impact processing and memory requirements onboard the vehicle—as well as the need to provide high integrity hardware security modules to support such operations?
D. Multiple Root Authority Credential Management
U.S. DOT research, performed in partnership with European, Australian, and Japanese partners, has recognized that the world will evolve into a multi-root world and that crypto-agility will be a required capability as a response to increasing cybersecurity attacks.
While these capabilities are not required at the initiation of a connected, cooperative environment, they are useful technical and policy constructs to incorporate as the threat profile shifts and as the operational environment grows.
There are three potential paths to consider, all with advantages and disadvantages (we further note that these paths are not exclusive and that as the technologies evolve, they may converge):
(1) There is the path of establishing a single chain to the Root Authority that allows for devices/equipment or operational entities to become enrolled and implicitly trusted by the system. In such a system:
a. The Root Authority requires a significant level of security to ensure that it is not comprised.
b. The root authority can authorize intermediate certificate authorities which can support a diversity of operational parameters. However, all intermediate certificate authorities under a single root authority must operate with the allowable policies of the root authority.
c. There is a requirement for a mechanism to manage root authorities which is capable of transitioning the fundamental cryptographic elements if the Root Authority is compromised. This mechanism must be similarly as highly secured as the root authority and has the ability to revoke the compromised root and add a new root in a controlled and efficient way for all participants in the security system.
While allowing for some diversity of operational usage within the policies of the root, there is a minimum of interfaces between the root and other nodes, consequently, the threat surface remains smaller.
d. The mechanism for managing the root, although requiring (and incurring costs for) a high level of security, allows for orderly migration of the security system to incorporate root replacements and cryptographic improvements (as long as the devices within the system are capable of adopting such new cryptographic processes), thus future-proofing the overall system to the extent possible within known parameters.
This is the path that the US is taking to establish initial operations to support emerging connected vehicle environments.
(2) There is the path of establishing multiple, co-existing roots in which each Root Authority must have an agreement with other root authorities that describe an appropriate level of trust. Based on the trust level, a host of interfaces have to be enacted for data transfer that assures one operational root that the other operational root remains trusted. See the report titled, Start Printed Page 3956“Cooperative-ITS Credential Management System Functional Analysis and Recommendations for Harmonization Document HTG6-4 Version: 2015-09” 
for greater details on the trust levels and how to enact the trust levels from both a policy perspective as well as a data flow perspective.
A benefit to this path is that with multiple operational roots, if one is compromised, another root could potentially take over operations (although this is highly dependent upon the trust levels—if the other operating root that has to take over does not trust the credentials of the compromised root (even if the credentials in use are still valid and not compromised), then all actors enrolled in the compromised root will have to cease operations of the cooperative applications until they can be proven to be trusted actors and enrolled in the uncompromised root authority).
Understanding the different trust levels is the key to understanding whether there are benefits to a multiple root world. A key conclusion to the analysis on how to enact different trust levels is that adding even one additional root to the system increases the number of interfaces among entities which exponentially increases the attack surface of the inter-related systems. This model also increases costs of running different organizations, increases the costs associated with data analysis, and increases the costs of auditing and updating policies. In addition, it seems that agreement of common security policies under the initialization of parallel operational roots, operated by different organizations with different priorities, is likely to be very difficult, adversely affecting the level of trust that may be established among various root authorities.
Furthermore the Government will have no authority to compel one Root Authority to interface with another Root Authority. This would adversely affect interoperability given the equipment under the different roots would not interact in crash avoidance situations reducing the effectiveness of V2V. For example a group of OEMs could be covered under one Root Authority were as a group of aftermarket suppliers could be covered under a different Root Authority. If the OEM group decides that the aftermarket devices do not meet the OEM level of performance then no agreement would be implemented and equipment in the OEM group would not interact with equipment in the aftermarket group. This could create market disparity and reduce consumer choice.
(3) There is one additional path that is very similar to path #2, but also incorporates the use of different types of security credentials (or security certificates). The use of the NIST elliptical curve SHA-256 offers a significant advantage over other types of credentials in that it includes the lowest amount of overhead for an appropriate level of trust and authentication among vehicle moving at very high speeds.
This version of the model would allow for different credentials (such as “brainpool” or other curves) to also be used in operations. This version of the model significantly increases the complexity of the system. While it offers greater crypto-flexibility, having the ability to recognize and use different credentials will require that ALL equipment/devices/applications will have to be able to recognize and trust messages created with either type of credential in order to ensure continued interoperability. This path may increase the cost and complexity of equipment on the vehicle and/or change the nature of the equipment, as the receivers will have to recognize the different cryptographic technologies and perform additional/different validity checks for the different cryptographic technologies. Also, this capability/path is not yet proven and would need to be demonstrated under a number of conditions to ensure that the transactions and timing can still meet the safety applications requirements for latency of the exchange and scalability of the dedicated spectrum available for low-latency communications, such as the V2V Basic Safety Message.
This is the path that is under consideration within the European Union at this time.
All of these paths are, in some sense, multi-root in that it is necessary to have at least a back-up root as part of an internal system. The analysis of the different paths highlights some of the key issues that will need to be addressed as the future evolves:
- Security credentials: At some point, we can expect that the security credentials based upon the current cryptographic level will be broken due to quantum computing and that new security approaches and/or new cryptographic curves will be needed. Research is needed into new curves to ensure that new security approaches do not significantly increase the communications overhead in order support the latency requirements for V2V communications.
- Governance/Certificate Policies: New root management and recovery solutions will need to be developed as the initial, smaller connected vehicle environments evolve into more complicated, region-wide, overlapping environments that may operate at different levels of security. This has been addressed in the first path through the innovative creation of Root Electors that provide the ability to revoke a compromise Root and establish a new Root without having to re-initialize devices.
VI. What is the agency's legal authority to regulate V2V devices, and how is this proposal consistent with that authority?
A. What can NHTSA regulate under the Vehicle Safety Act?
NHTSA has broad statutory authority to regulate motor vehicles and items of motor vehicle equipment under the National Traffic and Motor Vehicle Safety Act (the “Safety Act”).
As applied in this context, the agency's authority includes all or nearly all aspects of a V2V system. Congress enacted the Safety Act in 1966 with the purpose of reducing motor vehicle crashes and deaths and injuries that occur as a result of motor vehicle crashes and non-operational safety hazards attributable to motor vehicles.
The Safety Act, as amended, is now codified at 49 U.S.C. 30101 et seq.
The vehicle technologies that enable vehicles to send messages to and receive messages from each other are vastly different from those that existed when the Safety Act was enacted. Then, the vehicle operating systems were largely mechanical and controlled by the driver via mechanical inputs and linkages. Components and systems were either designed into the vehicle at the time of original manufacture or were later Start Printed Page 3957attached to or physically carried into the vehicle. Sensing of a vehicle's performance and the roadway environment was done solely by the driver.
Today, in contrast, an increasing number of vehicle functions are electronic. These functions can be activated and controlled automatically and do not necessarily require driver involvement, unlike the mechanical functions of previous generations of vehicles. V2V technologies require no driver involvement in order to send and receive information that can be used for vehicle safety functions. Other ways in which V2V technologies differ from the mechanical technologies prevalent when the Safety Act was first enacted include the fact that how they operate can be substantially altered by post-manufacture software updates, and that advances in communications technology make it possible for nomadic devices with vehicle-related applications to be brought into the vehicle.
The language of the Safety Act, however, is broad enough to comfortably accommodate this evolution in vehicle technologies. NHTSA's statutory authority over motor vehicles and motor vehicle equipment would allow the agency to establish safety standards applicable both to vehicles that are originally manufactured with V2V communications devices, and to those devices added after original manufacture.
In the Safety Act, “motor vehicle” is defined as a “vehicle driven or drawn by mechanical power and manufactured primarily for use” on public roads.
The definition of “motor vehicle equipment,” as cited below, is broader and thus effectively establishes the limit of the agency's authority under the Safety Act:
(A) Any system, part, or component of a motor vehicle as originally manufactured;
(B) any similar part or component manufactured or sold for replacement or improvement of a system, part, or component, or as an accessory or addition to a motor vehicle; or
(C) any device or an article or apparel, including a motorcycle helmet and excluding medicine or eyeglasses prescribed by a licensed practitioner, that—
(i) is not a system, part, or component of a motor vehicle; and
(ii) is manufactured, sold, delivered, or offered to be sold for use on public streets, roads, and highways with the apparent purpose of safeguarding users of motor vehicles against risk of accident, injury, or death.
NHTSA's authority over these groups of items—(1) systems, parts, and components installed or included in a vehicle, (2) replacements and improvements to those systems, parts, and components, (3) accessories and additions to motor vehicles, and (4) devices or articles with an apparent safety-related purpose—is very broad. The status of these items as motor vehicle equipment does not depend on the type of technology or its mode of control (mechanical or electronic), or whether an item is tangible or intangible. The transition from mechanical to electromechanical systems has thus had no effect on the extent of NHTSA's authority over motor vehicle performance. NHTSA has regulatory authority under the Safety Act over all the systems, parts, and components installed on new motor vehicles, even as motor vehicle control systems become increasingly electronic, and perhaps increasingly automated, in the future.
Put in the context of V2V-related motor vehicle equipment, NHTSA considers the following items subject to the agency's regulatory authority:
(1) Any integrated original equipment (OE) used for V2V communications or safety applications reliant on V2V communications.
(2) Any integrated aftermarket equipment used for V2V communications or safety applications reliant on V2V communications, under 30102(a)(7)(B), if the equipment “improves” an already-existing function of the vehicle or is an “addition” to the vehicle.
(3) Some non-integrated aftermarket equipment, depending on its nature and apparent purpose, under 30102(a)(7)(B), if the equipment is a motor vehicle “accessory” (something to be used while the vehicle is in operation, that enhances that operation), or 30102(a)(7)(C), if the equipment is a device used for the apparent purpose of traffic safety (purpose would be clearly observable from the characteristics of the object and the context of its use, rather than necessarily defined by the manufacturer's intent for the equipment).
(4) Software that provides or aids V2V functions, and software updates to all of this equipment, because, under 30102(a)(7)(B), updates can be considered as replacements or improvements.
(5) Potentially some roadside infrastructure (V2I), under 30102(a)(7)(B) and (C), because if its apparent purpose is safety, it may be an “accessory” or a “device . . . manufactured . . . with the apparent purpose of safeguarding users of motor vehicles against accident, injury, or death.” We currently anticipate that only a small subset of roadside infrastructure may fall within this category.
A number of commenters to the ANPRM and Readiness Report raised issues with the agency's discussion of the bounds of its authority. While most commenters agreed that the agency has clear authority to require V2V communications devices in new vehicles and to regulate aftermarket V2V devices,
the Alliance argued that it appeared that the agency sought to regulate “the relationship between the vehicle manufacturers and their customers,” 
given that NHTSA had discussed the potential need for additional security certificates during a V2V communications device's lifetime, as well as the possibility of software updates as needed. The Alliance argued that the Safety Act did not authorize a “lifetime maintenance mandate” to cover the potential need to provide additional certificates or software updates.
Moreover, the Alliance argued, NHTSA could not require consumers to renew security certificates or accept downloaded certificates pushed directly to the vehicle, or to ensure that DSRC remained operable over the lifetime of the vehicle, and therefore a FMVSS would not be publicly accepted, and therefore inconsistent with the agency's authority Start Printed Page 3958under the Safety Act, because consumers might not be confident that DSRC would continue to work properly over the vehicle's lifetime.
The Alliance even suggested that it could violate the Computer Fraud and Abuse Act (18 U.S.C. 1030) to push new certificates to consumers without their consent.
In response, NHTSA agrees that we have authority under the Safety Act to require V2V communications devices in new vehicles and mandate specific aspects of their performance, and to require similar performance from aftermarket V2V devices designed to participate in the V2V system, as long as those standards are consistent with Safety Act requirements.
We disagree, however, with the points raised by the Alliance regarding certificate and software updates. At this time, NHTSA is not requiring that certificate and software updates be pushed to vehicles without consumers' consent—we are simply requiring that manufacturers alert consumers, via a telltale or message center indicator, to the fact that V2V will not work if they are out of certificates or in need of some other kind of update, and that devices be capable of receiving such updates.
Consumers will need to know what action the telltale or message center indicator is telling them to take in order to continue to obtain the safety benefits of V2V, so vehicle or device manufacturers will need to ensure either that the message center indicator is clear about the needed action and the consequences of not taking that action, or that the explanation for the message or telltale is contained somewhere (like the owner's information) where the consumer can easily find it and understand what to do. Alternatively, vehicle manufacturers could obtain consumer consent for automatic certificate and software updates at the time of first sale, although that consent would not cover subsequent vehicle owners. Even if manufacturers make it necessary for consumers to consent to each new download, NHTSA expects that the need to do so would be sufficiently infrequent and well-explained by vehicle manufacturers in order to ensure that consumers recognize the significant safety risk of failing to accept the download. We assume that, at this point in time, nearly all consumers are already well-accustomed to the need for software updates on their electronic devices, like computers and smartphones, and regularly accept and initiate such updates. We seek comment from manufacturers on how they plan to develop succinct and compelling explanations to accompany these consent requests that would encourage consumers to accept the updates in a timely manner. We also seek additional comment regarding all aspects of consumer consent.
Alternatively, if manufacturers are concerned that consumers would not accept new certificate downloads and would thereby lose the safety benefits of V2V communications, manufacturers could install V2V devices that are pre-loaded with all the certificates that the device would need over its lifetime. This approach would presumably necessitate more storage capacity on the V2V device (and thus more cost), and could also present a potentially bigger security risk if the device were somehow compromised. We seek comment on whether requiring devices to come pre-loaded with a lifetime's worth of certificates could be a better approach than requiring consumers to consent to (and obtain) new downloads, and if so, why.
Besides certificates, however, we expect that software associated with both the V2V communications device itself, and with any accompanying applications that rely on V2V communications for information, would likely need updating during the vehicle's lifetime. As explained above, as for certificate updates, we are proposing to require that manufacturers include a means to communicate to the driver if and when a software update is needed. If the driver then chooses not to accept the update, the system must continue to warn them that V2V functionality is not available. If manufacturers choose not to update software when issues with it are discovered, and safety problems result, NHTSA may choose to pursue those problems under its enforcement authority.
Some commenters disagreed with the agency's statements in the Readiness Report that our Safety Act authority extended to cover RSE.
The Alliance argued that RSE only indirectly served a safety purpose, because they would perform non-safety functions as well, and therefore could not be motor vehicle equipment. CTIA and others presented a similar argument regarding the agency's authority to regulate mobile devices and applications for mobile devices, as it has elsewhere.
With regard to the agency's authority under the Safety Act over RSE, although we are not proposing in this NPRM to regulate any RSEs, we disagree that a device that performs non-safety functions in addition to safety functions is necessarily not motor vehicle equipment. Tires, for example, perform the non-safety function of helping a vehicle travel down the road by creating friction between the wheel and the road, but that friction also plays a safety role by helping the vehicle stop rapidly when the driver hits the brakes. Brakes and steering wheels, for that matter, help drivers execute turns which may be necessary to reach their intended destination, but they also help drivers avoid crashing their vehicles. Many items of motor vehicle equipment that NHTSA regulates perform safety functions in addition to being generally necessary for the driving task. NHTSA can regulate those items insofar as they affect vehicle safety. By providing a link between the SCMS and the vehicle, and potentially being the mechanism by which the vehicle's V2V communications device is able to obtain new security certificates and information about which other vehicles to trust and not to trust, the RSE may play a vital role in creating the environment needed for safety. A BSM cannot be sent without a certificate, and a V2V communications device must not trust an untrustworthy partner vehicle, or safety applications may not function properly.
That said, NHTSA does not currently anticipate the need to specify requirements for the RSE that may participate in the overall V2V system. We note that FHWA has already issued specifications for roadside units that are publicly available,
and at this point, we would expect the ones participating in the overall V2V system and interacting with V2V-equipped vehicles to conform to these specifications, or to updated specifications if and when they exist. We seek comment on whether additional regulation of RSE/RSU by NHTSA might be important to ensure that, among other things, they do not collect information that could be unnecessarily harmful to privacy; pose no cybersecurity threat to the overall V2V system; or perform (or risk failing to perform) any other task that could be harmful to vehicles or the V2V system Start Printed Page 3959or in any way negatively impact safety benefits associated with V2V.
Thus, the agency believes that our existing Safety Act authority comfortably allows us to require V2V communications devices in new motor vehicles and aftermarket equipment. The following section examines what the Safety Act requires NHTSA to consider in developing an FMVSS, and how the proposal in this NPRM may meet those requirements.
B. What does the Vehicle Safety Act allow and require of NHTSA in issuing a new FMVSS, and how is the proposal consistent with those requirements?
Under the Safety Act, NHTSA's motor vehicle safety standards are generally performance-oriented.
Further, the standards are required to be practicable and objective, and to meet the need for safety.
The following paragraphs will discuss briefly the meaning of each of these requirements, and then explore how the agency believes that the proposal may meet those requirements.
In the Safety Act, the Secretary is directed to issue motor vehicle safety standards. “Motor vehicle safety standards” are defined as “minimum standard[s] for motor vehicle or motor vehicle equipment performance.” 
One point to note at the outset is the party of whom performance is required: NHTSA's safety standards apply to manufacturers of new motor vehicles and motor vehicle equipment. It therefore falls to those “manufacturers”—from vehicle OEMs to OE suppliers to aftermarket device manufacturers to creators of V2V safety applications—to certify compliance with any safety standards established by NHTSA, and to conduct recalls and remedy defects if NHTSA finds them.
Vehicle owners are not required to comply with NHTSA's safety standards, which means that for vehicles already on the roads, participation in the V2V system would be entirely voluntary: NHTSA can regulate how aftermarket devices function, but it cannot require manufacturers or drivers to add them to used vehicles. The one exception to this rule against retrofit is that NHTSA has authority to require retrofit of commercial heavy-duty vehicles,
but that is not part of this proposal on light-duty vehicles.
While NHTSA is directed to establish performance standards, the case law and the legislative history indicate that when necessary to promote safety, NHTSA can be quite specific in drafting its performance standards and may require or preclude the installation of certain equipment. The cases have reinforced this concept by determining that NHTSA is “generally charged” 
with setting performance standards, instead of becoming directly involved in questions of design.
The legislative history further illustrates that NHTSA's standards are to “[specify] the required minimum safe performance of vehicles but not the manner in which the manufacturer is to achieve the specified performance.” 
An example cited in the legislative history points to “a building code which specifies the minimum load-carrying characteristics of the structural members of a building wall, but leaves the builder free to choose his own materials and design.” 
In that example, the agency could require the wall to be built (analogous to requiring certain equipment in vehicles) but would be expected to measure the wall's regulatory compliance by its performance rather than its design.
Although the Safety Act directs NHTSA to issue performance standards, however, Congress understood that the agency may preclude certain designs through these performance standards. “Motor vehicle safety” is defined in the Safety Act as the performance of a motor vehicle in a way that protects the public from unreasonable risks of accident due to (among other things) the design of a motor vehicle.
The legislative history indicates that this language is not intended to afford the agency the authority to promulgate design standards, “but merely to clarify that the public is to be protected from inherently dangerous designs which conflict with the concept of motor vehicle safety.” 
This clarification is evidence that Congress recognized that performance standards inevitably have an impact on the design of a motor vehicle.
The courts have further elaborated on the framework established by Congress and have recognized that, when necessary to achieve a safety purpose, NHTSA can be quite specific in establishing performance standards even if certain designs will be precluded. For example, the Sixth Circuit found that an agency provision permitting rectangular headlamps, but only if they were of certain specified dimensions, was not an invalid design restriction and “serve[d] to ensure proper headlamp performance,” reasoning that “the overall safety and reliability of a headlamp system depends to a certain extent upon the wide availability of replacement lamps, which in turn depends upon standardization.” 
Thus, the court found it permissible for the agency to establish very specific requirements for headlamps even though it would restrict design flexibility.
Further, the cases indicate that NHTSA can establish standards to require the installation of certain specific equipment on vehicles and establish performance standards for that equipment. For example, the Tenth Circuit found in Washington v. DOT that “NHTSA's regulatory authority extends beyond the performance of motor vehicles per se, to particular items of equipment.” 
In that case, the validity of NHTSA's FMVSS No. 121 requiring ABS systems on air-braked vehicles was challenged as “imposing design specifications rather than Start Printed Page 3960performance criteria.” 
The court's conclusion was based not only on the fact that prior courts had upheld NHTSA's standards requiring particular equipment,
but also on the fact that Congress had recognized NHTSA's former rulemakings and left NHTSA's authority unchanged when it codified the Safety Act in 1994.
Thus, in summary, NHTSA is required to issue performance standards when regulating motor vehicles and motor vehicle equipment. However, NHTSA is able to be quite specific in establishing performance standards and may preclude certain designs that are contrary to the interests of safety. Further, NHTSA may require the installation of certain equipment and establish performance standards for that equipment.
As Section III.E discusses at length and as the regulatory text at the end of this preamble discusses at length, NHTSA has developed a set of proposed performance requirements for DSRC performance. These sections explain: (1) What information needs to be sent to the surrounding vehicles; (2) how the vehicle needs to send that information; (3) how a vehicle shows that it is a valid source of information; and (4) how a vehicle makes sure the prior three functions work in various operational conditions (i.e., broadcast under congested conditions, detect/report misbehavior, and obtain new security materials). The proposal draws from existing voluntary standards while also explaining why a particular threshold or requirements from a voluntary standard is appropriate. The proposal contains a mandatory Privacy Statement, set forth in Appendix A. Finally, the proposal includes a test method for evaluating many of these aspects of performance. Having a clear test method helps inform the public as to how the agency would evaluate compliance with any final FMVSS. While research is ongoing in a few areas (namely message congestion mitigation, explicit details for misbehavior detection, SCMS policies and procedures), we have described for the public the potential requirements that we are considering for an NPRM and the potential test methods for evaluating compliance with those requirements. We believe that the public comments that we will receive in response (coupled with the agency's ongoing research) will produce a robust record upon which the agency can make a final decision.
The provisions allowing alternative technologies to satisfy the mandate are performance-oriented, but do not specify a particular way of communicating. The goal of this is to maximize industry's ability to innovate and potentially employ future communication technologies that may be able to meet the performance requirements (like, for example, latency) for V2V-based safety warning applications. While alternative technologies would be subject to several aspects of the test procedures set forth for DSRC-based devices, it leaves open for industry to develop a number of aspects of performance, including interoperability with all other V2V communications technologies that transmit BSMs. We believe that the inclusion of some performance tests makes these provisions consistent with the Safety Act requirement of standards being “performance-oriented.” We seek comment on this tentative conclusion.
2. Standards “Meeting the Need for Motor Vehicle Safety”
As required by the Safety Act, standards issued by the agency must “meet the need for motor vehicle safety.” 
As “motor vehicle safety” is defined in the statute as protecting the public against “unreasonable risk” of accidents, death, or injury,
the case law indicates that there must be a nexus between the safety problem and the standard.
However, a standard need not address safety by direct means. In upholding NHTSA's authority to issue a safety standard requiring standardized vehicle identification numbers, the Fourth Circuit Court of Appeals found that an FMVSS requiring VINs met the need for motor vehicle safety by such indirect means as reducing errors in compiling statistical data on motor vehicle crashes (in order to aid research to understand current safety problems and support future standards, to increase the efficiency of vehicle recall campaigns, and to assist in tracing stolen vehicles).
We believe that there is a clear nexus between the safety problem and the proposals in this document. In the case of DSRC-based devices, DSRC can enable all of the safety applications under consideration by the agency, such as Intersection Movement Assist, Left Turn Assist, and Electronic Emergency Brake Light, which means that DSRC can help to address the safety problems of, e.g., intersection collisions, collisions with forward stopped or slowing vehicles, collisions that occur because a driver chose to pass a forward vehicle without enough room to do so safely, etc. For some of the other safety applications, which can also be enabled by other technologies besides DSRC, such as on-board sensors, radar, or cameras, DSRC can add robustness to an on-board system. DSRC will either be the sole enabler of some safety applications or present a possible enhancement to on-board systems with regard to other applications. In either case, DSRC will address safety needs.
Moreover, case law supports that DSRC need not directly create more safety itself, as long as it is enabling other safety applications. If VINs could be upheld as meeting the need for motor vehicle safety simply by virtue of the fact that they aid research in understanding safety problems and supporting future standards, as well as aiding recall campaigns and tracking of stolen vehicles, then DSRC, which would directly enable half a dozen safety applications at its inception and perhaps many more eventually, seems even more clearly to meet the need for safety in that respect.
Non-DSRC devices should have a similar nexus to the safety problem.
3. “Objective” Standards
A standard is objective if it specifies test procedures that are “capable of producing identical results when test conditions are exactly duplicated” and performance requirements whose satisfaction is “based upon the readings obtained from measuring instruments as opposed to subjective opinions.” 
The requirement that standards be stated in Start Printed Page 3961objective terms matches the overall statutory scheme requiring that manufacturers self-certify that their motor vehicles or motor vehicle equipment comply with the relevant FMVSSs.
In order for this statutory scheme to work, the agency and the manufacturer must be able to obtain the same result from identical tests in order to objectively determine the validity of the manufacturer's certification.
Using those two elements of objectivity (capable of producing identical results and compliance based on measurements rather than subjective opinion), the Sixth Circuit Court of Appeals found that the test procedure in question in an early version of FMVSS No. 208 was not objective because the test dummy specified in the standard for use in compliance testing did not give consistent and repeatable results.
The court in this case was unconvinced that the standard met the objectivity requirements even though NHTSA based its test procedure on a test dummy in a voluntary automotive industry standard (Society of Automotive Engineers Recommended Practice J963). The court rejected NHTSA's explanation that, although J963 “may not provide totally reproducible results,” “dummies conforming to the SAE specifications are the most complete and satisfactory ones presently available.” 
Further, the court rejected NHTSA's reasoning that, in the event that the agency's test results were different from those of the manufacturers because of the difference in the test dummies, NHTSA's test results would not be used to find non-compliance, stating that “there is no room for an [ ] agency investigation [ ] in this procedure” that enable the agency to compare results of differing tests.
Other courts have also reached similar conclusions. The Ninth Circuit Court of Appeals, relying on the same reasoning adopted by the Sixth Circuit, found that a compliance road test specifying the use of surfaces specifically rated with quantifiable numbers (defining the “slickness” of the surfaces) was objective despite “[t]he fact that it is difficult to create and thereafter maintain a road surface with a particular coefficient of friction,” which the court held “does not render the specified coefficient any less objective.” 
In this case, both NHTSA and the manufacturer would perform road tests on surfaces with identically rated friction coefficients.
In a later case, the Sixth Circuit upheld NHTSA's decision not to incorporate a test suggested by a commenter for wheelchair crashworthiness performed with a “test seat” that “shall be capable of resisting significant deformation” during a test as not sufficiently objective.
In the absence of language quantifying how much deformation is significant, terms such as “significant deformation” do not provide enough specificity to remove the subjective element from the compliance determination process.
As discussed above, under the proposal, we have developed and are proposing performance requirements, including compliance test procedures, for DSRC. We will continue evaluating the compliance test procedures further and receiving public input during the comment period that can assist us in fine-tuning the procedures and ensuring that they meet our statutory requirements. For alternative technologies, given that the testing to this point that led to the development of the test procedures for interoperability did not evaluate the use of non-DSRC communication technologies, we seek comment on how the regulatory text alternative technologies can achieve interoperability in an objective manner.
4. “Practicable” Standards
In general, the practicability of a given standard involves a number of considerations. The majority of issues concerning the practicability of a standard arise out of whether the standard is technologically and economically feasible. An additional issue is whether the means used to comply with a standard will be accepted and correctly used by the public.
First, significant technical uncertainties in meeting a standard might lead a court to find that a standard is not practicable. For example, the Sixth Circuit Court of Appeals upheld NHTSA's decision to amend FMVSS No. 222 to include requirements for wheelchair securement and occupant restraint on school buses with a static 
compliance test instead of a dynamic test,
noting that the administrative record showed that this particular dynamic test was underdeveloped and had many unresolved technical problems.
The court noted that it is not practicable “[t]o attempt to fashion rules in an area in which many technical problems have been identified and no consensus exists for their resolution . . . .” 
In another example, the Ninth Circuit Court of Appeals found a compliance test procedure using a specified friction (slickness) coefficient to be impracticable due to technical difficulties in maintaining the specific slickness test condition. As mentioned Start Printed Page 3962above, the Ninth Circuit found the specified coefficient test condition to be objective.
However, simply being objective did not also make the test condition practicable. Thus, the cases show that when significant technical uncertainties and difficulties exist in a standard promulgated by NHTSA, those portions of the standard can be considered impracticable under the Safety Act.
However, the requirement that a standard be technologically feasible does not include the additional requirement that the agency show that the technology to be used to comply with the standard is already fully developed and tested at the time that the standard is promulgated. The Sixth Circuit upheld a NHTSA standard requiring “Complete Passive Protection,” that required the installation of airbags as standard equipment by a future date, rejecting petitioner's contention that NHTSA may only establish performance requirements which can be met with devices which, at the time of the rulemaking, are developed to the point that they may be readily installed.
Relying on the legislative history of the Safety Act, the court found that the agency “is empowered to issue safety standards which require improvements in existing technology or which require the development of new technology, and is not limited to issuing standards based fully on devices already developed.” 
Thus, the requirement that standards be technologically feasible is sufficiently broad that it can be satisfied by showing that new technology can be developed in time to comply with the effective date of the standard.
Second, a standard can be considered impracticable by the courts due to economic infeasibility. This consideration primarily involves the costs imposed by a standard.
In the instances in which a court has been called upon to assess whether a standard is economically feasible, typically with respect to an industry composed largely of relatively small businesses, the courts have asked whether or not the cost would be so prohibitive that it could cause significant harm to a well-established industry. In essence, this consideration generally establishes a non-quantified outer limit of the costs that can be reasonably imposed on regulated entities. If compliance with the standard is so burdensome, i.e., costly, so as to create a significant harm to a well-established industry, courts have generally found that the standard is impracticable in its application to that industry.
Finally, a standard might not be considered practicable if the public were not expected to accept and correctly use the technologies installed in compliance with the standard. When considering passive restraints such as automatic seatbelts, the D.C. Circuit stated that “the agency cannot fulfill its statutory responsibility [in regard to practicability] unless it considers popular reaction.” 
While the agency argued in that case that public acceptance is not one of the statutory criteria that the agency must apply, the court disagreed. The court reasoned that “without public cooperation there can be no assurance that a safety system can `meet the need for motor vehicle safety.' ” 
Thus, as a part of the agency's considerations, a standard issued by the agency will not be considered practicable if the technologies installed pursuant to the standard are so unpopular that there is no assurance of sufficient public cooperation to meet the safety need that the standard seeks to address.
We believe that the proposal is consistent with these requirements. Technologically, DSRC has existed for over a decade, and is currently