82 FR 3854 - Federal Motor Vehicle Safety Standards; V2V Communications
DEPARTMENT OF TRANSPORTATION National Highway Traffic Safety Administration
Federal Register Volume 82, Issue 8 (January 12, 2017)
Page Range
3854-4019
FR Document
2016-31059
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.
Federal Register, Volume 82 Issue 8 (Thursday, January 12, 2017)
[Federal Register Volume 82, Number 8 (Thursday, January 12, 2017)]
[Proposed Rules]
[Pages 3854-4019]
From the Federal Register Online [www.thefederalregister.org]
[FR Doc No: 2016-31059]
[[Page 3853]]
Vol. 82
Thursday,
No. 8
January 12, 2017
Part II
Department of Transportation
-----------------------------------------------------------------------
National Highway Traffic Safety Administration
-----------------------------------------------------------------------
49 CFR Part 571
Federal Motor Vehicle Safety Standards; V2V Communications; Proposed
Rule
Federal Register / Vol. 82 , No. 8 / Thursday, January 12, 2017 /
Proposed Rules
[[Page 3854]]
-----------------------------------------------------------------------
DEPARTMENT OF TRANSPORTATION
National Highway Traffic Safety Administration
49 CFR Part 571
[Docket No. NHTSA-2016-0126]
RIN 2127-AL55
Federal Motor Vehicle Safety Standards; V2V Communications
AGENCY: National Highway Traffic Safety Administration (NHTSA),
Department of Transportation (DOT).
ACTION: Notice of Proposed Rulemaking (NPRM).
-----------------------------------------------------------------------
SUMMARY: 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.
DATES: Comments must be received on or before April 12, 2017.
ADDRESSES: 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.
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: [email protected]. 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 protected].
SUPPLEMENTARY INFORMATION:
Table of Contents
I. Executive Summary
II. Background
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
7. Cybersecurity
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
2. Privacy
3. Hacking (Cybersecurity)
4. Health
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
1. Overview
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
7. Conclusion
V. Device Authorization
A. Approaches to Security Credentialing
B. Federated Security Credential Management (SCMS)
1. Overview
2. Technical Design
3. Independent Evaluation of SCMS Technical Design
4. SCMS RFI Comments and Agency Responses
[[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?
1. ``Performance-Oriented''
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?
1. SCMS
2. Liability
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
3. Summary
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
B. Aftermarket
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
[[Page 3856]]
and 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.\1\
---------------------------------------------------------------------------
\1\ Equipping vehicles with V2V could also lead to deployment of
connectivity hardware that could potentially be used for other
applications, such as connectivity with roadway infrastructure (V2I)
and with pedestrians (V2P). These technologies (collectively
referred to as ``V2X'') could increase the vehicle's awareness of
its surroundings and enable additional applications. We do not
consider these other potential applications here.
---------------------------------------------------------------------------
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.\2\
---------------------------------------------------------------------------
\2\ This analysis for this proposal focuses on the benefits
resulting from the implementation of safety applications that are
projected to reduce vehicle crashes. The agency did not incorporate
any potential benefits from the anticipated expanded use of DSRC for
mobility and envirionment benefits. A list of potential mobility and
environment applications can be found at http://www.its.dot.gov/pilots/cv_pilot_apps.htm (last accessed: Dec 7, 2016).
---------------------------------------------------------------------------
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
[[Page 3857]]
being 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:
Communication Technology
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.
Message Authentication
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.
Hardware Security
NHTSA proposes that V2V equipment be ``hardened'' against intrusion
(FIPS-140 Level 3) by entities attempting to steal its security
credentials.
Effective Date
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.
Safety Applications
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.
Authority
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.
[[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'' \3\ to an individual.
Additionally, the proposal contains specific privacy and security
requirements with which manufacturers would be required to comply.
---------------------------------------------------------------------------
\3\ NHTSA intends for the term ``reasonably linkable,'' as used
in this NPRM, to have the same meaning as the term ``as a practical
matter linkable'' as used in the definition of ``personal data'' in
Section 4 of the White House Consumer Privacy Bill of Rights: ``data
that are under the control of a covered entity, not otherwise
generally available to the public through lawful means, and are
linked, or as a practical matter linkable by the covered entity, to
a specific individual, or linked to a device that is associated with
or routinely used by an individual.'' https://www.whitehouse.gov/sites/default/files/omb/legislative/letters/cpbr-act-of-2015-discussion-draft.pdf (last accessed Dec 7, 2016). The Federal Trade
Commission also uses the concept of '' linked or reasonably
linkable'' as a suggested definition of personally identifiable
information in its recent comment to the Federal Communications
Commission at https://www.ftc.gov/system/files/documents/advocacy_documents/comment-staff-bureau-consumer-protection-federal-trade-commission-federal-communications-commission/160527fcccomment.pdf (last accessed Dec 7, 2016).
---------------------------------------------------------------------------
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.
[[Page 3859]]
Table I-1--Costs * and Benefits in Year 30 of Deployment
[2051]
----------------------------------------------------------------------------------------------------------------
Monetary
Total annual costs Per vehicle Crashes prevented and lives benefits
costs saved (billions)
----------------------------------------------------------------------------------------------------------------
$2.2 billion-$5.0 billion..................... $135-$301 Crashes: 424,901-594,569........ $53-$71
Lives: 955-1,321................
----------------------------------------------------------------------------------------------------------------
* 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.
Regulatory Alternatives
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.
II. Background
A. The Safety Need
Safety technology has developed rapidly since NHTSA began
regulating the auto industry \4\--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.\5\ 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,\6\ to
32,675 fatalities in 2015--a 38 percent reduction.\7\
---------------------------------------------------------------------------
\4\ NHTSA was established by the Highway Safety Act of 1970, as
the successor to the National Highway Safety Bureau, to carry out
safety programs under the National Traffic and Motor Vehicle Safety
Act of 1966 and the Highway Safety Act of 1966. NHTSA also carries
out consumer programs established by the Motor Vehicle Information
and Cost Savings Act of 1972.
\5\ Kahane, C. J. (2015, January). Lives saved by vehicle safety
technologies and associated Federal Motor Vehicle Safety Standards,
1960 to 2012--Passenger cars and LTVs--With reviews of 26 FMVSS and
the effectiveness of their associated safety technologies in
reducing fatalities, injuries, and crashes. (Report No. DOT HS 812
069). Washington, DC: National Highway Traffic Safety
Administration.
\6\ National Highway Traffic Safety Administration, Traffic
Safety Facts 2012. Available at http://www-nrd.nhtsa.dot.gov/Pubs/812032.pdf (last accessed Dec. 7, 2016).
\7\ National Highway Traffic Safety Administration, Fatality
Analysis Report System (FARS) final 2014 data. For more information,
see http://www-fars.nhtsa.dot.gov/Main/index.aspx (last accessed Dec
7, 2016).
---------------------------------------------------------------------------
[[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.\8\ 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.\9\ 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.
---------------------------------------------------------------------------
\8\ For more information, see the agency policy statement on
automated vehicles at http://www.nhtsa.gov/staticfiles/rulemaking/pdf/Automated_Vehicles_Policy.pdf (last accessed Dec 7, 2016).
\9\ See https://www.nhtsa.gov/About-NHTSA/Press-Releases/nhtsa_iihs_commitment_on_aeb_03172016 (last accessed Dec 7, 2016).
---------------------------------------------------------------------------
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),\10\ 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 \11\
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 \12\
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.
---------------------------------------------------------------------------
\10\ MAIS (Maximum Abbreviated Injury Scale) approach, which
represents the maximum injury severity of an occupant at an
Abbreviated Injury Scale (AIS) level. AIS is an anatomically based,
consensus-derived global severity scoring system that classifies
each injury by body region according to its relative importance to
fatality on a 6-point ordinal scale (1=minor, 2=moderate, 3=serious,
4=severe, 5=critical, and 6=maximum (untreatable). The AIS was
developed by the Association for the Advancement of Automotive
Medicine (AAAM). See https://www.aaam.org/abbreviated-injury-scale-ais/ (last accessed Dec 7, 2016) for more information.
\11\ 2014 GES and FARS data was not available at the time of
NPRM development.
\12\ GES and FARS only record the police-reported crash severity
scale known as KABCO: K=fatal injury, A=incapacitating injury,
B=non-incapacitating injury, C=possible injury, O=no injury. These
KABCO injuries then were converted to MAIS scale through a KABCO-
MAIS translator. The KABCO-MAIS translator was established using
1982-1986 NASS (old NASS) and 2000-2007 Crashworthiness Data System
(CDS). Old NASS and CDS recorded both KABCO and MAIS scales thus
enable us to create the KABCO-translator.
---------------------------------------------------------------------------
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.\13\
---------------------------------------------------------------------------
\13\ Costs are in 2014 dollars and, for clarity, include the
economic costs. See Blincoe, L.J., Miller, T.R., Zaloshnja, E., &
Lawrence, B.A. (2014, May), The economic and societal impact of
motor vehicle crashes, 2010, (Report No. DOT HS 812 013),
Washington, DC: National Highway Traffic Safety Administration
(Revised, May, 2015), available at: http://www-nrd.nhtsa.dot.gov/pubs/812013.pdf (last accessed Dec 7, 2016).
---------------------------------------------------------------------------
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,\14\ 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.
---------------------------------------------------------------------------
\14\ Light vehicles include passenger cars, vans, minivans,
sport utility vehicles, crossover utility vehicles and light pickup
trucks with a gross vehicle weight rating (GVWR) less than or equal
to 10,000 pounds.
---------------------------------------------------------------------------
[[Page 3861]]
[GRAPHIC] [TIFF OMITTED] TP12JA17.000
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.\15\ 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.
---------------------------------------------------------------------------
\15\ Najm, W.G., R. Ranganathan, G. Srinivasan, J. Smith, S.
Toma, E. Swanson, and A. Burgett, ``Description of Light Vehicle
Pre-Crash Scenarios for Safety Applications Based on Vehicle-to-
Vehicle Communications.'' DOT HS 811 731, U.S. Department of
Transportation, National Highway Traffic Safety Administration, May
2013. http://www.nhtsa.gov/Research/Crash-Avoidance/Vehicle%E2%80%93to%E2%80%93Vehicle-Communications-for-Safety (last
accessed Dec 8, 2016) see also Najm, W.G., J. Smith, and M.
Yanagisawa, ``Pre-Crash Scenario Typology for Crash Avoidance
Research.'' DOT HS 810 767, U.S. Department of Transportation,
National Highway Traffic Safety Administration, April 2007. Najm,
W.G., B. Sen, J.D. Smith, and B.N. Campbell, ``Analysis of Light
Vehicle Crashes and Pre-Crash Scenarios Based on the 2000 General
Estimates System.'' DOT HS 809 573, U.S. Department of
Transportation, National Highway Traffic Safety Administration,
November 2002. Available at http://www.nhtsa.gov/Research/Crash-Avoidance/Vehicle%E2%80%93to%E2%80%93Vehicle-Communications-for-Safety (last accessed Dec 8, 2016).
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.
[[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.
37. Other.
------------------------------------------------------------------------
[GRAPHIC] [TIFF OMITTED] TP12JA17.001
The 10 priority pre-crash scenarios listed in Table II-2 can be
addressed by the corresponding V2V-based safety applications.
---------------------------------------------------------------------------
\16\ Average of 2010-2013-GES data; * Includes only 2&3 vehicle
crashes; ** Includes running red-light and running stop sign.
Table II-2--Pre-Crash Scenario/Safety Application Association
------------------------------------------------------------------------
Associated safety
Pre-crash scenarios Pre-crash groups 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 Junction Intersection Movement
Signal. Crossing. Assist.
Left-Turn Across Path/ Left Turn @ Left Turn Assist.
Opposite Direction. crossing.
Opposite Direction/No Opposite Do Not Pass Warning.
Maneuver. Direction.
Opposite Direction/Maneuver.. Opposite Do Not Pass Warning.
Direction.
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.\17\ These
safety warning applications were (1) Forward Collision Warning (FCW),
(2) Emergency Brake
[[Page 3863]]
Light (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.
---------------------------------------------------------------------------
\17\ The Connected Vehicle Safety Pilot (``Safety Pilot'')
Program was a scientific research initiative that features a real-
world implementation of connected vehicle safety technologies,
applications, and systems using everyday drivers. The effort will
test performance, evaluate human factors and usability, observe
policies and processes, and collect empirical data to present a more
accurate, detailed understanding of the potential safety benefits of
these technologies. The Safety Pilot program includes two critical
test efforts--the Safety Pilot Driver Clinics and the Safety Pilot
Model Deployment. See http://www.its.dot.gov/research_archives/safety/cv_safetypilot.htm for more information. (last accessed Dec
7, 2016).
---------------------------------------------------------------------------
(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
--------------------------------------------------------------------------------------------------------------------------------------------------------
Economic
V2V Safety applications--crashes Crash scenarios Crashes MAIS 1-5 Fatalities PDOVs costs Comprehensive
injuries (billion) costs (billion)
--------------------------------------------------------------------------------------------------------------------------------------------------------
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
----------------------------------------------------------------------------------
Total...................... 1,488,094 751,953 562 106,712 $41.5 $101.6
==================================================================================
IMA Intersection Crossing Crashes....... Turn-Into Path, Into Same 425,145 218,852 472 48,423 $12.6 $34.8
Direction or Opposite
Direction.
Straight Cross Path........ 346,187 251,488 1,399 66,580 $14.4 $49.4
----------------------------------------------------------------------------------
Total...................... 771,332 470,340 1,871 115,003 $26.9 $84.3
==================================================================================
LTA Left-Turning Crashes................ Turn Across Path, Initial 298,542 224,336 613 64,233 $11.7 $37.9
Opposite Direction.
BS/LCW Lane Change/Merge Crashes........ Vehicle Changing Lane, Same 475,097 175,044 397 20,816 $11.4 $26.6
Direction.
Others.................................. 378,659 192,152 3,882 4,416,890 $16.7 $66.4
----------------------------------------------------------------------------------
Total............................... ........................... 3,411,724 1,813,825 7,325 4,723,654 $108.2 $316.8
--------------------------------------------------------------------------------------------------------------------------------------------------------
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
[[Page 3864]]
designed 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.\18\
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),\19\ Blind Spot Warning (BSW), and Lane Change Warning (LCW).\20\
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.
---------------------------------------------------------------------------
\18\ A LIDAR device detects distant objects and determines their
position, velocity, or other characteristics by analysis of pulsed
laser light reflected from their surfaces. Lidar operates on the
same principles as radar and sonar.
\19\ FCW warns the driver of an impending rear-end collision
with a vehicle ahead in traffic in the same lane and direction of
travel.
\20\ BSW and LCW technologies warn the driver during a lane
change attempt if the zone into which the driver intends to switch
to is, or will soon be, occupied by another vehicle traveling in the
same direction. The technology also provides the driver with
advisory information that a vehicle in an adjacent lane is
positioned in his/her vehicle's ``blind spot'' zone even when a lane
change is not being attempted.
---------------------------------------------------------------------------
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,\21\ 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.
---------------------------------------------------------------------------
\21\ ``Vehicle-to-Vehicle Communications: Readiness of V2V
Technology for Application'', August 2014, pp. 105.
---------------------------------------------------------------------------
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),\22\ Do Not Pass Warning (DNPW),\23\ and
BSW/LCW safety applications, all of which can benefit from, or require,
information on turn signal status or steering wheel angle.
---------------------------------------------------------------------------
\22\ LTA warns the driver of a vehicle, when entering an
intersection, not to turn left in front of another vehicle traveling
in the opposite direction. LTA applications currently trigger only
when the driver activates the turn signal.
\23\ DNPW warns the driver of a vehicle during a passing
maneuver attempt when a slower-moving vehicle, ahead and in the same
lane, cannot be safely passed using a passing zone that is occupied
by vehicles travelling in the opposite direction. The application
may also provide the driver an advisory warning that the passing
zone is occupied when a passing maneuver is not being attempted.
---------------------------------------------------------------------------
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.\24\ 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.
---------------------------------------------------------------------------
\24\ Such a device could still be useful to users, because it
would alert other drivers to the presence of their vehicle (i.e., it
would help them be ``seen better'').
---------------------------------------------------------------------------
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
[[Page 3865]]
not 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,\25\ and high costs stemming from
cellular data costs and fitting new vehicles with cellular capability.
---------------------------------------------------------------------------
\25\ BAH CDDS Final Report. See Docket No. NHTSA-2014-0022.
---------------------------------------------------------------------------
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.\26\
---------------------------------------------------------------------------
\26\ BAH CDDS Final Report. See Docket No. NHTSA-2014-0022.
---------------------------------------------------------------------------
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.\27\
---------------------------------------------------------------------------
\27\ ``Organizational and Operational Models for the Security
Credentials Management System (SCMS); Industry Governance Models,
Privacy Analysis, and Cost Updates,'' dated October 23, 2013,
prepared by Booz Allen Hamilton under contract to DOT, non-
deliberative portions of which may be viewed in docket: NHTSA-2014-
0022.
---------------------------------------------------------------------------
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.\28\ Cost concerns and potential security risks are also
inherent to DSRC technology.
---------------------------------------------------------------------------
\28\ Report and Order FCC-03-0324.
---------------------------------------------------------------------------
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.'' \29\ 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.
---------------------------------------------------------------------------
\29\ The process of calculating one's position, especially at
sea, by estimating the direction and distance traveled rather than
by using landmarks, astronomical observations, or electronic
navigation methods.
---------------------------------------------------------------------------
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
[[Page 3866]]
point 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.
[[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.\31\
---------------------------------------------------------------------------
\31\ See Section II.B of the Readiness Report, available at
http://www.safercar.gov/v2v/ (last accessed Dec 7, 2016).
---------------------------------------------------------------------------
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
[[Page 3868]]
be finalized and issued.\32\ 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).
---------------------------------------------------------------------------
\32\ See, e.g., Nodine et al., ``Independent Evaluation of
Light-Vehicle Safety Applications Based on Vehicle-to-Vehicle
Communications Used in the 2012-2013 Safety Pilot Model
Deployment,'' USDOT Volpe Center, DOT HS 812 222, December 2015.
Available at Docket NHTSA-2016-0126.
---------------------------------------------------------------------------
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.\33\ 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.
---------------------------------------------------------------------------
\33\ The benefits estimated for this proposal vary from those
developed for the V2V Readiness Report. Please refer to Section VII
for details on the costs and benefits of this proposal.
---------------------------------------------------------------------------
(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.\34\ 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.
---------------------------------------------------------------------------
\34\ See Revision of Part 15 of the Commission's Rules to Permit
Unlicensed National Information Infrastructure (U-NII) Devices in
the 5 GHz Band, Notice of Proposed Rulemaking, ET Docket No. 13-49
(Feb. 2013). Under the FCC Part 15 rules U-NII devices cannot cause
interference to DSRC operations and must accept interference from
DSRC operations.
---------------------------------------------------------------------------
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
[[Page 3869]]
communication 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.\35\ 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.
---------------------------------------------------------------------------
\35\ ``Development of DSRC Device and Communication System
Performance Measures'' Booz Allen Hamilton, Final Report--May, 2016;
FHWA-JPO-17-483 available at http://ntl.bts.gov/lib/60000/60500/60536/FHWA-JPO-17-483.pdf (last accessed Dec 12, 2016) and, CAMP
research supporting SAE J2945-1, ``On-Board System Requirements for
V2V Safety Communications'' April, 2016.
---------------------------------------------------------------------------
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).\36\
---------------------------------------------------------------------------
\36\ Section II.F discusses NHTSA's Request for Information
(RFI) regarding the development of a potential Security Credential
Management System (SCMS).
---------------------------------------------------------------------------
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.\37\
---------------------------------------------------------------------------
\37\ As follow-up to other consumer acceptance topics, the
agency undertook additional consumer acceptance research (both
qualitative and quantitative) to better understand potential
consumer concerns. This research was used to directly inform this
proposal. See Section III for discussion of this research and how
the agency used it to develop this proposal.
---------------------------------------------------------------------------
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.
[[Page 3870]]
Table II-4--DSRC Performance Requirements and Compliance Testing Research
[NPRM RELEVANT]
----------------------------------------------------------------------------------------------------------------
Research projects
Readiness report research need Description initiated to Description Completion date
address
----------------------------------------------------------------------------------------------------------------
Standards Need V-1 SAE Standards Currently Crash Avoidance Crash Avoidance April 2016.
Maturity. Standards are Metrics Metrics
being developed Partnership V2V Partnership
by outside Interoperability providing results
standards and V2V System of DSRC device
organizations. Engineering performance
Projects. requirements to
SAE standards
development
committee for SAE
J2735 and J2945.
Research Need V-2 Impact of [V-2] V2V device DSRC On-Board Unit BAH project will BAH Completion
Software Implementation on DSRC software updates Performance Develop date--Requirement
Device Performance. may be required Measures Booze performance s October 2015/
over its Allen and measures for Test Procedures
lifecycle. NHTSA Hamilton. Dedicated Short October 2015.
will need to Crash Avoidance Range CAMP System
determine how to Metrics Communication Engineering
ensure necessary Partnership--Docu (DSRC) device; Completion date--
V2V device mentation of On- and develop Requirements Aug
software updates Board Unit security 2015/Test
are seamless for Requirements and performance Procedures Sept
consumers and Certification measures for the 2015.
confirmed. Procedures for following, but
V2V Systems not limited to
(System Critical
Engineering components on the
Project). DSRC device,
and............... Firmware on the
V2V-Comminication DSRC device,
Research project. Predominant
elements in a
Public Key
Infrastructure
(PKI).
Research Need V-3 DSRC Data [V-3] The purpose .................. .................. CAMP
Communication System of this research Communications
Performance Measures. is to finalize research
the operational completion date--
modes and August 2016.
scenarios, key
functions, and
qualitative
performance
measures that
indicate minimum
operational
performance to
support DSRC
safety and
security
communication
functions.
Research Need V-5 BSM Congestion [V-5] Complete .................. CAMP will develop
Sensitivity. congestion a single
mitigation and comprehensive
scalability document
research to summarizing the
identify minimum level of
bandwidth Connected Vehicle
congestion (CV) V2V safety
conditions that system on-board
could impair requirements and
performance of certification
safety or other procedures..
applications, and
develop
appropriate
mitigation
approaches.
Research Need V-6 Relative [V-6] Research .................. CAMP V2V
Positioning Performance Test. will be required Communications
to determine how Research Project
to test relative will identify
positioning requirement in
performance relation to BSM
across GPS message
receivers congestion
produced by mitigation and
different misbehavior
suppliers and detection.
yield a
generalized
relationship
between relative
and absolute
positioning.
Research Need V-7 Vehicle and [V-7] Research to
Receiver Positioning Biases. understand
potential
erroneous
position
reporting due to
positional biases
across multiple
GPS receiver
combinations.
Research Need VI-7 Compliance [VI-7] Development
Specifications and Requirements. 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
[NPRM RELEVANT]
----------------------------------------------------------------------------------------------------------------
Research projects
Readiness report research need Description initiated to Description Completion date
address
----------------------------------------------------------------------------------------------------------------
Policy Need IV-1 Road Side NHTSA will Authority .................. Issuance of NPRM.
Equipment Authority. evaluate the need evaluation
for DOT to conducted for
regulate aspects NPRM.
of RSE operation
and assess its
authority for
doing so.
[[Page 3871]]
Policy Need IV-2 V2V Device V2V device Crash Avoidance The System Completion Date
Software Updates. software updates Metrics Engineering for Requirements--
may be required Partnership V2V project will Sept 2015.
over its System investigate
lifecycle. NHTSA Engineering software update
will need to project and Crash requirements from
determine how to Avoidance Metrics the vehicle
ensure necessary Partnership perspective as
V2V device Security the Security
software updates Credential Credential
are seamless for Management System Management
consumers and Proof of Concept Systems project
confirmed. project. investigates
software update
from the security
system
perspective. Both
projects will
identify
requirements that
will facilitate
the software
update of V2V
devices.
Research Need V-1 Spectrum Evaluate the Testing spectrum A test plan for The evaluation of
Sharing Interference. impact of sharing testing spectrum sharing
unlicensed U-NII feasibility. unlicensed interference is
devices on the devices that pending the
transmission and would share the conduct of tests
reception of band with with
safety critical licensed DSRC representative U-
warnings in a devices has been NII-4 devices
shared spectrum developed. The that operate in
environment. testing will the 5.9 GHz
evaluate the (DSRC) frequency
feasibility of band.Testing
sharing spectrum could be
with unlicensed completed within
devices. 12 months of
receipt of
prototype
devices.
Research Need VII-1 Consumer Supplement the V2V Crash This review needs September 2015.
Acceptance. driver acceptance Avoidance Safety to extend the
analysis Technology Public current
completed per the Acceptance Review. evaluation of
Driver Clinics driver acceptance
and Safety Pilot to a broader
Model Deployment public acceptance
with further context and
research that evaluate how
includes a public acceptance
focused may impact and or
assessment of influence the
privacy in design,
relation to V2V performance,
technology. operation, and
implementation of
this technology.
Research Need VIII-1 V2V [VIII-1] Assess Independent The objective of March 2016.
Location Tracking via BSM. the availability Evaluation of V2V this Task Order
of information Security Design is to perform:
and technologies and Technical (1) an
that facilitate Analysis of the independent and
linking data in Potential Privacy comprehensive
the BSM to Risk of V2V technical
determine a motor Systems. analysis of the
vehicle's path. 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.
Research Need VIII-2 V2V [VIII-2]
Identification Capabilities. 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 [VIII-3] Inventory
Inventory of Privacy Controls. and assess the
privacy controls
applicable to the
SCMS in
connection with
our comprehensive
privacy
assessment.
Research Need VIII-4 V2V Privacy [VIII-4] A
Risk Assessment. 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.
[[Page 3872]]
Research Need IX-2 Cryptographic [IX-2] The chosen
flexibility. 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 [IX-3] Independent
Security Design Assessment. 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 Development of the Crash Avoidance The CAMP System Initial
Authority. processes, Metrics engineering Misbehavior
algorithms, Partnership project will Detection
reporting System investigate the information to be
requirements, and Engineering implementation completed
data requirements project, Security and device December 2015.
for both local Credential requirements for
and global Management Proof local (vehicle
detection of Concept based)
functions; and project, and misbehavior
procedures to Communication detection and
populate and Research Project. global (system-
distribute the wide) misbehavior
CRL. 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.
----------------------------------------------------------------------------------------------------------------
Table II-6--V2V Safety Application Improvement and Performance Verification Research
[NPRM IRRELEVANT]
----------------------------------------------------------------------------------------------------------------
Research projects
Readiness report research need Description initiated to Description Completion date
address
----------------------------------------------------------------------------------------------------------------
Research Need V-4 Development of [V-4] This Volpe False Alert The Volpe project Volpe Completion
Safety Application Test Metrics research will Scenarios and will support Date--December
and Procedures. take the Objective Test NHTSA development 2018.
Research Need VI-2 Safety performance Procedures for of false-positive VRTC Completion
Application Performance Measure measures and Crash Avoidance warning objective Date--April 2019.
Rationale. objective test Applications test procedures
procedures used project and in conjunction
during the Vehicle Research with development
research of V2V and Test Center of objective test
applications and project. procedures and
develop FMVSS performance
level performance criteria for IMA,
measures and LTA, FCW, and BS/
safety LCW applications.
application The results of
objective tests. this IAA will
contribute to
potential Federal
Motor Vehicle
Safety Standards
(FMVSS) for these
crash avoidance
applications.
Research Need VI-3 [VI-1] Assess the .................. The VRTC project
Practicability of Non-Ideal capability and will incorporate
Driving Condition Testing. capacity of results and
possible information from
refinements to the Volpe project
reduce frequency to develop
of false positive Federal Motor
warning while Vehicle Safety
maintaining crash Standards (FMVSS)
avoidance for these crash
effectiveness. avoidance
applications.
[VI-2] Develop a
rationale to
support each
performance and
test metric
recommended for
incorporation
into an FMVSS.
[[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- [VI-4] Develop
Fused V2V Safety Application test procedures
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 [VI-5] Conduct
and Test Metric Validation. test validation
to ensure that
the performance
and test metrics
are objective,
repeatable, and
practicable.
Research Need VI-1 False Assess the Volpe False Alert The Volpe project Volpe Completion
Positive Mitigation. capability and Scenarios and will support Date--December
capacity of Objective Test NHTSA development 2018.
possible Procedures for of false-positive
refinements to Crash Avoidance warning objective
reduce frequency Applications test procedures
of false positive project and. in conjunction
warning while with development
maintaining crash of objective test
avoidance procedures and
effectiveness. performance
criteria for IMA,
LTA, FCW, and BS/
LCW applications.
Research Need VI-6 DVI Minimum Determine DVI's V2V On-Road DVI Testing DVIs for VTTI Completion
Performance Requirements. impact on Project. Intersection Date: November
effectiveness of Movement Assist 2016.
system and safety and Left Turn
benefits Assist for
applications to stopped vehicles.
establish minimum
performance for
crash avoidance
and objective
test procedures.
----------------------------------------------------------------------------------------------------------------
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,\38\ and also to
facilitate cross-border traffic, as between NAFTA countries.\39\ 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,\40\ and some commenters suggested
that NHTSA work to develop a Global Technical Regulation (GTR) and
facilitate harmonization through that approach.\41\
---------------------------------------------------------------------------
\38\ Mercedes at 7; Alliance at 50; Automotive Safety Council at
3; Harley-Davidson at 2; Volvo Group at 3;
\39\ Alliance at 50; Global at 19-20; Pennsylvania DOT at 7; TRW
Automotive at 7.
\40\ Mercedes at 7; Systems Research Associates, Inc., at 10;
SAE International at 5; Delphi at 10; Continental Automotive Systems
at 3.
\41\ Automotive Safety Council at 3; Volvo Group at 4.
---------------------------------------------------------------------------
With regard to what specifically should be harmonized, commenters
mentioned hardware,\42\ software,\43\ DVI,\44\ and BSM,\45\ 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.\46\
Some industry commenters cautioned, however, that NHTSA should not let
harmonization objectives impede safety.\47\ 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.\48\
---------------------------------------------------------------------------
\42\ Mercedes at 7.
\43\ Mercedes at 7.
\44\ Automotive Safety Council at 3; TRW Automotive at 7.
\45\ TRW Automotive at 7.
\46\ Cohda Wireless at 9.
\47\ Alliance at 50, Global at 19-20.
\48\ Mercedes at 8.
---------------------------------------------------------------------------
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
[[Page 3874]]
aid 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.\49\
---------------------------------------------------------------------------
\49\ ``Continuation of the Implementing Arrangement between the
U.S. Department of Transportation and the European Commission''
http://www.its.dot.gov/press/2015/euro_commission.htm#sthash.URMW4OOH.dpuf (last accessed Dec 8,
2016).
---------------------------------------------------------------------------
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:
[cir] Signalized intersections applications such as Signal Phase
and Timing, Signal Request, Signal Status,
[cir] 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,
[[Page 3875]]
regional, 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.\50\
---------------------------------------------------------------------------
\50\ ``Harmonized security policies for cooperative Intelligent
Transport Systems create international benefits'' October 16, 2016.
https://ec.europa.eu/digital-single-market/news/harmonized-security-policies-cooperative-intelligent-transport-systems-create-international (last accessed: Dec 8, 2016).
---------------------------------------------------------------------------
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:
[cir] 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.
[cir] 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.
[cir] 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.
[cir] 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.
[cir] 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.\51\ Accompanying the ANPRM, NHTSA also published a research
report discussing the status of V2V technology and its readiness for
application (``V2V Readiness Report'').\52\ 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.
---------------------------------------------------------------------------
\51\ 79 FR 49270.
\52\ Docket No. NHTSA-2014-0022-0001.
---------------------------------------------------------------------------
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.\53\ 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.\54\
---------------------------------------------------------------------------
\53\ 79 FR 49270.
\54\ Id.
---------------------------------------------------------------------------
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
[[Page 3876]]
type 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.\55\ 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.\56\
---------------------------------------------------------------------------
\55\ Id.
\56\ Id.
---------------------------------------------------------------------------
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.\57\ 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.\58\ 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.
---------------------------------------------------------------------------
\57\ Id.
\58\ Id.
---------------------------------------------------------------------------
In the V2V Readiness Report,\59\ 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.\60\
---------------------------------------------------------------------------
\59\ V2V Readiness Report. Docket No. NHTSA-2014-0022-0001. Page
xv.
\60\ Id. at xv.
---------------------------------------------------------------------------
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,\61\ the
potential technological solutions to those problems (V2V-based or
otherwise),\62\ the potential hardware/software component that could be
used in DSRC devices,\63\ the applications that could be enabled by
V2V,\64\ and preliminary design concepts for a security system for the
V2V environment.\65\
---------------------------------------------------------------------------
\61\ Id. at 15.
\62\ Id. at 25.
\63\ Id. at 65.
\64\ Id. at 119.
\65\ Id. at 158.
---------------------------------------------------------------------------
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.),\66\ issues that may be outside the scope of NHTSA's
activities,\67\ privacy and public acceptance concerns over V2V
technology,\68\ and potential legal liability implications.\69\ 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.\70\ 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.\71\ Finally, throughout the V2V
Readiness Report, we also identified various research and policy gaps
in each of the substantive areas that we discussed.\72\
---------------------------------------------------------------------------
\66\ Id. at 33.
\67\ Id. at xvi.
\68\ Id. at 133.
\69\ Id. at 208.
\70\ Id. at 216.
\71\ Id. at 259.
\72\ See e.g., id. at xix.
---------------------------------------------------------------------------
In the context of the V2V Readiness Report, the ANPRM asked 57
questions to help solicit comments from the public more
effectively.\73\ 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.\74\ 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.\75\ On
the same subject, we asked if preferring certain technologies over
others in the situation of a network good \76\ such as V2V would lead
to any detrimental impact.\77\
---------------------------------------------------------------------------
\73\ 79 FR 49270, 49271.
\74\ Id. See also id. at 49273-24.
\75\ Id. at 49271.
\76\ A network good's value to each user increases when the
number of users of that good increase (e.g., telephone). In other
words, increasing the number of users creates a positive
externality.
\77\ Id.
---------------------------------------------------------------------------
The ANPRM questions also covered policy issues such as legal
interpretation of NHTSA's authorities under the Motor Vehicle Safety
Act,\78\ and how commenters view the public's potential acceptance/non-
acceptance of V2V technology.\79\ 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.\80\
---------------------------------------------------------------------------
\78\ Id.
\79\ Id. at 49273.
\80\ Id. at 49272.
---------------------------------------------------------------------------
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.\81\ 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.\82\
---------------------------------------------------------------------------
\81\ Id.
\82\ Id. at 49273.
---------------------------------------------------------------------------
2. Comments to the ANPRM
In response to the ANPRM, the V2V Readiness Report, and our
questions, we received more than 900 comments.\83\ 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
[[Page 3877]]
covered 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.
---------------------------------------------------------------------------
\83\ See Docket No. NHTSA-2014-0022.
---------------------------------------------------------------------------
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).\84\ 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).\85\ 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.\86\ 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.\87\
---------------------------------------------------------------------------
\84\ See e.g., Comments from the Alliance of Automobile
Manufacturers, Docket No. NHTSA-2014-0022-0603.
\85\ See id.
\86\ See id.
\87\ See e.g., Comments from Ford Motor Company, Docket No.
NHTSA-2014-0022-0953.
---------------------------------------------------------------------------
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 \88\ 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.\89\ 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.\90\
---------------------------------------------------------------------------
\88\ See Docket No. NHTSA-2014-0022-0655.
\89\ See Docket No. NHTSA-2014-0022-0414.
\90\ See Docket No. NHTSA-2014-0022-0266.
---------------------------------------------------------------------------
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).\91\ 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).\92\ 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).\93\
---------------------------------------------------------------------------
\91\ See Docket No. NHTSA-2014-0022-0646.
\92\ Consumers Union discussed the HMI and how warnings need to
be effectively communicated to the driver. See Docket No. NHTSA-
2014-0022-0533.
\93\ See e.g., Docket No. NHTSA-2014-0022-0511.
---------------------------------------------------------------------------
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.\94\
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.\95\ While IEEE
suggested that spectrum sharing is feasible, they opined that DSRC
deployment should not wait for further research on spectrum
sharing.\96\ Instead ``acceptable sharing parameters'' may be
determined at a later date after DSRC deployment and further
research.\97\
---------------------------------------------------------------------------
\94\ See e.g., Docket No. NHTSA-2014-0022-0597.
\95\ See id.
\96\ See Docket No. NHTSA-2014-0022-0693.
\97\ Id.
---------------------------------------------------------------------------
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,\98\
such manufacturers raised questions about NHTSA's authority to regulate
software and mobile devices.\99\ In addition, individual companies
(e.g., Qualcomm \100\) and other associations (e.g., the Wi-Fi Alliance
\101\) 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).\102\
---------------------------------------------------------------------------
\98\ CTIA--The Wireless Association and the Consumer Electronics
Association.
\99\ See e.g., Docket No. NHTSA-2014-0022-0483.
\100\ See Docket No. NHTSA-2014-0022-0665.
\101\ See Docket No. NHTSA-2014-0022-0644.
\102\ See Docket No. NHTSA-2014-0022-0403.
---------------------------------------------------------------------------
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).\103\ State agencies also commented.\104\ 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.\105\
---------------------------------------------------------------------------
\103\ See Docket No. NHTSA-2014-0022-0267.
\104\ State DOTs from also stress the need to have uniform HMI--
serving a purpose similar to the MUTCD for traffic signs and
signals. They also commented that other vehicle types that could
benefit from V2V (e.g., vehicles with GVWR greater than 10,000) and
mentioned the potential of other V2X applications (e.g., vehicle to
rail, agricultural equipment, horse-drawn vehicles). Further they
opine that mandate is needed to deploy quickly. See e.g., Comment
from PennDOT, Docket No. NHTSA-2014-0022-0371; TxDOT, Docket No.
NHTSA-2014-0022-0218; Wisconsin DOT, Docket No. NHTSA-2014-0022-
0507.
\105\ See Docket No. NHTSA-2014-0022-0420.
---------------------------------------------------------------------------
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
[[Page 3878]]
methods, and require adherence to Consumer Privacy Bill of
Rights).\106\ 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.\107\ 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.\108\
---------------------------------------------------------------------------
\106\ See Docket No. NHTSA-2014-0022-0689.
\107\ See Docket No. NHTSA-2014-0022-0331.
\108\ See Docket No. NHTSA-2014-0022-0502.
---------------------------------------------------------------------------
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 \109\ expressed similar concerns stating that
NHTSA should postpone this rulemaking until the FCC changes their
guidelines regarding human radiation exposure to wireless
communications.
---------------------------------------------------------------------------
\109\ See Docket No. NHTSA-2014-0022-0682.
---------------------------------------------------------------------------
F. SCMS RFI
Approximately 30 days after issuing the agency's Advance Notice of
Proposed Rulemaking (ANPRM) \110\ and V2V Readiness Report, NHTSA
released a Request for Information (RFI) \111\ 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.
---------------------------------------------------------------------------
\110\ 79 FR 49270 (Aug. 20, 2014).
\111\ 79 FR 61927 (Oct. 15, 2014).
---------------------------------------------------------------------------
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.\112\ The agency
[[Page 3879]]
believes 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 \113\ 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.
---------------------------------------------------------------------------
\112\ ``Passenger cars,'' ``multipurpose passenger vehicles,''
``trucks,'' and ``buses'' are defined in 49 CFR 571.3. Some
commenters suggested that the agency's proposal also cover vehicles
like motorcycles and horse-drawn buggies (Wisconsin DOT), or heavy
vehicles (Bendix, among others). Both motorcycles and HVs were
included in the Safety Pilot Model Deployment, but in very small
numbers, and the agency believes that more research is needed than
what is available at the time of this NPRM before we are ready to
propose requirements for those vehicles. The agency will be making a
decision on how to proceed with V2V capability for HVs at a later
date. For buggies, these would not be considered motor vehicles, but
we are optimistic that V2X capability may eventually be available
for them.
\113\ Impact of Light Vehicle Rule on Consumer/Aftermarket
Adoption--Dedicated Short Range Communications Market Study,
Intelligent Transportation Society of America, FHWA-JPO-17-487,
available at http://ntl.bts.gov/lib/60000/60500/60535/FHWA-JPO-17-487_Final_.pdf (last accessed Dec 12, 2016).
---------------------------------------------------------------------------
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.\114\ 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.
---------------------------------------------------------------------------
\114\ To be clear, the related performance requirements for V2V
communication security will incorporate protections to ensure a
secure vehicle communication that are distinct from other types of
communications with the vehicle for other data transfers and
interconnectivity. The performance requirements for V2V security
communications do not and are not intended to provide comprehensive
protection for other vehicle wireless communications or internal
vehicle connectivity for operational functionality. That
responsibility continues to belong to manufacturers.
---------------------------------------------------------------------------
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
[[Page 3880]]
benefits 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.
[[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.\115\ 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.
---------------------------------------------------------------------------
\115\ Six potential applications were mentioned in particular:
IMA, FCW, DNPW, EEBL, BSW/LCW, and LTA.
---------------------------------------------------------------------------
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
[[Page 3882]]
standards 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.
(1) Range
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.
[[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 +[hairsp]10 degrees and
-6 degrees. We think that the elevation angle range of +[hairsp]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 +[hairsp]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.\116\
---------------------------------------------------------------------------
\116\ Vehicle reference point is the same point that we defined
in the basic safety message content requirements section, above.
---------------------------------------------------------------------------
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
\117\ proceeding in any direction around the vehicle.\118\
---------------------------------------------------------------------------
\117\ Note the line originates at a point that is 1.5 m above
the test reference point, but (for simplicity) we are expressing the
angle of the line by referencing the test surface (i.e., the ground,
which is not where the line begins). The angle of the line could be
expressed by referencing any plane that is parallel to the test
surface.
\118\ In other words, the line can travel in any direction (360
degrees) around the point 1.5 m above the vehicle reference point.
---------------------------------------------------------------------------
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
\119\ proceeding in any direction around the vehicle.\120\
---------------------------------------------------------------------------
\119\ See similar note, above.
\120\ See similar note, above.
---------------------------------------------------------------------------
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
[[Page 3884]]
that 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.
(3) Reliability
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) 4.1.1.2 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
[[Page 3885]]
aforementioned 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.
(a) Channel
(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
[[Page 3886]]
2015, 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.\121\ The overall goals and objectives of this research
are as follows:
---------------------------------------------------------------------------
\121\
---------------------------------------------------------------------------
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.\122\ 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.
---------------------------------------------------------------------------
\122\ https://apps.fcc.gov/edocs_public/attachmatch/FCC-16-68A1_Rcd.pdf.
---------------------------------------------------------------------------
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
[[Page 3887]]
congestion 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 \123\); 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).
---------------------------------------------------------------------------
\123\ In relation to communications congestions the use of the
term ``traffic jam'' refers to the analysis presented via the ANPRM
that identified a major interchange that includes overpasses as an
extreme scenario with the possibility of approximately 800 V2V
vehicles transmitting BSMs in the range of one V2V vehicle.
---------------------------------------------------------------------------
Based on this logic, BAH recommended in its research that devices
transmit in the following manner:
When the Channel Busy Ratio \124\ is below 50%, transmit
the BSM at a data rate of 9 Mbps;
---------------------------------------------------------------------------
\124\ Channel busy ratio describes how congested the channel is.
When the ratio is 50%, it means that for a 100 ms timeframe, the
device sees that there is someone else within range that is
transmitting for 50 ms of the 100 ms.
---------------------------------------------------------------------------
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 \125\ 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.
---------------------------------------------------------------------------
\125\ See Section 3 in Appendix I, http://www.nhtsa.gov/Research/Crash-Avoidance/Vehicle%E2%80%93to%E2%80%93Vehicle-Communications-for-Safety (last accessed: Dec 8, 2016).
---------------------------------------------------------------------------
[[Page 3888]]
[GRAPHIC] [TIFF OMITTED] TP12JA17.002
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
[[Page 3889]]
constant (regardless of the bitrate tested) up to 500 m.\126\
---------------------------------------------------------------------------
\126\ See BAH DSRC Phase II Report Section 4.3.3.2.
[GRAPHIC] [TIFF OMITTED] TP12JA17.003
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.\127\ 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).
---------------------------------------------------------------------------
\127\ Wireless transmission of information through radio signals
often travel to a receiver not only through a direct path, but also
through reflections off of other objects in the environment. When
the objects move and the direct path between the transmitter and the
receiver change, the signal may fade in a variety of ways. Thus, the
changing environmental conditions (in addition to some of the other
---------------------------------------------------------------------------
(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]
Note: 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.
(2) Reception
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
[[Page 3890]]
under 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
[[Page 3891]]
agency 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.
[GRAPHIC] [TIFF OMITTED] TP12JA17.004
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:
Openness;
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.\128\
---------------------------------------------------------------------------
\128\ See ``Standards Glossary'' IEEE, https://www.ieee.org/education_careers/education/standards/standards_glossary.html (last
accessed Dec 12, 2016).
---------------------------------------------------------------------------
Voluntary consensus standards follow a rigorous, industry inclusive
development process where each standard is developed by an established
[[Page 3892]]
committee 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.\129\ 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.
---------------------------------------------------------------------------
\129\ For a description of the IEEE ballot process, see http://standards.ieee.org/develop/balloting.html (last accessed Dec 12,
2016).
---------------------------------------------------------------------------
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.\130\ Each layer has unique
responsibilities including passing information to the layers above and
below it.\131\ 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.
---------------------------------------------------------------------------
\130\ See ``How OSI Works'' http://computer.howstuffworks.com/osi1.htm (last accessed: Dec 12, 2016).
\131\ See ``Physical Layer'', http://www.linfo.org/physical_layer.html (last accessed: Dec 12, 2016).
---------------------------------------------------------------------------
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.\132\ These layers and
associated standards represent the DSRC protocol stack that developers
use to design and produce interoperable devices.
---------------------------------------------------------------------------
\132\ See ``OSI reference model (Open Systems Interconnection)''
http://searchnetworking.techtarget.com/definition/OSI (last
accessed: Dec 12, 2016).
---------------------------------------------------------------------------
[[Page 3893]]
[GRAPHIC] [TIFF OMITTED] TP12JA17.005
(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.
[[Page 3894]]
[GRAPHIC] [TIFF OMITTED] TP12JA17.006
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.
[[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.
[GRAPHIC] [TIFF OMITTED] TP12JA17.007
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 Requirements
[[Page 3896]]
Table III-1--Summary of BSM Transmission Requirements
----------------------------------------------------------------------------------------------------------------
Relationship to
Requirement Proposal Basis standards Reason
----------------------------------------------------------------------------------------------------------------
Range (longitudinal & lateral).. Minimum 300m; 360 CAMP--application SAE J2945/1....... The setting is
degrees around tested in SPMD based on the need
vehicle. also calculation to provide
of range needed accurate and
for DNPW. 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 CAMP and BAH SAE J2945/1....... Same as above.
of +10 degrees research and
and -6 degrees. testing
capabilities.
Reliability..................... Packet Error Rate CAMP and BAH...... SAE J2945/1....... Same as above.
<10%.
BSM Radio Channel............... All BSM FCC rules......... SAE J2945/1....... Same as above.
transmissions and
receptions on 172
(safety-critical
communications).
Data Rate....................... 6 Mbps............ CAMP and BAH SAE J2945/1 (one Same as above--
research--CAMP of the bitrates Also Current
research shows included in developers
PER degradation 802.11). support a 6 Mbps
using 12 Mbps. data rate. More
BAH research data and testing
indicates is needed to
problems after change the data
500m, also BAH rate and
test done under determine if a
``open field'' changing rate can
conditions. be used and
support crash
avoidance.
Transmission Frequency.......... 10 times per CAMP--trade-off SAE J2945/1....... Accepted among
second under non- between long experts to
congested inter-packet support V2V crash
conditions. delays avoidance.
experienced by
V2V safety
applications and
heavy wireless
channel
utilization.
Staggering Transmission Time.... Random Mitigate channel SAE J2945/1....... Due to accuracy of
transmission of congestion if all devices need to
BSMs every 100 +/- devices mimic the stagger
ms between 0 and transmitted at experienced
5 ms. same time--CAMP during SPMD to
and BAH research. 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.
(i) Range
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.
(3) Reliability
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
[[Page 3897]]
the 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.
(b) Reception
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.
(c) Interoperability
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 \133\ 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.
---------------------------------------------------------------------------
\133\ E.g., SAE Standard J2735, J2945.
---------------------------------------------------------------------------
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,\134\ 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.
---------------------------------------------------------------------------
\134\ SAE J2735 and J2945.
---------------------------------------------------------------------------
(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
[[Page 3898]]
element is one byte from 0 to 15.\135\ 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.
---------------------------------------------------------------------------
\135\ SAE Standard J2735, page 171.
---------------------------------------------------------------------------
(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.\136\ 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.
---------------------------------------------------------------------------
\136\ Id. at page 212.
---------------------------------------------------------------------------
(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.\137\
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.
---------------------------------------------------------------------------
\137\ Id. at page 252.
---------------------------------------------------------------------------
(b) Time
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 \138\ and devices would be
required to use the UTC \139\ 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.\140\
---------------------------------------------------------------------------
\138\ Id. at page 62.
\139\ Coordinated Universal Time International
Telecommunications Union Recommendation (ITU-R TF.460-6), See BAH
Report Section 4.3.6.2pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-
I!!PDF-E.pdf.
\140\ See ``Leap Seconds'' http://www.endruntechnologies.com/leap.htm (last accessed Dec 12, 2016).
---------------------------------------------------------------------------
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.
(c) Location
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
[[Page 3899]]
differentiate 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.
[GRAPHIC] [TIFF OMITTED] TP12JA17.008
(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) \141\ 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.\142\ 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
[[Page 3900]]
basic 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.
---------------------------------------------------------------------------
\141\ HDOP is a measure of the geometric quality of a GNSS
satellite configuration in the sky. HDOP is a factor in determining
the relative accuracy of a horizontal position based on the number
of visible satellites. The smaller the DOP number, the better the
geometry and accuracy. HDOP less than 5 is a general rule of
indicating a good GNSS condition that can provide the desired level
of accuracy. However, a lower DOP value does not automatically mean
a low position error. The quality of a GPS-derived position estimate
depends upon both the measurement geometry as represented by DOP
values, and range errors caused by signal strength, ionospheric
effects, multipath, etc.
\142\ As noted above, there are other factors that may lead to
degradation of the GPS information--e.g., ionospheric interference,
multipath, etc.
---------------------------------------------------------------------------
(iii) Elevation
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.\143\ 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.
---------------------------------------------------------------------------
\143\ We would measure the elevation data element under the same
conditions as the longitudinal/lateral data element--i.e., the
accuracy needs to be 3m when the HDOP is less than 5 within the 1
sigma absolute error.
---------------------------------------------------------------------------
(d) Movement
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.
(i) Speed
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?
(ii) Heading
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)
[[Page 3901]]
sensors 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'' \144\ 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.
---------------------------------------------------------------------------
\144\ ``Latch'' in this context refers to a software operation
that holds a value in memory and attached to a specific variable as
long as a specified condition is reached and maintained.
---------------------------------------------------------------------------
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.\145\
---------------------------------------------------------------------------
\145\ See Mazzae, E.N., Garrott, W.R., (2006) Experimental
Evaluation of the Performance of Available Backover Prevention
Technologies. National Highway Traffic Safety Administration, DOT HS
810 634.
---------------------------------------------------------------------------
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 \146\
(~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.
---------------------------------------------------------------------------
\146\ The speed threshold for unlatching the vehicle heading is
different from the speed threshold for latching. The reason for the
latching speed to be lower than the unlatching speed is because a
system should not need to latching and unlatch the vehicle heading
repeatedly when the vehicle speed is hovering around a given
threshold speed (e.g., 1.11 m/s). By having different (but similar)
speeds for latching and unlatching, the system will be able to latch
the speed once when the vehicle is decelerating and unlatch once
when the vehicle is accelerating without having to repeat the action
multiple times if there are vehicle speed fluctuations during the
vehicle's general acceleration or deceleration trend.
---------------------------------------------------------------------------
(iii) Acceleration
For Acceleration, the agency would require vehicles to report
horizontal (longitudinal and lateral) acceleration with an accuracy of
0.3 m/s\2\ and vertical acceleration to 1 m/s\2\. 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.................... .......... [check] .......... .......... .......... ..........
Control Loss without Prior Vehicle .......... .......... .......... .......... .......... [check]
Action.................................
Vehicle(s) Turning at Non-Signalized .......... .......... .......... [check] [check] ..........
Junctions..............................
Straight Crossing Paths at Non- .......... .......... .......... [check] .......... ..........
Signalized Junctions...................
Lead Vehicle Decelerating............... [check] [check] .......... .......... .......... ..........
Vehicle(s) Changing Lanes--Same .......... .......... [check] .......... .......... ..........
Direction..............................
Left Turn Across Path--Opposite .......... .......... .......... .......... [check] ..........
Direction..............................
Lead Vehicle Stopped.................... .......... [check] .......... .......... .......... ..........
Control Loss without Prior Vehicle .......... .......... .......... .......... .......... [check]
Action.................................
Vehicle(s) Turning at Non-Signalized .......... .......... .......... [check] [check] ..........
Junctions..............................
Straight Crossing Paths at Non- .......... .......... .......... [check] .......... ..........
Signalized Junctions...................
Lead Vehicle Decelerating............... [check] [check] .......... .......... .......... ..........
Vehicle(s) Changing Lanes--Same .......... .......... [check] .......... .......... ..........
Direction..............................
Left Turn Across Path--Opposite .......... .......... .......... .......... [check] ..........
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
[[Page 3902]]
may 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/s\2\.
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,
[[Page 3903]]
headlights (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.\147\ 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.
---------------------------------------------------------------------------
\147\ NHTSA's past research used 6 degree changes in steering
input to indicate a situation in the research project where the test
driver intended to conduct a maneuver. See NHTSA Light Vehicle
Antilock Brake System Research Program Task 5.2/5.3: Test Track
Examination of Drivers' Collision Avoidance Behavior Using
Conventional and Antilock Brakes, DOT HS 809 561, March 2003, page
32.
---------------------------------------------------------------------------
(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
[[Page 3904]]
driver'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.\148\
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.
---------------------------------------------------------------------------
\148\ See FN 3 above.
---------------------------------------------------------------------------
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
[[Page 3905]]
path 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.\149\ 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.
---------------------------------------------------------------------------
\149\ See 79 FR 19220.
---------------------------------------------------------------------------
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.
[[Page 3906]]
Please provide any supporting evidence that the agency can used to
make an informed decision.
(3) Summary Table of BSM Content Requirements
---------------------------------------------------------------------------
\150\ NHTSA intends for the BSM Content Requirements identified
in Table III-3 to be in accordance with the proposal's overarching
requirement that BSMs may not contain data elements linked or
reasonably linkable to an individual.
Table III-3--Summary of BSM Content Requirements \150\
----------------------------------------------------------------------------------------------------------------
Applicable
Requirement Proposal Basis standards Reason
----------------------------------------------------------------------------------------------------------------
Message Packaging............... Message ID--(2) Preliminary SAE J2735......... Allows device to
for BSM. elements need to interpret message
Message Count-- ID, process, and and obtain safety
sequence No. sequence BSMs. information.
Temp ID--random
No. from specific
device.
Time............................ Use UTC standard UTC is accepted SAE J2735, J2945/1 Need time standard
to set time. standard for to related
setting universal messages to time
system time. critical conflict
situations.
Position (Longitude & Latitude). Longitude and Per CAMP research SAE J2735, J2945/1 Provides for
Latitude within to develop accurate relative
1.5m of actual relationship vehicle position
position at HDOP between need to support
<5 and 1 sigma measurable crash avoidance--
absolute error. absolute position (CAMP).
and relative
position.
Position (Elevation)............ 3m (10 feet) (more Accurate elevation SAE 2735, J2945/1. 3m provides for
difficult to reduces false low bridges and
calculate than positives--SPMD. changes in grade
lat/long). for crash
avoidance.
Movement (Speed)................ Accurate within Same as EDR rule-- SAE J2735, J2945/1 The setting is
0.28 m/s (1 kph). tighter accuracy based on the need
then identified to provide
by CAMP. Changed accurate and
to be consistent timely safety
with existing alerts. The
standard. 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 Research indicates SAE J2735, J2945/1 Same as above.
accuracy within 2 that above 12.5 m/
degree--Speed s sensors and
>12.5 m/s within vehicle dynamics
3 degrees. can support 2
degrees--under
12.5 m/s can
support 3 degrees.
Movement (Acceleration)......... Longitudinal & CAMP research and SAE J2735, J2945/1 Same as above.
Lateral accuracy testing.
0.3 m/s\2\--
Vertical accuracy
1 m/s.
Movement (Yaw rate)............. Accuracy within CAMP.............. SAE J2735, J2945/1 The setting is
0.5 degrees per based on the need
second. 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 Report if vehicle CAMP.............. SAE J2735, J2945/1 Same as above.
(Transmission). is in forward or
reverse gear, or
neutral.
Vehicle Motion Indicator Report the CAMP.............. SAE J2735, J2945/1 Same as above.
(Steering Wheel Angle). direction of
steering wheel
angle within 5
degrees of actual.
Vehicle Size.................... Vehicle length and CAMP and MITRE SAE J2735, J2945/1 Balance the need
width within 0.2m privacy research. to know the
tolerance. physical extent
of the vehicle
for crash
avoidance and
still protect
privacy.
[[Page 3907]]
Excluded Data Elements: No data Mandate that these MITRE privacy SAE J2735, J2945/1 To protect
elements directly or, as a optional data research. consumer privacy
practical matter, linkable to a element cannot be by reducing
specific individual or vehicle populated for privacy risk.
(including but not limited to device in
VIN string, Owner code, privately owned
Temporary ID, Vehicle Type). light vehicles.
Path History.................... Provides concise CAMP research to SAE J2735, J2945/1 Use in
representation of support crash calculations to
vehicles recent avoidance. identify vehicle
movements with conflict
accuracy of min situations.
23 points and
required to be
transmitted with
BSM.
Path Prediction................. Perpendicular CAMP research..... SAE J2735, J2945/1 The setting is
Distance--1M; based on the need
Radius error--2%; to provide
Transmission Time accurate and
4s. 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
[[Page 3908]]
Management 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. \151\ 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.\152\
---------------------------------------------------------------------------
\151\ The V2V device generates the private key & public keys.
The public key is sent to the SCMS to incorporate into a certificate
that is signed by the PCA. The private key is always kept secret
with the V2V device. The private key is vital to the signing process
and must be kept secured at all times.
\152\ See ``Using the Elliptic Curve Digital Signature Algorithm
effectively'' http://www.embedded.com/design/safety-and-security/4427811/Using-the-Elliptic-Curve-Digital-Signature-Algorithm-effectively, Feb. 2, 2014 (last accessed Dec 7, 2016).
---------------------------------------------------------------------------
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
----------------------------------------------------------------------------------------------------------------
Certificate Message content Signature Timestamp
----------------------------------------------------------------------------------------------------------------
Pseudonym Certificate
Public Key.................. (i.e., the speed, Produced from the (i.e., when the
Signature of the Pseudonym heading, location, following steps: information is
Certificate Authority. etc. information that Compute hash transmitted.]).
Validity Period...................... supports the safety of the Message Content
Says when certificate applications). and Timestamp.
effective and when expires. Use your
private key to create
an encoded string of
numbers.
The encoded
string of numbers is
your signature.
----------------------------------------------------------------------------------------------------------------
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 \153\ 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) \154\
governs the creation of the hash.
---------------------------------------------------------------------------
\153\ A hash function is any function that can be used to map
data of arbitrary size to data of fixed size. The values returned by
a hash function are called hash values, hash codes, hash sums, or
simply hashes.
\154\ See ``Secure Hashing'' http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html (last accessed Dec 7, 2016).
---------------------------------------------------------------------------
(b) Input the hashed contents through an Elliptical Curve Digital
Signature Algorithm \155\ (the equation that creates the encoded string
of numbers). The resulting number is the ``digital signature.''
---------------------------------------------------------------------------
\155\ See FIPS publication 186-4 at ``FIPS Publications'' http://csrc.nist.gov/publications/PubsFIPS.html (last accessed Dec 7,
2016).
---------------------------------------------------------------------------
(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.
[[Page 3909]]
[GRAPHIC] [TIFF OMITTED] TP12JA17.009
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 \156\ (which itself
references specific clauses and sections of relevant IEEE P1609 and
802.11 standards).
---------------------------------------------------------------------------
\156\ See ``On-Board System Requirements for V2V Safety
Communication'' at http://standards.sae.org/j2945/1_201603/ (last
accessed Dec 7, 2016).
---------------------------------------------------------------------------
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.\157\
---------------------------------------------------------------------------
\157\ As discussed later in this section, the timeframes for
this test accommodate our current proposal for changing
certificates.
---------------------------------------------------------------------------
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.
[[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
[[Page 3911]]
number 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.\158\ 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.
---------------------------------------------------------------------------
\158\ A certificate is expected to be 117 bytes. The number of
unique certs/year * size of one certificate. (103680 * 117 = 12.13MB
for one vehicle for one year). *300 million vehicles =
3,639,168,000,000,000. Or 3.6 exabytes.
---------------------------------------------------------------------------
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 x 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
(1) Overview
The agency is also bringing forth potential alternatives to the
SCMS-based
[[Page 3912]]
proposal 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
[[Page 3913]]
and identification algorithm capabilities over time.
(1) Reporting
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).
[[Page 3914]]
Further, 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
(a) Overview
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:
[cir] Device components not operating properly
[cir] Input sensor data not within appropriate tolerances
[cir] On Board memory failures
[cir] GPS receiver failures
[cir] Unable to transmit or receive basic safety messages
[cir] 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.\159\ 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.160 161
---------------------------------------------------------------------------
\159\ See below for the agency's discussion of its legal
authority. This proposed requirement is similar to many other
existing requirements to warn drivers via telltales or messages
about potential issues with required safety technologies, for
example, the ESC or TPMS malfunction telltales. The difference in
this case is simply that the agency expects a need to illuminate the
telltale with some regularity, given that certificates will
periodically run out and need to be replenished.
\160\ ``OTA updating brings benefits, challenges'' SAE
Automotive Engineering, August 16, 2016, http://articles.sae.org/14946/ (last accessed: Dec 7, 2016).
\161\ ``International Truck offers over-the-air programming for
2017 Cummins engines'' SAE Automotive Engineering, May 19, 2016,
http://articles.sae.org/14834/ (last accessed: Dec 7, 2016).
---------------------------------------------------------------------------
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
[[Page 3915]]
anticipates 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.
7. Cybersecurity
(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.\162\ 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.
---------------------------------------------------------------------------
\162\ See ``NHTSA and Vehicle Cybersecurity'', http://www.nhtsa.gov/staticfiles/administration/pdf/presentations_speeches/2015/NHTSA-VehicleCybersecurity_07212015.pdf (last accessed Dec 12,
2016).
---------------------------------------------------------------------------
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:
[[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 \163\ 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.
---------------------------------------------------------------------------
\163\ The FIPS families of standards contain a set of standards
that pertain specifically to cryptographic storage models, FIPS-140
which the industry uses to store sensitive cryptographic
information. The device long and short term certificates along with
the devices public/private key pairs are generally regarded as
cryptographic information. The FIPS-140 set of standards define
various levels of security for cryptographic information storage
ranging from 1 through 4, with increasing security measures as the
levels get higher. Of particular interest to the OBE are levels 2
and levels 3. Amongst other differences, the agency is interested in
the tamper capabilities of these levels. Level 2 is considered
tamper evident storage. This can be achieved by placing seals on
enclosures (like stickers on over the counter medication that say
``do not use if seal is broken''), by using tamper evident screws
and mounting hardware, and other such methodologies. Level 3 adds to
this by requiring devices to be tamper resistant. There are many
ways to achieve tamper resistance; however, one common method for
protecting data is to have the device zero out cryptographic storage
in the event that a device is tampered with.
---------------------------------------------------------------------------
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:
[ssquf] All individual pseudonym certificates
[ssquf] RA, Intermediate CA, and PCA certificates
[ssquf] the RA address
[ssquf] system configuration files
[ssquf] security policies
[ssquf] Root CA certificate
[ssquf] Device Enrollment certificate
[ssquf] All system private keys
[ssquf] The System CRL
[ssquf] 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
[[Page 3917]]
device'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,\164\
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?
---------------------------------------------------------------------------
\164\ See ``GPS Under Attack as Crooks, Rogue Workers Wage
Electronic War'' at http://www.nbcnews.com/news/us-news/gps-under-attack-crooks-rogue-workers-wage-electronic-war-n618761 (last
accessed Dec 7, 2016).
---------------------------------------------------------------------------
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
[[Page 3918]]
might 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'' \165\ 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,\166\ which led to eventual recall \167\ 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.
---------------------------------------------------------------------------
\165\ Worm refers to a standalone malware that replicates itself
in order to spread to other systems.
\166\ ``Remote Exploitation of an Unaltered Passenger Vehicle'',
Charlie Miller and Chris Valasek. Page 48. Available at http://illmatics.com/Remote%20Car%20Hacking.pdf (last accessed Dec. 7,
2016).
\167\ NHTSA Recall Campaign Number: 15V461000.
---------------------------------------------------------------------------
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.\168\ The
growing trend is towards building in capabilities for remote software
updates.
---------------------------------------------------------------------------
\168\ According to online Web site Autotrader, the recall
completion rate in 2015 was approximately 48 percent, down from 56
percent in 2014.
---------------------------------------------------------------------------
[[Page 3919]]
According to a study released by IHS in September of 2015,\169\
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.
---------------------------------------------------------------------------
\169\ ``Over-the-air Software Updates to Create Boon for
Automotive Market, IHS Says'' at http://press.ihs.com/press-release/automotive/over-air-software-updates-create-boon-automotive-market-ihs-says (last accessed: Dec. 7, 2016).
---------------------------------------------------------------------------
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
[[Page 3920]]
many 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.\170\ 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.
---------------------------------------------------------------------------
\170\ See, e.g., Nodine et al., ``Independent Evaluation of
Light-Vehicle Safety Applications Based on Vehicle-to-Vehicle
Communications Used in the 2012-2013 Safety Pilot Model
Deployment,'' USDOT Volpe Center, DOT HS 812 222, December 2015,
Section 5.1. Available at Docket NHTSA-2016-0126.
---------------------------------------------------------------------------
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.
2. Privacy
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
[[Page 3921]]
their 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,\171\ 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.
---------------------------------------------------------------------------
\171\ Section 522 of the Consolidated Appropriations Act, 2005,
Public Law 108-447.
---------------------------------------------------------------------------
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.\172\ 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.
---------------------------------------------------------------------------
\172\ ``PRIVACY PRINCIPLES FOR VEHICLE TECHNOLOGIES AND
SERVICES'' available at http://www.autoalliance.org/?objectid=865F3AC0-68FD-11E4-866D000C296BA163 (last accessed dec 7,
2016).
---------------------------------------------------------------------------
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.\173\ 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
[[Page 3922]]
detection 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.\174\
---------------------------------------------------------------------------
\173\ Additional information about NHTSA's approach to
automotive cybersecurity is available at http://www.nhtsa.gov/About+NHTSA/Speeches,+Press+Events+&+Testimonies/NHTSA+and+Vehicle+Cybersecurity (last accessed Sept. 23, 2015).
\174\ See, e.g., King, Rachel, ``GM Grapples with Big Data,
Cybersecurity in Vehicle Broadband Connections,'' Wall Street
Journal, Feb. 10, 2015. Available at http://blogs.wsj.com/cio/2015/02/10/gm-grapples-with-big-data-cybersecurity-in-vehicle-broadband-connections/ (last accessed Dec 7, 2016).
---------------------------------------------------------------------------
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.\175\ The recommendations were as follows:
---------------------------------------------------------------------------
\175\ See Launchbury, John, Dylan McNamee, and Lee Pike, Galois
Inc., ``A Technique for Secure Vehicle-to-Vehicle Communication,''
Mar. 9, 2014. Available at http://galois.com/wp-content/uploads/2014/07/whitepaper_SecureInterfaces.pdf (last accessed Dec 7, 2016).
---------------------------------------------------------------------------
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
[cir] parse(serialize(m)) = m, for all messages m, and
[cir] 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.
4. Health
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.\176\
---------------------------------------------------------------------------
\176\ ``Vehicle to Vehicle Crash Avoidance Safety Technology:
Public Acceptance Final Report'' December, 2015. Available at Docket
No. NHTSA-2016-0126
---------------------------------------------------------------------------
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
[[Page 3923]]
more 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,\177\ 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.
---------------------------------------------------------------------------
\177\ See 79 FR 49270, at 49272 (Aug. 20, 2014) (Question 13 in
the ANPRM asks whether commenters believe that V2V-based warnings
should be permitted to be modified or disabled).
---------------------------------------------------------------------------
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.\178\ 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.
---------------------------------------------------------------------------
\178\ See 49 U.S.C. 30122(b).
---------------------------------------------------------------------------
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.\179\ 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.\180\
---------------------------------------------------------------------------
\179\ See 49 CFR part 126, S5.4. We note that despite the
overarching requirement to return to full functionality at the new
ignition cycle, S5.4 does not require ESC to return to full
functionality if the vehicle is in a mode for ``low-speed, off-road
driving,'' or if the front and rear axles are locked because the
vehicle is in some sort of 4WD mode.
\180\ 72 FR at 17279-80 (Apr. 6, 2007).
---------------------------------------------------------------------------
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.\181\ 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).\182\ 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.\183\
---------------------------------------------------------------------------
\181\ See 49 CFR part 208, S4.5.4.
\182\ Id.
\183\ Deactivation of the ``advanced'' right front passenger air
bag was primarily intended to address the possibility that, in
vehicles with no (or very small) back seats, a child seat might have
to be placed in the front passenger seat rather than in the back.
The primary mechanism to mitigate the risk of the front passenger
air bag deploying when a child seat is present is a suppression
system, but the agency allowed vehicle manufacturers to include an
off switch for several years to improve parents' confidence that the
suppression systems were working successfully in the field. See 65
FR at 30723 (May 12, 2000).
---------------------------------------------------------------------------
[[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.\184\ 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.
---------------------------------------------------------------------------
\184\ See Reports: FHWA-JPO-15-237--``Final Design Analysis
Report'' September 18, 2015, FHWA-JPO-15-236--``Privacy Issues for
Consideration by USDOT Based on Review of Preliminary Technical
Framework (Final-Rev A)'' February 24, 2016, FHWA-JPO-15-235--
``Final Requirements Report'' September 11, 2015, and ``Technical
Memorandum: Modeling and simulation of Areas of Potential V2V
Privacy Risk'' March 8, 2016 located in Docket No. NHTSA-2016-0126.
---------------------------------------------------------------------------
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
[[Page 3925]]
commercial 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 \185\ 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.
---------------------------------------------------------------------------
\185\ Section 522 of the Consolidated Appropriations Act, 2005,
Public Law 108-447.
---------------------------------------------------------------------------
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
[[Page 3926]]
density, 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
[[Page 3927]]
with 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
[[Page 3928]]
Federal 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.
[[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
[cir] Triggering BSM(s)
[cir] Host vehicle BSM(s)
[cir] Neighboring vehicle BSM(s)
[cir] Warnings
[cir] Neighboring devices
[cir] 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
[[Page 3930]]
device 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.
[[Page 3931]]
Table IV-1--Transactions Identified for Further Analysis
------------------------------------------------------------------------
Transaction type Description
------------------------------------------------------------------------
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 4. Do BSMs in misbehavior reporting
Misbehavior Message. provide sufficient information
about the past location of the
reporting or other vehicles to
retrospectively track the vehicle's
path?
Certificate Revocation List (CRL) 5. Does information regarding
Distribution Transaction. 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.\186\ 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.
---------------------------------------------------------------------------
\186\ ``Electromagnetic Hypersensitivity Comment Review and
Analysis'', NHTSA V2V Support--Task 3, dated March 13, 2015, Noblis.
---------------------------------------------------------------------------
1. Overview
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.\187\
---------------------------------------------------------------------------
\187\ ``Electromagnetic fields and public health:
Backgrounder'', The World Health Organization (WHO), December 2005.
Available at http://www.who.int/peh-emf/publications/facts/fs296/en/
(last accessed Sept. 28, 2015).
---------------------------------------------------------------------------
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.\188\
---------------------------------------------------------------------------
\188\ ``Wireless Devices and Health Concerns'', Federal
Communications Commission (FCC), Consumer and Governmental Affairs
Bureau, updated March 12, 2014. Available at http://www.fcc.gov/guides/wireless-devices-and-health-concerns (last accessed Dec 12,
2016).
---------------------------------------------------------------------------
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
[[Page 3932]]
Western 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.\189\
---------------------------------------------------------------------------
\189\ ``COMAR Technical Information Statement the IEEE exposure
limits for radiofrequency and microwave energy'', Marvin C. Ziskin,
IEEE Engineering in Medicine and Biology Magazine, March/April,
2005. Available at http://ewh.ieee.org/soc/embs/comar/standardsTIS.pdf (last accessed Dec. 12, 2016).
---------------------------------------------------------------------------
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.\190\
---------------------------------------------------------------------------
\190\ Department of Energy ``Smart Grid'' Web site. Available at
http://energy.gov/oe/services/technology-development/smart-grid
(last accessed Dec 12, 2016).
---------------------------------------------------------------------------
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.\191\ 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.\192\
---------------------------------------------------------------------------
\191\ ``Demand Response & Smart Metering Policy Actions Since
the Energy Policy Act of 2005--A Summary for State Officials'',
Prepared by U.S. Demand Response Coordinating Committee for The
National Council on Electricity Policy, 2008. http://energy.gov/oe/downloads/demand-response-and-smart-metering-policy-actions-energy-policy-act-2005-summary-state (last accessed: Dec 12, 2016)
\192\ ``Assessment of Demand Response and Advanced Metering'',
Federal Energy Regulatory Commission (FERC) Report, December 2014.
Available at https://www.ferc.gov/industries/electric/indus-act/demand-response/dem-res-adv-metering.asp (last accessed Dec. 12,
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.\193\
---------------------------------------------------------------------------
\193\ Federal Communications Commission, (FCC), 2011. Radio
frequency safety, available at https://www.fcc.gov/encyclopedia/radio-frequency-safety (last accessed Dec 12, 2016).
---------------------------------------------------------------------------
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.\194\ 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.\195\ 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.\196\
---------------------------------------------------------------------------
\194\ ``Review of Health Issues Related to Smart Meters'',
Monterey County Health Department, Public Health Bureau,
Epidemiology and Evaluation, March, 2011. Available at https://www.nema.org/Technical/Documents/Smart%20Meter%20Safety%20-%20Marin%20Co%20CA%20whitepaper.pdf (last accessed Dec 12, 2016).
\195\ ``Health Impacts of RF Exposure from Smart Meters'',
California Council on Science and Technology, April 2011. Available
at https://ccst.us/publications/2011/2011smart-final.pdf (last
accessed Dec 12, 2016).
\196\ ``RF Exposure Levels from Smart Meters: A Case Study of
One Model'', Electric Power Research Institute (EPRI), February
2011. Available at http://www.epri.com/abstracts/Pages/ProductAbstract.aspx?ProductId=000000000001022270 (last accessed Dec
12, 2016).
---------------------------------------------------------------------------
A typical ``smart'' utility meter device uses a low power one watt
wireless radio to send customer energy-usage information
wirelessly.\197\ The V2V DSRC devices used for NHTSA research in the
Safety Pilot activities are allowed to transmit at up to 33 dBm \198\
(approximately 2.0 watts of power output), as defined by FCC
specifications.\199\ 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.
---------------------------------------------------------------------------
\197\ Radio Frequency FAQ, http://www.pge.com/en/safety/systemworks/rf/faq/index.page (last accessed Jun. 5, 2015).
\198\ dBm or decibel-milliwatt is an electrical power unit in
decibels (dB), referenced to 1 milliwatt (mW). The power in decibel-
milliwatts (P(dBm)) is equal to 10 times base 10 logarithm of the
power in milliwatts (P(mW)).
\199\ ``Table I.5a--Maximum STA transmit power classification
for the 5.85-5.925 GHz band in the United States'', IEEE
specification 802.11P-2010, Page 31. Available at https://www.ietf.org/mail-archive/web/its/current/pdfqf992dHy9x.pdf (last
accessed Dec. 12, 2016).
---------------------------------------------------------------------------
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
[[Page 3933]]
these messages to the end-user community.\200\
---------------------------------------------------------------------------
\200\ Recommendations on Consumer Acceptance of Smart Grid,
Electricity Advisory Committee, Richard Cowart, Chair to Honorable
Patricia Hoffman, Assistant Secretary for Electricity Delivery and
Energy Reliability, U.S. Department of Energy, June 6, 2013. http://energy.gov/sites/prod/files/2013/06/f1/EAC_SGConsumerRecs.pdf (last
accessed Dec 12, 2016).
---------------------------------------------------------------------------
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: \201\
---------------------------------------------------------------------------
\201\ ``Questions and Answers about Biological Effects and
Potential Hazards of Radiofrequency Electromagnetic Fields'', OET
Bulletin 56, Fourth Edition, August 1999, Federal Communications
Commission, Office of Engineering and Technology. Available at
https://transition.fcc.gov/Bureaus/Engineering_Technology/Documents/bulletins/oet56/oet56e4.pdf (last accessed Dec 12, 2016).
---------------------------------------------------------------------------
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.\202\
---------------------------------------------------------------------------
\202\ ``Evaluating Compliance with FCC Guidelines for Human
Exposure to Radio frequency Electromagnetic Fields'', Federal
Communications Commission, Office of Engineering & Technology, OET
Bulletin 65 (Edition 97-01), August 1997. Available at