Federal Motor Vehicle Safety Standards; V2V Communications, 3854-4019 [2016-31059]
Download as PDF
3854
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
National Highway Traffic
Safety Administration (NHTSA),
Department of Transportation (DOT).
ACTION: Notice of Proposed Rulemaking
(NPRM).
AGENCY:
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.
SUMMARY:
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 https://
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
DATES:
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 https://
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
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:
gregory.powell@dot.gov. 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:
rebecca.yoon@dot.gov.
FOR FURTHER INFORMATION CONTACT:
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
PO 00000
Frm 00002
Fmt 4701
Sfmt 4702
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
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 shortrange 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 invehicle 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
PO 00000
Frm 00003
Fmt 4701
Sfmt 4702
3855
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 vehicleresident systems. These unique
characteristics allow V2V-equipped
vehicles to perceive and warn drivers of
some threats sooner than vehicleresident 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 radarand 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
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3856
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
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
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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00004
Fmt 4701
Sfmt 4702
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
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
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 https://
www.its.dot.gov/pilots/cv_pilot_apps.htm (last
accessed: Dec 7, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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:
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
PO 00000
Frm 00005
Fmt 4701
Sfmt 4702
3857
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 phasein 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.
E:\FR\FM\12JAP2.SGM
12JAP2
3858
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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 V2Venabled 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.
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-of2015-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-bureauconsumer-protection-federal-trade-commissionfederal-communications-commission/
160527fcccomment.pdf (last accessed Dec 7, 2016).
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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.
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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00006
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
3859
TABLE I–1—COSTS * AND BENEFITS IN YEAR 30 OF DEPLOYMENT
[2051]
Per vehicle
costs
Total annual costs
$2.2 billion–$5.0 billion .................................................
$135–$301
Crashes prevented and lives saved
Crashes: 424,901–594,569 ..........................................
Lives: 955–1,321 ..........................................................
Monetary
benefits
(billions)
$53–$71
* Note: Does not include spectrum opportunity costs, which will be included in the analysis of the final rule.
In order to account for the inherent
uncertainty in the assumptions
underlying this cost-benefit analysis, the
agency also conducted extensive
uncertainty analysis to illustrate the
variation in the rule’s benefits and costs
associated with different assumptions
about the future number of accidents
that could be prevented, the assumed
adoption rates and estimated
effectiveness of the two safety
applications, and our assumptions about
the costs of providing V2V
communications capability. Aside from
opportunity costs, this analysis showed
that the proposed rule would reach its
breakeven year between 2030 and 2032
with 90 percent certainty, with even the
most conservative scenario showing that
the breakeven year would be five to six
years later than the previously estimated
years (2029–2032). Considering these
same sources of uncertainty in the costeffectiveness 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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 ‘‘ifequipped’’ 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 V2Vcapable 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.
PO 00000
Frm 00007
Fmt 4701
Sfmt 4702
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 https://wwwnrd.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 https://wwwfars.nhtsa.dot.gov/Main/index.aspx (last accessed
Dec 7, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
3860
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
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 nearterm 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
srobinson on DSK5SPTVN1PROD with PROPOSALS2
8 For more information, see the agency policy
statement on automated vehicles at https://
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).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
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,
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-scaleais/ (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=nonincapacitating 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.
PO 00000
Frm 00008
Fmt 4701
Sfmt 4702
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
Because V2V is a communicationsbased 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 multivehicle 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.
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: https://www-nrd.nhtsa.dot.gov/pubs/
812013.pdf (last accessed Dec 7, 2016).
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.
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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. https://
www.nhtsa.gov/Research/Crash-Avoidance/Vehicle
%E2%80%93to%E2%80%93VehicleCommunications-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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
deemed potentially addressable by V2V
communications. Further statistical
analysis focusing on the frequency and
severity of those 17 pre-crash scenarios
identified the top 10 (priority) pre-crash
scenarios that V2V could potentially
address. Table II–1 provides a graphical
depiction of the flow of the pre-crash
scenario breakdown used in the
analysis.
TABLE II—1 37 PRE-CRASH SCENARIO
TYPOLOGY
1. Vehicle Failure.
2. Control Loss with Prior Vehicle Action.
3. Control Loss without Prior Vehicle Action.
4. Running Red Light.
5. Running Stop Sign.
6. Road Edge Departure with Prior Vehicle
Maneuver.
7. Road Edge Departure without Prior Vehicle Maneuver.
8. Road Edge Departure While Backing Up.
9. Animal Crash with Prior Vehicle Maneuver.
10. Animal Crash without Prior Vehicle Maneuver.
https://www.nhtsa.gov/Research/Crash-Avoidance/
Vehicle%E2%80%93to%E2%80%93VehicleCommunications-for-Safety (last accessed Dec 8,
2016).
PO 00000
Frm 00009
Fmt 4701
Sfmt 4702
TABLE II—1 37 PRE-CRASH SCENARIO
TYPOLOGY—Continued
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.
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.000
2. Pre-Crash Scenarios Potentially
Addressed by V2V Communications
3861
3862
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE II—1 37 PRE-CRASH SCENARIO
TYPOLOGY—Continued
TABLE II—1 37 PRE-CRASH SCENARIO
TYPOLOGY—Continued
TABLE II—1 37 PRE-CRASH SCENARIO
TYPOLOGY—Continued
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.
The 10 priority pre-crash scenarios
listed in Table II–2 can be addressed by
the corresponding V2V-based safety
applications.
TABLE II–2—PRE-CRASH SCENARIO/SAFETY APPLICATION ASSOCIATION
Pre-crash groups
Lead Vehicle Stopped ..................
Lead Vehicle Moving ....................
Lead Vehicle Decelerating ...........
Straight Crossing Path @ Non
Signal.
Left-Turn Across Path/Opposite
Direction.
Opposite Direction/No Maneuver
Opposite Direction/Maneuver .......
Change Lanes/Same Direction ....
Turning/Same Direction ................
Drifting/Same Direction .................
Associated safety application
Rear-end .....................................
Rear-end .....................................
Rear-end .....................................
Junction Crossing .......................
Forward Collision Warning.
Forward Collision Warning.
Forward Collision Waring/Emergency Electronic Brake Light.
Intersection Movement Assist.
Left Turn @ crossing ..................
Left Turn Assist.
Opposite Direction ......................
Opposite Direction ......................
Lane Change ..............................
Lane Change ..............................
Lane Change ..............................
Do Not Pass Warning.
Do Not Pass Warning.
Blind Spot/Lane Change Warning.
Blind Spot/Lane Change Warning.
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
16 Average of 2010–2013–GES data; * Includes
only 2&3 vehicle crashes; ** Includes running redlight and running stop sign.
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 https://www.its.dot.gov/
research_archives/safety/cv_safetypilot.htm for
more information. (last accessed Dec 7, 2016).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00010
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.001
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Pre-crash scenarios
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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 precrash scenarios is provided below.
(1) Forward Collision Warning (FCW):
Warns drivers of stopped, slowing, or
slower vehicles ahead. FCW addresses
rear-end crashes that are separated into
three key scenarios based on the
movement of lead vehicles: Leadvehicle 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 oppositedirection 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
3863
the breakdown of V2V pre-crash
scenarios and relationships to prototype
V2V safety applications. The 3.4 million
LV2LV are distributed among the precrash 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
Comprehensive
costs
(billion)
Crash scenarios
FCW Rear-End Crashes
Lead Vehicle Stopped ..
Lead Vehicle Moving ....
Lead Vehicle Decelerating.
998,664
146,247
343,183
497,907
80,508
173,538
242
242
78
68,508
12,605
25,599
$27.4
$4.6
$9.5
$65.7
$12.9
$23.1
Total ..............................
1,488,094
751,953
562
106,712
$41.5
$101.6
Turn-Into Path, Into
Same Direction or
Opposite Direction.
Straight Cross Path ......
425,145
218,852
472
48,423
$12.6
$34.8
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.
BS/LCW Lane Change/
Merge Crashes.
Others ...........................
Turn Across Path, Initial
Opposite Direction.
Vehicle Changing Lane,
Same Direction.
298,542
224,336
613
64,233
$11.7
$37.9
475,097
175,044
397
20,816
$11.4
$26.6
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
srobinson on DSK5SPTVN1PROD with PROPOSALS2
IMA Intersection Crossing Crashes.
MAIS 1–5
injuries
Economic
costs
(billion)
V2V Safety applications—crashes
Crashes
Fatalities
PDOVs
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,
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00011
Fmt 4701
Sfmt 4702
recent years, vehicle manufacturers
have begun to offer, or have announced
plans to offer, various types of crash
avoidance technologies that are
E:\FR\FM\12JAP2.SGM
12JAP2
3864
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
designed to do just that. These
technologies are designed to address a
variety of crashes, including rear end,
lane change, and intersection.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
1. Radar and Camera Based Systems
Many of the advanced crash
avoidance technologies currently
available in the marketplace employ onboard sensor technologies such as
cameras, RADAR, or LIDAR, to monitor
the vehicles’ surroundings.18 These
technologies are what we call ‘‘vehicleresident’’ 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 vehicleresident 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 crashpredicting safety applications leveraging
these existing sensing technologies are
beginning to emerge and NHTSA is
aggressively pursuing those
technologies that demonstrate safety
benefits.
Vehicle-resident systems can be
highly effective in mitigating certain
crash types, although their performance
varies by sensor type, and is limited in
certain situations. Perception range
varies from 10 meters to 200 meters for
LIDAR and 77 GHz radar, respectively,
while field-of-view ranges from 18
degrees to 56 degrees for 77 GHz radar
and 24 GHz radar,21 respectively. Onboard sensors can also exhibit reduced
reliability in certain weather conditions
(e.g., snow, fog, and heavy rain), and
camera systems, in particular, can
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 rearend 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.
21 ‘‘Vehicle-to-Vehicle Communications:
Readiness of V2V Technology for Application’’,
August 2014, pp. 105.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
exhibit reduced performance when
encountering lighting transitions and
shadows. Most if not all current sensing
technologies are susceptible to
performance reductions through foreign
objects such as dirt or snow. For
camera-based systems, some
manufacturers have implemented
devices that attempt to keep the camera
clear for maximal operation. Both sensor
types can be vulnerable to misalignment
or damage over time. On-board sensors
do, however, perform reliably in ‘‘urban
canyons’’ and other situations in which
a clear view of the sky is not needed.
2. Communication-Based Systems
Devices enabling vehicles to
communicate with one another or with
road-side equipment and/or
infrastructure have been prototyped and
tested in field operational tests like the
Safety Pilot Model Deployment. These
devices, when eventually developed for
mass production, could be fully
integrated into a vehicle when
manufactured, or could be standalone
aftermarket units not restricted to a
single vehicle. These devices offer
varying degrees of functionality, but all
are designed to communicate safety
information to help mitigate crashes.
Safety information that can help
mitigate crashes includes data elements
like vehicle position, heading, speed,
and so forth—data elements that could
help a computer-based safety
application on a vehicle calculate
whether it and another vehicle were in
danger of crashing without driver
intervention. These pieces of
information are collected into what is
known as a ‘‘Basic Safety Message,’’ or
‘‘BSM.’’ In a fully-integrated vehicle
communication system, the system is
built into the vehicle during production,
and consists of a general purpose
processor and associated memory, a
radio transmitter and transceiver,
antennas, interfaces to the vehicle’s
sensors, and a GPS receiver. It generates
the BSM using in-vehicle information
obtained from the vehicle’s on board
sensors. An integrated system can both
transmit and receive BSMs, and can
process the content of received
messages to provide advisories and/or
warnings to the driver of the vehicle in
which it is installed. Since the vehicle
data bus provides a rich data set,
integrated systems have the potential to
obtain information that could indicate
driver intent, which can help inform
safety applications such as Left Turn
Assist (LTA),22 Do Not Pass Warning
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.
PO 00000
Frm 00012
Fmt 4701
Sfmt 4702
(DNPW),23 and BSW/LCW safety
applications, all of which can benefit
from, or require, information on turn
signal status or steering wheel angle.
Aftermarket devices, which are added
to a vehicle after its assembly, can vary
significantly from both fully-integrated
vehicle communication systems, and
from one another. The simplest designs
may only transmit (and not also receive)
a BSM, may only connect to a power
source and otherwise operate
independently from the systems in the
vehicle, and may not run safety
applications or provide advisories/
warnings to a driver.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.
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
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.
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’’).
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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 highcapacity 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.
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
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
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
25 BAH CDDS Final Report. See Docket No.
NHTSA–2014–0022.
26 BAH CDDS Final Report. See Docket No.
NHTSA–2014–0022.
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.
28 Report and Order FCC–03–0324.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
security risks are also inherent to DSRC
technology.
In this NPRM, the proposal would
require V2V communication to use
DSRC devices to transmit messages
about a vehicle’s speed, heading,
braking status, etc. to surrounding
vehicles, as well as to receive
comparable information from
surrounding vehicles. As DSRC is based
on radio signals, which are
omnidirectional (i.e., offer 360 degrees
of coverage), V2V offers the ability to
‘‘see’’ around corners and ‘‘see’’ through
other vehicles. Consequently, V2V is not
restricted by the same line-of-sight
limitations as crash avoidance
technologies that rely on vehicleresident 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 ‘‘deadreckoning.’’ 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.
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
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.
PO 00000
Frm 00013
Fmt 4701
Sfmt 4702
3865
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
E:\FR\FM\12JAP2.SGM
12JAP2
3866
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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 onboard 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,
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00014
Fmt 4701
Sfmt 4702
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 vehicleto-vehicle connectivity as reason to
suggest that V2V is unnecessary for fullscale 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 nonautonomous 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.
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
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 invehicle safety systems, aftermarket
safety devices, or vehicle awareness
devices, all using DSRC to emit wireless
31 See Section II.B of the Readiness Report,
available at https://www.safercar.gov/v2v/ (last
accessed Dec 7, 2016).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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;
PO 00000
Frm 00015
Fmt 4701
Sfmt 4702
3867
• 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
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3868
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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).
• 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.
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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
(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
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.
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.
PO 00000
Frm 00016
Fmt 4701
Sfmt 4702
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 WiFi enabled devices can share the
spectrum successfully with V2V, and if
so, how. In December 2015 and January
2016, the DOT, FCC, and the
Department of Commerce sent joint
letters to members of the U.S. Senate
Committee on Commerce, Science, and
Transportation, delineating a
collaborative multi-phased approach
that will be used to provide real-world
data on the performance of unlicensed
devices that are designed to avoid
interfering with DSRC operations in the
5.85–5.925 GHz band.
• V2V device certification issues:
V2V devices are different from other
technologies regulated by NHTSA under
the Federal Motor Vehicle Safety
Standards, insofar as part of ensuring
their successful operation (and thus, the
safety benefits associated with them)
requires ensuring that they are able to
communicate with all other V2V
devices participating in the system. This
means that auto manufacturers (and
V2V device manufacturers) attempting
to comply with a potential V2V mandate
could have a significant testing
obligation to guarantee interoperability
among their own devices and devices
produced by other manufacturers. At
the time of the Readiness Report, it was
an open question whether individual
companies could meet such an
obligation themselves, or whether
independent testing facilities might
need to be developed to perform this
function. Based on the security design
evaluated for the report, it was thought
likely that an entity or entities providing
the security management system would
require that device manufacturers
comply with interoperability
certification requirements to ensure the
reliability of message content. The
agency currently believes the creation of
a standardized test device should
mitigate manufacturer to manufacturer
communication variances to help ensure
interoperability.
• Test procedures, performance
requirements, and driver-vehicle
interface (DVI) issues: Test procedures,
performance requirements, and drivervehicle 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
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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.
• 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
• 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
35 ‘‘Development of DSRC Device and
Communication System Performance Measures’’
Booz Allen Hamilton, Final Report—May, 2016;
FHWA–JPO–17–483 available at https://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.
36 Section II.F discusses NHTSA’s Request for
Information (RFI) regarding the development of a
potential Security Credential Management System
(SCMS).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00017
Fmt 4701
Sfmt 4702
3869
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 nonfunctioning V2V capabilities.37
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.
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.
E:\FR\FM\12JAP2.SGM
12JAP2
3870
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE II–4—DSRC PERFORMANCE REQUIREMENTS AND COMPLIANCE TESTING RESEARCH
[NPRM RELEVANT]
Readiness report research
need
Description
Research projects initiated to
address
Description
Standards Need V–1 SAE
Standards Maturity.
Currently Standards are being
developed by outside standards organizations.
Crash Avoidance Metrics Partnership V2V Interoperability
and V2V System Engineering Projects.
Research Need V–2 Impact of
Software Implementation on
DSRC Device Performance.
[V–2] V2V device software updates may be required over
its lifecycle. NHTSA will
need to determine how to
ensure necessary V2V device software updates are
seamless for consumers and
confirmed.
Research Need V–3 DSRC
Data Communication System
Performance Measures.
[V–3] The purpose of this research is to finalize the operational modes and scenarios, key functions, and
qualitative
performance
measures that indicate minimum operational performance to support DSRC safety and security communication functions.
[V–5] Complete congestion
mitigation and scalability research to identify bandwidth
congestion conditions that
could impair performance of
safety or other applications,
and develop appropriate
mitigation approaches.
[V–6] Research will be required to determine how to
test relative positioning performance across GPS receivers produced by different
suppliers and yield a generalized relationship between
relative and absolute positioning.
[V–7] Research to understand
potential erroneous position
reporting due to positional
biases across multiple GPS
receiver combinations.
[VI–7] Development of performance requirements, test
procedures, and test scenarios to evaluate a device’s
compliance with interoperability standards, security
communication needs; and
to support safety applications.
DSRC On-Board Unit Performance Measures Booze Allen
and Hamilton.
Crash Avoidance Metrics Partnership—Documentation of
On-Board Unit Requirements
and Certification Procedures
for V2V Systems (System
Engineering Project).
and
V2V-Comminication Research
project.
..................................................
Crash Avoidance Metrics Partnership providing results of
DSRC device performance
requirements to SAE standards development committee
for SAE J2735 and J2945.
BAH project will Develop performance
measures
for
Dedicated
Short
Range
Communication (DSRC) device; and develop security
performance measures for
the following, but not limited
to Critical components on
the DSRC device, Firmware
on the DSRC device, Predominant elements in a Public Key Infrastructure (PKI).
..................................................
Research Need V–5 BSM
Congestion Sensitivity.
Research Need V–6 Relative
Positioning Performance
Test.
Research Need V–7 Vehicle
and Receiver Positioning Biases.
Research Need VI–7 Compliance Specifications and Requirements.
..................................................
April 2016.
BAH Completion date—Requirements October 2015/
Test Procedures October
2015.
CAMP System Engineering
Completion date—Requirements Aug 2015/Test Procedures Sept 2015.
CAMP Communications research completion date—August 2016.
CAMP will develop a single
comprehensive
document
summarizing the minimum
level of Connected Vehicle
(CV) V2V safety system onboard requirements and certification procedures..
..................................................
Completion date
CAMP V2V Communications
Research Project will identify
requirement in relation to
BSM message congestion
mitigation and misbehavior
detection.
TABLE II–5—SYSTEM, SECURITY, AND ACCEPTANCE RESEARCH
[NPRM RELEVANT]
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Readiness report research
need
Policy Need IV–1 Road Side
Equipment Authority.
VerDate Sep<11>2014
Description
Research projects initiated to
address
Description
NHTSA will evaluate the need
for DOT to regulate aspects
of RSE operation and assess its authority for doing
so.
Authority evaluation conducted
for NPRM.
..................................................
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00018
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
Completion date
Issuance of NPRM.
3871
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE II–5—SYSTEM, SECURITY, AND ACCEPTANCE RESEARCH—Continued
[NPRM RELEVANT]
Readiness report research
need
Description
Research projects initiated to
address
Description
Policy Need IV–2 V2V Device
Software Updates.
V2V device software updates
may be required over its
lifecycle. NHTSA will need to
determine how to ensure
necessary V2V device software updates are seamless
for consumers and confirmed.
Crash Avoidance Metrics Partnership V2V System Engineering project and Crash
Avoidance Metrics Partnership
Security
Credential
Management System Proof
of Concept project.
Research Need V–1 Spectrum
Sharing Interference.
Evaluate the impact of unlicensed U–NII devices on the
transmission and reception
of safety critical warnings in
a shared spectrum environment.
Testing spectrum sharing feasibility.
The
System
Engineering
project will investigate software update requirements
from the vehicle perspective
as the Security Credential
Management
Systems
project investigates software
update from the security system
perspective.
Both
projects will identify requirements that will facilitate the
software update of V2V devices.
A test plan for testing unlicensed devices that would
share the band with licensed
DSRC devices has been developed. The testing will
evaluate the feasibility of
sharing spectrum with unlicensed devices.
Research Need VII–1 Consumer Acceptance.
Supplement the driver acceptance analysis completed per
the Driver Clinics and Safety
Pilot Model Deployment with
further research that includes a focused assessment of privacy in relation to
V2V technology.
V2V Crash Avoidance Safety
Technology Public Acceptance Review.
Research Need VIII–1 V2V Location Tracking via BSM.
[VIII–1] Assess the availability
of information and technologies that facilitate linking
data in the BSM to determine a motor vehicle’s path.
Independent Evaluation of V2V
Security Design and Technical Analysis of the Potential Privacy Risk of V2V Systems.
Research Need VIII–2 V2V
Identification Capabilities.
[VIII–2] Understanding and
quantifying risk of linking vehicle tracking or other information in the BSM to a specific vehicle, address, or individual via available resources (including but not
limited to database matching
or data mining).
[VIII–3] Inventory and assess
the privacy controls applicable to the SCMS in connection with our comprehensive
privacy assessment.
[VIII–4] A comprehensive privacy risk analysis of all aspects of the V2V system including infrastructure equipment, on-board vehicle systems, wireless and wired
communications, as well as
organizational and management issues.
Research Need VIII–3 V2V Inventory of Privacy Controls.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Research Need VIII–4 V2V Privacy Risk Assessment.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00019
Fmt 4701
Sfmt 4702
This review needs to extend
the current evaluation of
driver acceptance to a
broader public acceptance
context and evaluate how
public acceptance may impact and or influence the design, performance, operation, and implementation of
this technology.
The objective of this Task
Order is to perform: (1) an
independent
and
comprehensive technical analysis of the V2V security system design that is currently
proposed specifically for a
V2V connected vehicle environment; and (2) a technical
analysis of the potential privacy risks of the entire V2V
system that includes security
but also focuses on the operation of V2V communications in support of crash
avoidance safety applications.
E:\FR\FM\12JAP2.SGM
12JAP2
Completion date
Completion Date for Requirements—Sept 2015.
The evaluation of spectrum
sharing interference is pending the conduct of tests with
representative U–NII–4 devices that operate in the 5.9
GHz (DSRC) frequency
band.Testing could be completed within 12 months of
receipt of prototype devices.
September 2015.
March 2016.
3872
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE II–5—SYSTEM, SECURITY, AND ACCEPTANCE RESEARCH—Continued
[NPRM RELEVANT]
Readiness report research
need
Research Need IX–2 Cryptographic flexibility.
Research Need IX–3 Independent Security Design Assessment.
Research Need IX–1 Misbehavior Authority.
Research projects initiated to
address
Description
[IX–2] The chosen cryptographic algorithms are estimated to be resilient against
brute force attack for a few
decades with some susceptibility through an unanticipated weakness. In the future new algorithms could
enable better performance
but may require redesign of
functions or operations within the SCMS.
[IX–3] Independent evaluation
of CAMP/USDOT security
design to assess alignment
with Government business
needs, identify minimum requirements, assess the security designs ability to support trusted messages and
appropriately protect privacy,
identify and remove misbehaving devices, and be flexible enough to support future
upgrades.
Development of the processes,
algorithms, reporting requirements, and data requirements for both local and
global detection functions;
and procedures to populate
and distribute the CRL.
Description
Completion date
Crash Avoidance Metrics Partnership System Engineering
project, Security Credential
Management Proof of Concept project, and Communication Research Project.
The CAMP System engineering project will investigate
the implementation and device requirements for local
(vehicle based) misbehavior
detection and global (system-wide) misbehavior detection. The Communication
Research project will research local and global misbehavior detection needs.
The SCMS Proof of Concept
will investigate implementation aspects from the security system perspective.
Initial Misbehavior Detection information to be completed
December 2015.
TABLE II–6—V2V SAFETY APPLICATION IMPROVEMENT AND PERFORMANCE VERIFICATION RESEARCH
[NPRM IRRELEVANT]
Readiness report research
need
Research projects initiated to
address
Description
Volpe False Alert Scenarios
and Objective Test Procedures for Crash Avoidance
Applications project and Vehicle Research and Test
Center project.
Research Need VI–3 Practicability of Non-Ideal Driving
Condition Testing.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Research Need V–4 Develop[V–4] This research will take
ment of Safety Application
the performance measures
Test Metrics and Procedures.
and objective test proceResearch Need VI–2 Safety
dures used during the reApplication Performance
search of V2V applications
Measure Rationale.
and develop FMVSS level
performance measures and
safety application objective
tests.
..................................................
VerDate Sep<11>2014
[VI–1] Assess the capability
and capacity of possible refinements to reduce frequency of false positive
warning while maintaining
crash avoidance effectiveness.
[VI–2] Develop a rationale to
support each performance
and
test
metric
recommended for incorporation
into an FMVSS.
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00020
Fmt 4701
Sfmt 4702
Description
Completion date
The Volpe project will support Volpe Completion Date—DeNHTSA
development
of
cember 2018.
false-positive warning objec- VRTC Completion Date—April
tive test procedures in con2019.
junction with development of
objective test procedures
and performance criteria for
IMA, LTA, FCW, and BS/
LCW applications. The results of this IAA will contribute to potential Federal
Motor Vehicle Safety Standards (FMVSS) for these
crash avoidance applications.
The VRTC project will incorporate results and information from the Volpe project to
develop Federal Motor Vehicle
Safety
Standards
(FMVSS) for these crash
avoidance applications.
E:\FR\FM\12JAP2.SGM
12JAP2
3873
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE II–6—V2V SAFETY APPLICATION IMPROVEMENT AND PERFORMANCE VERIFICATION RESEARCH—Continued
[NPRM IRRELEVANT]
Readiness report research
need
Research Need VI–4 Fused
and Non-Fused V2V Safety
Application Test Procedures.
Research Need VI–5 Performance and Test Metric Validation.
Research Need VI–1 False
Positive Mitigation.
Research Need VI–6 DVI Minimum Performance Requirements.
[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.
[VI–4] Develop test procedures
that can be applied to systems relying solely on V2V
information as well as
‘‘fused’’ systems, those relying on both V2V and other
sources of information (e.g.,
on-board sensors).
[VI–5] Conduct test validation
to ensure that the performance and test metrics are
objective, repeatable, and
practicable.
Assess the capability and capacity of possible refinements to reduce frequency
of false positive warning
while
maintaining
crash
avoidance effectiveness.
Determine DVI’s impact on effectiveness of system and
safety benefits applications
to establish minimum performance for crash avoidance and objective test procedures.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
VerDate Sep<11>2014
Research projects initiated to
address
Description
23:49 Jan 11, 2017
Jkt 241001
Description
Volpe False Alert Scenarios
and Objective Test Procedures for Crash Avoidance
Applications project and.
The Volpe project will support
NHTSA
development
of
false-positive warning objective test procedures in conjunction with development of
objective test procedures
and performance criteria for
IMA, LTA, FCW, and BS/
LCW applications.
Testing DVIs for Intersection
Movement Assist and Left
Turn Assist for stopped vehicles.
V2V On-Road DVI Project .......
reduce costs,38 and also to facilitate
cross-border traffic, as between NAFTA
countries.39 A number of commenters
discussed existing or underdevelopment 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
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
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.
42 Mercedes at 7.
43 Mercedes at 7.
44 Automotive Safety Council at 3; TRW
Automotive at 7.
45 TRW Automotive at 7.
PO 00000
Frm 00021
Fmt 4701
Sfmt 4702
Completion date
Volpe Completion Date—December 2018.
VTTI Completion Date: November 2016.
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
NHTSA recognizes the value of
implementing V2V in a globallyharmonized 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
46 Cohda
Wireless at 9.
at 50, Global at 19–20.
48 Mercedes at 8.
47 Alliance
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3874
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
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 privatesector 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
49 ‘‘Continuation of the Implementing
Arrangement between the U.S. Department of
Transportation and the European Commission’’
https://www.its.dot.gov/press/2015/
euro_commission.htm#sthash.URMW4OOH.dpuf
(last accessed Dec 8, 2016).
PO 00000
Frm 00022
Fmt 4701
Sfmt 4702
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 inprogress. Its scope is to address the need
for standardized Vehicle-toInfrastructure message sets and
interfaces, including:
Æ Signalized intersections
applications such as Signal Phase and
Timing, Signal Request, Signal Status,
Æ In-vehicle data message sets.
At this point, there is general
agreement on the data concepts in these
message sets, but there remain
differences in how the data is conveyed
between the infrastructure and the
vehicles. These differences are due to
project and communications
restrictions. For example, the U.S. is
planning for additional message sets for
enhanced functionality; whereas the
European approach may limit the initial
applications and simply add data
elements to the messages over time. ISO
Technical Specification 19091, a
standard covering to V2I and I2V
communications for signalized
intersections, is currently under
development and is incorporating both
harmonized content and recognizing
region-specific content—a practical
compromise resulting from existing
differences in signal standards. Overall,
19091 allows for substantial hardware
congruity while acknowledging that
fully identical message standards are
not viable at this time.
• HTG6 on Harmonized Development
of a Cooperative-ITS Security Policy
Framework: HTG6 assessed security
policy needs across international,
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
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/crossjurisdictional 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 intraCCMS communications will require
decisions when developing near-term
operational systems but those decisions
may have longer-term impacts on
crypto-agility, system flexibility, and
50 ‘‘Harmonized security policies for cooperative
Intelligent Transport Systems create international
benefits’’ October 16, 2016. https://ec.europa.eu/
digital-single-market/news/harmonized-securitypolicies-cooperative-intelligent-transport-systemscreate-international (last accessed: Dec 8, 2016).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
evolution of systems that must be
considered from the start.
• Critical near-term steps for policy
and decision makers to perform include:
Æ Minimize the number of CCMS:
Policy makers must determine the
number of CCMS that will be
operational within a local, regional, or
national jurisdiction. Increasing the
number of CCMS, in particular the root
authorities, significantly increases
complexity and cost.
Æ Assess risk and set appropriate
parameters for risk and privacy: No
system will ever be without risk. Policy
and decision makers must set acceptable
levels of internal and external risk, as
well as levels of privacy protection.
Further, systems managers must assess
these levels continuously throughout
the lifecycle both of the security
solution as well as end-entity (user)
devices and applications. Risk and
privacy levels come with trade-offs that
will need to be assessed by policy
makers.
Æ Choose appropriate trust models:
After system managers assess and
categorize risk, they can identify policy
and technical controls to mitigate risk.
Collectively, these controls support the
implementation of trust models that
range from no trust among security
entities to full trust that allows users
(‘‘trusted actors’’ that are accepted into
the C–ITS security environment) to
receive security services even after
leaving their ‘‘native’’ system in which
they are enrolled. Decisions are also
required to establish criteria that define
who are trusted actors and policies and
procedures for certification, enrollment,
removal in the event of misbehavior,
and reinstatement.
Æ Establish Governance: These
decisions include the identification and
convening of key stakeholders who will
require representation in ongoing
decision-making. Once convened, this
group will establish processes for
decision-making, define criteria for new
entrants into the governance process,
assign roles and responsibilities,
establish authority to provide
governance and enforcement, and
determine enforcement procedures.
Æ Implement harmonized processes:
The HTG6 team identified the priority
areas for harmonization in report
HTG6–3 and identified the interfaces
and data flows where the policies would
be applied in HTG6–4. Policy makers
will need to examine them to determine
which ones are appropriate both to
support their choice in trust models and
throughout the CCMS lifecycle.
HTG group members comprise a small
group of international experts who
worked together intensively with co-
PO 00000
Frm 00023
Fmt 4701
Sfmt 4702
3875
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.
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 marketdriven approach to safety, and possibly
other, application deployment.54
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
51 79
FR 49270.
No. NHTSA–2014–0022–0001.
53 79 FR 49270.
54 Id.
52 Docket
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3876
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
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.
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
55 Id.
56 Id.
57 Id.
58 Id.
59 V2V Readiness Report. Docket No. NHTSA–
2014–0022–0001. Page xv.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
information with each other and issued
warnings to their drivers.60
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
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
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
60 Id.
at xv.
at 15.
62 Id. at 25.
63 Id. at 65.
64 Id. at 119.
65 Id. at 158.
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.
73 79 FR 49270, 49271.
74 Id. See also id. at 49273–24.
61 Id.
PO 00000
Frm 00024
Fmt 4701
Sfmt 4702
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
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
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
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
75 Id.
at 49271.
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.
78 Id.
79 Id. at 49273.
80 Id. at 49272.
81 Id.
82 Id. at 49273.
83 See Docket No. NHTSA–2014–0022.
76 A
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
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
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
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 humanmachine 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 vehicleresident 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
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
While expressing general support for
the technology and NHTSA’s efforts in
90 See
Docket No. NHTSA–2014–0022–0266.
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.
94 See e.g., Docket No. NHTSA–2014–0022–0597.
95 See id.
96 See Docket No. NHTSA–2014–0022–0693.
97 Id.
91 See
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.
88 See Docket No. NHTSA–2014–0022–0655.
89 See Docket No. NHTSA–2014–0022–0414.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00025
Fmt 4701
Sfmt 4702
3877
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
Other government agencies also
submitted comments. The NTSB
commented that both V2V and vehicleresident 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
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
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.
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.
E:\FR\FM\12JAP2.SGM
12JAP2
3878
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
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.
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.
Questions in the RFI covered topics
such as potential governance structures
for the SCMS, requests for estimates of
necessary initial capital investment,
106 See
Docket No. NHTSA–2014–0022–0689.
Docket No. NHTSA–2014–0022–0331.
108 See Docket No. NHTSA–2014–0022–0502.
109 See Docket No. NHTSA–2014–0022–0682.
110 79 FR 49270 (Aug. 20, 2014).
111 79 FR 61927 (Oct. 15, 2014).
107 See
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 multistakeholder and cross-cutting nature of
the V2V ecosystem.
Additional details on the SCMS RFI
responses can be found in Section
V.B.4.
PO 00000
Frm 00026
Fmt 4701
Sfmt 4702
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-tovehicle 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
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
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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 redesign cycles. The proposal also allows
vehicles to comply using non-DSRC
technologies that meet certain
performance and interoperability
standards.
In addition to requiring new light
vehicles to be able to transmit and
receive BSMs over DSRC, the proposal
would also require that similarlycapable 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.
The agency has put forth this
proposed rule on the basis that a fullyimplemented 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
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 https://ntl.bts.gov/lib/60000/
60500/60535/FHWA-JPO-17-487_Final_.pdf (last
accessed Dec 12, 2016).
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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00027
Fmt 4701
Sfmt 4702
3879
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 manufacturersupplied 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 ifequipped 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
E:\FR\FM\12JAP2.SGM
12JAP2
3880
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
benefits of a mandate? For instance, we
seek additional comment on how an ifequipped 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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 carryin 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
PO 00000
Frm 00028
Fmt 4701
Sfmt 4702
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 doit-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.
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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.
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
115 Six potential applications were mentioned in
particular: IMA, FCW, DNPW, EEBL, BSW/LCW,
and LTA.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00029
Fmt 4701
Sfmt 4702
3881
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 V2Vcommunications 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
E:\FR\FM\12JAP2.SGM
12JAP2
3882
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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).
PO 00000
Frm 00030
Fmt 4701
Sfmt 4702
(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.
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
(b) Elevation Transmission Performance
srobinson on DSK5SPTVN1PROD with PROPOSALS2
In addition to the 2-dimension range
of the basic safety message transmission,
we need to consider the potential
changes in elevation on roadways. Thus,
in addition to establishing a minimum
distance that the basic safety message
needs to travel, we also need to
establish an elevation angle that the
message needs to travel.
Safety applications may need
information from vehicles at a higher
elevation (because of changes in the
slope of the roadway, for example).
Thus, our current belief is that a
proposal to regulate DSRC radio
performance should also evaluate
whether a vehicle transmitting the basic
safety message can transmit said
message at an angle that is sufficient to
cover potential roadway elevation
changes.
Our proposal would require that
vehicles transmit the basic safety
message not only to 300 m around a
vehicle (in all directions—i.e., 360
degrees) but also at an elevation angle
of +10 degrees and ¥6 degrees. We
think that the elevation angle range of
+10 to ¥6 degrees 360 degrees around
the vehicle is an appropriate range to
ensure that the broadcast of the BSM
can be received by vehicles in a 300m
radius given most roadway
characteristics such as changes in
roadway grade was what was used to
demonstrate capability in Safety Pilot
Model Deployment. The agency is
continuing to research a larger range of
elevation angle (+/¥10 degrees) to
determine actual transmission coverage
range. In particular, if the range would
be adequate to support transmission and
reception of BSMs on roadway grades
up to 15 degrees, which is the current
design maximum for many States and
localities (excluding San Francisco).
However, currently it is not practicable
to test the +/¥10 degree elevation angle
range given current testing equipment.
We ask for comment on this proposed
minimum. Should the agency choose a
different minimum elevation angle
requirement? What would be
appropriate alternative minimum
elevation angle range values and why?
Please provide data to support your
position.
(2) Testing the Elevation Transmission
Range
In order to give context to our
proposed requirement, we are also
describing the method the agency would
use in assessing the elevation angle
range performance requirement (i.e., the
test procedure and type of test device).
As discussed later in this document, the
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
3883
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
• 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
• 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
• 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
(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 2dimensional range with an elevation
angle that can be set at +10 degree and
¥6 degrees.
PO 00000
Frm 00031
Fmt 4701
Sfmt 4702
116 Vehicle reference point is the same point that
we defined in the basic safety message content
requirements section, above.
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.
119 See similar note, above.
120 See similar note, above.
E:\FR\FM\12JAP2.SGM
12JAP2
3884
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
PO 00000
Frm 00032
Fmt 4701
Sfmt 4702
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 nonoptimal 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
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
PO 00000
Frm 00033
Fmt 4701
Sfmt 4702
3885
(a) Channel
(i) Proposed Channel Usage
The FCC currently divides the 5.9
GHz spectrum into seven, tenmegahertz 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 Rechannelization
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
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3886
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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:
• Overall Goals as listed in the DSRCUnlicensed 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.
122 https://apps.fcc.gov/edocs_public/
attachmatch/FCC-16-68A1_Rcd.pdf.
121
VerDate Sep<11>2014
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 ‘‘ReChannelization’’), as well as on other
potentially viable approaches to sharing
in the band without causing harmful
interference to V2V operations.
The FCC described the two proposed
sharing approaches as follows: (1)
Detect and avoid, under which
unlicensed devices would monitor the
existing DSRC channels, and if they
detected any transmitted DSRC signal,
they would avoid using the entire DSRC
band. After waiting a certain amount of
time the unlicensed device would again
sense the DSRC spectrum to determine
if any DSRC channels are in use or
whether it could safely transmit; and (2)
Re-Channelization, under which the
DSRC spectrum would be split into two
contiguous blocks: one for safety-related
communications and one for non-safetyrelated 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
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00034
Fmt 4701
Sfmt 4702
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
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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).
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;
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.
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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
• 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
PO 00000
Frm 00035
Fmt 4701
Sfmt 4702
3887
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, https://
www.nhtsa.gov/Research/Crash-Avoidance/
Vehicle%E2%80%93to%E2%80%93VehicleCommunications-for-Safety (last accessed: Dec 8,
2016).
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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).
PO 00000
Frm 00036
Fmt 4701
Sfmt 4702
(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
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.002
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3888
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
3889
constant (regardless of the bitrate tested)
up to 500 m.126
(2) Reception
(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—
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
• The system shall set the DE_DSecond transmission power and distance from
the vehicle;
with a value corresponding to
• translate the 0’s and 1’s received
milliseconds within a minute of the
over the wireless airwaves into the basic
UTC time when the BSM Part I
safety message (i.e., using the
vehicle location data is determined by appropriate protocol suite to interpret
the positioning source. [MPR–
and unpack the wireless signal into the
BSMTX–DATAACC–008]
basic safety message content); and
• DE_DSecond shall be accurate to
• authenticate the signature of the
within 1 ms of the corresponding UTC basic safety message to confirm that the
time. [MPR–BSMTX–DATAACC–009] information is from an authenticated
source (i.e., to determine that the
• DE_DSecond shall have a value less
message is actually from a vehicle).
than 150 ms from the UTC time at
While the research (e.g., the V2V
which the BSM is transmitted (i.e., the
safety pilot) included many of these
age of the time used in DE_DSecond
aspects of performance, we tentatively
shall be less than 150 ms). [MPR–
believe that it is unnecessary to
BSMTX–DATAACC–010]
separately evaluate the vehicle’s ability
Note: Other measurements present in the
to receive the basic safety message as a
BSM should be aligned to DE_DSecond
number of indirect methods
insofar as possible in the implementation.
determining if a vehicle received the
Since other measurements present in the
information exist in the transmission
BSM do not have an absolute time stamp, it
requirements already, namely
is not clear how this is done in practice.
congestion detection and mitigation.
Nevertheless, practical implementations to
Although this may be
date have used the most recent measurement
counterintuitive, we believe that
updates known to the transmitter at the time
directly evaluating the reception of the
when the BSM is composed.
basic safety message is best conducted
126 See BAH DSRC Phase II Report Section
4.3.3.2.
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
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00037
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.003
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.
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).
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3890
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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 sublayers.
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00038
Fmt 4701
Sfmt 4702
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
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
(d) DSRC-Based Communication—
Applicable Industry Standards
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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
(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
(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;
PO 00000
Frm 00039
Fmt 4701
Sfmt 4702
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.
• 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
Voluntary consensus standards follow
a rigorous, industry inclusive
development process where each
standard is developed by an established
128 See ‘‘Standards Glossary’’ IEEE, https://
www.ieee.org/education_careers/education/
standards/standards_glossary.html (last accessed
Dec 12, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.004
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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?
3891
3892
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
In relation to DSRC V2V
Communications, to date two voluntary
consensus standard organizations have
developed separate, however,
interrelated standards based on DSRCenabled 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
a description of the IEEE ballot process,
see https://standards.ieee.org/develop/balloting.html
(last accessed Dec 12, 2016).
srobinson on DSK5SPTVN1PROD with PROPOSALS2
129 For
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
130 See ‘‘How OSI Works’’ https://
computer.howstuffworks.com/osi1.htm (last
accessed: Dec 12, 2016).
131 See ‘‘Physical Layer’’, https://www.linfo.org/
physical_layer.html (last accessed: Dec 12, 2016).
PO 00000
Frm 00040
Fmt 4701
Sfmt 4702
standards. The Standards cover how
data is communicated and interpreted
from one V2V device to another device
and processed to be used by crash
avoidance applications; analogous to
how your wireless router transfers data
via the internet to an application on
your computer such as a web browser.
The layers represent levels of
interfaces to enable the bits that
represent data to be properly
transported and interpreted. The layers
are illustrated in Figure III–5. The first
layer starts at the bit/hardware device
level and indicates how the steam of
raw information is sent to the next layer.
In relation to V2V this would be the
DSRC radio level. In addition to the raw
information, layer 2 organizes data
packets into network frames that are
transported across the V2V wireless
network. These first two levels are
covered by IEEE 802.11p. The next 3
layers are covered by IEEE 1609.x.
Layers 3, 4, and 5 handle the addressing
and routing of messages, management of
the packetization of data and delivery of
packets, and the coordination of
message transmissions and
authorization (security). Layer 6, session
layer, and layer 7, application layer, are
covered by SAE J2735 and SAE J2945
and provide for the conversion of
incoming data for use by the application
and interface protocols with the
applications.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)’’ https://
searchnetworking.techtarget.com/definition/OSI
(last accessed: Dec 12, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
layer, the IEEE 802.11–2012—IEEE
Standard for Information technologyTelecommunication 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
PO 00000
Frm 00041
Fmt 4701
Sfmt 4702
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.
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.005
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
3893
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 multichannel 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 multichannel 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
PO 00000
Frm 00042
Fmt 4701
Sfmt 4702
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.
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.006
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3894
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
3895
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 subsystem tests. The Auto OEMs conduct
tests at the system level to verify design
and system operations. After
installation, OEMs conduct vehicle
integration tests to verify installation
and system operation in relation to
design specification and regulation
identified performance requirements.
Once the integration is verified, the
Auto OEMs verify compliance with the
performance requirements. This
hierarchy demonstrates how top level
performance requirements supported by
standards provide the information to
successfully design and implement V2V
components that will be interoperable
and meet identified system level
performance requirements.
The voluntary consensus standards
provide information that support both
performance requirements and design
specifications, and are the bridge for
connecting the requirements to the
specifications. In relation to the NPRM,
the work performed by NHTSA in
relation to performance requirements is
to identify, and define performance
requirements and verification tests that
will indicate that V2V device have been
designed and implemented such that
these devices will operate to provide the
DSRC communications and security that
will support crash avoidance
applications.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00043
Fmt 4701
Sfmt 4702
(6) Summary of DSRC-Based BSM
Transmission Requirements
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.007
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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-
3896
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE III–1—SUMMARY OF BSM TRANSMISSION REQUIREMENTS
Requirement
Proposal
Basis
Relationship to standards
Reason
Range (longitudinal & lateral) ..
Minimum 300m; 360 degrees
around vehicle.
CAMP—application tested in
SPMD also calculation of
range needed for DNPW.
SAE J2945/1 ............................
Range (Elevation) ....................
At elevation angle of +10 degrees and ¥6 degrees.
Packet Error Rate <10% .........
All BSM transmissions and receptions on 172 (safety-critical communications).
6 Mbps .....................................
CAMP and BAH research and
testing capabilities.
CAMP and BAH .......................
FCC rules .................................
SAE J2945/1 ............................
The setting is based on the
need to provide accurate
and timely safety alerts. The
setting was obtained by extensively testing commercially available equipment
and automotive sensors in a
wide variety of driving environments.
Same as above.
SAE J2945/1 ............................
SAE J2945/1 ............................
Same as above.
Same as above.
CAMP and BAH research—
CAMP research shows PER
degradation using 12 Mbps.
BAH
research
indicates
problems after 500m, also
BAH test done under ‘‘open
field’’ conditions.
SAE J2945/1 (one of the
bitrates included in 802.11).
Transmission Frequency .........
10 times per second under
non-congested conditions.
SAE J2945/1 ............................
Staggering Transmission Time
Random transmission of BSMs
every 100 +/¥ms between 0
and 5 ms.
CAMP—trade-off between long
inter-packet delays experienced by V2V safety applications and heavy wireless
channel utilization.
Mitigate channel congestion if
all devices transmitted at
same time—CAMP and BAH
research.
Same as above—Also Current
developers support a 6
Mbps data rate. More data
and testing is needed to
change the data rate and
determine if a changing rate
can be used and support
crash avoidance.
Accepted among experts to
support V2V crash avoidance.
Reliability ..................................
BSM Radio Channel ................
Data Rate .................................
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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 performancebased 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.
SAE J2945/1 ............................
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.
(3) Reliability
Alternative technologies would need
to support the same message
transmission reliability requirements as
DSRC-based devices, minus any
reference to DSRC.
(2) Testing the Elevation Transmission
Range
(a) Transmit Power
Alternative technologies would need
to support he same message
transmission elevation test requirements
as DSRC-based devices.
Alternative technologies would need
to support the same message
Alternative technologies would need
to support the same message
Jkt 241001
(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.
(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) Test Device
23:49 Jan 11, 2017
transmission elevation transmission
performance test device requirements as
DSRC-based devices, minus any
reference to DSRC.
(iii) Elevation Transmission
Performance
Alternative technologies would need
to support the same message
transmission elevation performance
requirements as DSRC-based devices.
(1) Transmission Range and Reliability
VerDate Sep<11>2014
Due to accuracy of devices
need to mimic the stagger
experienced during SPMD to
avoid message collisions to
facilitate efficient channel
usage.
PO 00000
Frm 00044
Fmt 4701
Sfmt 4702
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
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
133 E.g.,
PO 00000
SAE Standard J2735, J2945.
Frm 00045
Fmt 4701
Sfmt 4702
3897
interoperability with vehicles that may
choose to send additional data elements,
we are generally proposing to permit
vehicles to transmit a data value that
either conforms to the SAE standard or
is the SAE-specified ‘‘data unavailable’’
value.
Finally, we are also proposing to
exclude certain data elements from
being transmitted as a part of the BSM.
We are proposing this limitation in
order to balance the privacy concerns of
consumers with the need to prove safety
information to surrounding vehicles.
While we request public input on any
of the issues discussed in this section,
we especially would like input on
whether we have appropriately selected
(1) the data elements to include/make
optional/exclude, and (2) the tolerance
levels for each data element.
(1) Required Data Elements and Their
Performance Metrics
In the work completed by SAE thus
far,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.
(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
134 SAE
E:\FR\FM\12JAP2.SGM
J2735 and J2945.
12JAP2
3898
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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.
(iii) Temporary ID
Finally, the Temporary ID is a fourbyte 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
135 SAE
Standard J2735, page 171.
136 Id. at page 212.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 randomlygenerated 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.
(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
137 Id.
at page 252.
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-200202I!!PDF-E.pdf.
138 Id.
PO 00000
Frm 00046
Fmt 4701
Sfmt 4702
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
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
140 See ‘‘Leap Seconds’’ https://
www.endruntechnologies.com/leap.htm (last
accessed Dec 12, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
(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
(ii) Longitude and Latitude
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
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 GPSderived position estimate depends upon both the
measurement geometry as represented by DOP
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
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
values, and range errors caused by signal strength,
ionospheric effects, multipath, etc.
PO 00000
Frm 00047
Fmt 4701
Sfmt 4702
142 As noted above, there are other factors that
may lead to degradation of the GPS information—
e.g., ionospheric interference, multipath, etc.
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.008
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).
3899
3900
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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.
(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.
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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00048
Fmt 4701
Sfmt 4702
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 GPSdetermined 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)
E:\FR\FM\12JAP2.SGM
12JAP2
3901
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
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
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.
(iii) Acceleration
For Acceleration, the agency would
require vehicles to report horizontal
(longitudinal and lateral) acceleration
with an accuracy of 0.3 m/s2 and
vertical acceleration to 1 m/s2. The
requirement is based on the need to
provide accurate and timely safety alerts
for the crash scenarios and
corresponding potential safety
applications identified in Table III–2.
The requirement was obtained by
extensively testing commerciallyavailable 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 commerciallyavailable 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
Lead Vehicle Stopped ..................................................................
Control Loss without Prior Vehicle Action ...................................
Vehicle(s) Turning at Non-Signalized Junctions ..........................
Straight Crossing Paths at Non-Signalized Junctions .................
Lead Vehicle Decelerating ...........................................................
Vehicle(s) Changing Lanes—Same Direction .............................
Left Turn Across Path—Opposite Direction ................................
Lead Vehicle Stopped ..................................................................
Control Loss without Prior Vehicle Action ...................................
Vehicle(s) Turning at Non-Signalized Junctions ..........................
Straight Crossing Paths at Non-Signalized Junctions .................
Lead Vehicle Decelerating ...........................................................
Vehicle(s) Changing Lanes—Same Direction .............................
Left Turn Across Path—Opposite Direction ................................
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
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.
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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
FCW
BSW/
LCW
IMA
LTA
CLW
..................
..................
..................
..................
✓
..................
..................
..................
..................
..................
..................
✓
..................
..................
✓
..................
..................
..................
✓
..................
..................
✓
..................
..................
..................
✓
..................
..................
..................
..................
..................
..................
..................
✓
..................
..................
..................
..................
..................
..................
✓
..................
..................
..................
✓
✓
..................
..................
..................
..................
..................
✓
✓
..................
..................
..................
..................
..................
✓
..................
..................
..................
✓
..................
..................
✓
..................
..................
..................
✓
..................
✓
..................
..................
..................
..................
..................
..................
✓
..................
..................
..................
..................
..................
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
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.
PO 00000
Frm 00049
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
3902
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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 inbetween 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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00050
Fmt 4701
Sfmt 4702
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 steadystate conditions (straight roadways or
curves with a constant radius of
curvature).
When a deviceis in steady state
conditions over a range from 100 m to
2,500 m in magnitude, the agency is
proposing to require that the subsystem
populate the PP data frame with a
calculated radius that has less than 2%
error from the actual radius. The agency
believes that this range and error rate is
appropriate to ensure the effectiveness
of safety applications that rely on such
information. For the purposes of this
performance requirement, steady state
conditions are defined as those which
occur when the vehicle is driving on a
curve with a constant radius and where
the average of the absolute value of the
change of yaw rate over time is smaller
than 0.5 deg/s2.
After a transition from the original
constant radius (R1) to the target
constant radius (R2), the subsystem
shall repopulate the PP data frame
within four seconds under the
maximum allowable error bound
defined above.
Lastly, when the transmitting vehicle
is stationary, we propose requiring that
a device report a ‘‘straight path’’ radius
of value 32,767 and confidence value of
100%, which corresponds to a value of
200 for the data element.
(iii) Exterior Lights
For the Exterior Lights data element,
the agency is proposing to require that
the subsystem shall set the individual
light indications in the data element to
be consistent with the vehicle status
data that is available. If meaningful
values are unavailable, or no light
indications will be set, the data element
should not be transmitted.
The data element, Exterior Lights,
provides the status of all exterior lights
on the vehicle, including parking lights,
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
• 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
PO 00000
Frm 00051
Fmt 4701
Sfmt 4702
3903
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.
(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
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.
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3904
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 preemption 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
PO 00000
Frm 00052
Fmt 4701
Sfmt 4702
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.
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
148 See
E:\FR\FM\12JAP2.SGM
FN 3 above.
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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-offon 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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
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
149 See
PO 00000
79 FR 19220.
Frm 00053
Fmt 4701
Sfmt 4702
3905
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.
E:\FR\FM\12JAP2.SGM
12JAP2
3906
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
Please provide any supporting
evidence that the agency can used to
make an informed decision.
(3) Summary Table of BSM Content
Requirements
TABLE III–3—SUMMARY OF BSM CONTENT REQUIREMENTS 150
Requirement
Proposal
Basis
Applicable
standards
Message Packaging ..........
Message ID—(2) for BSM
Message Count—sequence No.
Temp ID—random No.
from specific device.
Use UTC standard to set
time.
Preliminary elements need
to ID, process, and sequence BSMs.
SAE J2735 ........................
Allows device to interpret
message and obtain
safety information.
UTC is accepted standard
for setting universal system time.
Per CAMP research to develop relationship between measurable absolute position and relative
position.
Accurate elevation reduces
false positives—SPMD.
SAE J2735, J2945/1 .........
Need time standard to related messages to time
critical conflict situations.
Provides for accurate relative vehicle position
need to support crash
avoidance—(CAMP).
Time ...................................
Position (Longitude & Latitude).
Longitude and Latitude
within 1.5m of actual position at HDOP <5 and 1
sigma absolute error.
Position (Elevation) ...........
3m (10 feet) (more difficult
to calculate than lat/
long).
Movement (Speed) ............
Accurate within 0.28 m/s
(1 kph).
Same as EDR rule—tighter accuracy then identified by CAMP. Changed
to be consistent with existing standard.
SAE J2735, J2945/1 .........
Movement (Heading) .........
Speed >12.5 m/s accuracy
within 2 degree—Speed
>12.5 m/s within 3 degrees.
SAE J2735, J2945/1 .........
Movement (Acceleration) ..
Longitudinal & Lateral accuracy 0.3 m/s2—
Vertical accuracy 1 m/s.
Accuracy within 0.5 degrees per second.
Research indicates that
above 12.5 m/s sensors
and vehicle dynamics
can support 2 degrees—
under 12.5 m/s can support 3 degrees.
CAMP research and testing.
3m provides for low
bridges and changes in
grade for crash avoidance.
The setting is based on
the need to provide accurate and timely safety
alerts. The setting was
obtained by extensively
testing commercially
available equipment and
automotive sensors in a
wide variety of driving
environments.
Same as above.
SAE J2735, J2945/1 .........
Same as above.
CAMP ................................
SAE J2735, J2945/1 .........
CAMP ................................
SAE J2735, J2945/1 .........
The setting is based on
the need to provide accurate and timely safety
alerts. The setting was
obtained by extensively
testing commercially
available equipment and
automotive sensors in a
wide variety of driving
environments.
Same as above.
CAMP ................................
SAE J2735, J2945/1 .........
Same as above.
CAMP and MITRE privacy
research.
SAE J2735, J2945/1 .........
Balance the need to know
the physical extent of
the vehicle for crash
avoidance and still protect privacy.
Movement (Yaw rate) ........
Vehicle Motion Indicator
(Transmission).
Vehicle Motion Indicator
(Steering Wheel Angle).
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Vehicle Size .......................
Report if vehicle is in forward or reverse gear, or
neutral.
Report the direction of
steering wheel angle
within 5 degrees of actual.
Vehicle length and width
within 0.2m tolerance.
SAE J2735, J2945/1 .........
Reason
SAE 2735, J2945/1 ...........
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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00054
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
3907
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE III–3—SUMMARY OF BSM CONTENT REQUIREMENTS 150—Continued
Requirement
Proposal
Basis
Applicable
standards
Reason
Excluded Data Elements:
No data elements directly or, as a practical
matter, linkable to a specific individual or vehicle
(including but not limited
to VIN string, Owner
code, Temporary ID, Vehicle Type).
Path History .......................
Mandate that these optional data element cannot be populated for device in privately owned
light vehicles.
MITRE privacy research ...
SAE J2735, J2945/1 .........
To protect consumer privacy by reducing privacy
risk.
Provides concise repCAMP research to support
resentation of vehicles
crash avoidance.
recent movements with
accuracy of min 23
points and required to
be transmitted with BSM.
Perpendicular Distance—
CAMP research .................
1M; Radius error—2%;
Transmission Time 4s.
SAE J2735, J2945/1 .........
Use in calculations to identify vehicle conflict situations.
SAE J2735, J2945/1 .........
The setting is based on
the need to provide accurate and timely safety
alerts. The setting was
obtained by extensively
testing commercially
available equipment and
automotive sensors in a
wide variety of driving
environments.
Path Prediction ..................
3. Message Signing and Authentication
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00055
Fmt 4701
Sfmt 4702
• 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
E:\FR\FM\12JAP2.SGM
12JAP2
3908
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
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
Pseudonym Certificate
• Public Key ..................................
• Signature of the Pseudonym
Certificate Authority.
Validity Period ................................
• Says when certificate effective
and when expires.
Signature
(i.e., the speed, heading, location,
etc. information that supports
the safety applications).
Produced from the following
steps:
• Compute hash of the Message
Content and Timestamp.
• Use your private key to create
an encoded string of numbers.
• The encoded string of numbers
is your signature.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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.
(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.’’
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’’ https://www.embedded.com/
design/safety-and-security/4427811/Using-theElliptic-Curve-Digital-Signature-Algorithmeffectively, Feb. 2, 2014 (last accessed Dec 7, 2016).
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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
(b) Verifying the Signature Upon
Receipt
A device receiving the basic safety
message performs the following
PO 00000
Frm 00056
Fmt 4701
Sfmt 4702
Timestamp
(i.e., when the
transmitted.]).
information
is
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.
154 See ‘‘Secure Hashing’’ https://csrc.nist.gov/
groups/ST/toolkit/secure_hashing.html (last
accessed Dec 7, 2016).
155 See FIPS publication 186–4 at ‘‘FIPS
Publications’’ https://csrc.nist.gov/publications/
PubsFIPS.html (last accessed Dec 7, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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).
• 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
• 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.
156 See ‘‘On-Board System Requirements for V2V
Safety Communication’’ at https://standards.sae.org/
j2945/1_201603/ (last accessed Dec 7, 2016).
157 As discussed later in this section, the
timeframes for this test accommodate our current
proposal for changing certificates.
PO 00000
Frm 00057
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.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.
3909
3910
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
• 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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00058
Fmt 4701
Sfmt 4702
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
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
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.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
one set of credentials for every message.
However, as we described above, that
would create significant privacy risk by
associating all basic safety messages
sent from a single source with each
other.
In order to balance these competing
interests, our tentative conclusion is
that the current method for changing
certificates used in the research would
be a reasonable compromise that
protects privacy in a technically feasible
way. By rotating among 20 certificates
every five minutes, we are ensuring that
no group of basic safety messages will
be linked to more than 5 minutes of
other safety messages at a time. In other
words, a person obtaining basic safety
messages from a device may not be able
to associate those messages with each
other because their certificate is only
used for 5 minutes out of every 100
minutes. Further, a device shutting off
at one particular location would
unlikely use the same certificate upon
startup. Finally, in order to ensure that
a person could not obtain all 20
certificates for a particular device, we
are proposing for devices to completely
discard their certificates each week and
replace them with 20 new certificates.
We request comment from the public
on our proposed method for changing
certificates and privacy concerns. Have
we appropriately balanced the privacy
interest with the interest in maintaining
the technical feasibility of producing
and storing certificates in vehicles? Is
periodically rotating certificates the
right approach to limiting the privacy
impact of having signed messages? Have
we established the appropriate
thresholds for the method for changing
certificates (i.e., have we selected the
correct duration for when devices need
to rotate certificates and change the
certificates to new ones altogether?).
Further, should the agency establish
requirements for rotating the 20
certificates (i.e., should the device
rotating among 20 certificates every five
minutes use the same order for rotating
through the certificates or should the
device use a different order the next
time it cycles through the 20
certificates? What method should the
agency choose for changing the cycling
order of the 20 certificates?).
(iii) Test Method
As we discussed in Section
III.E.3.b)(2)(a), our static test method for
assessing whether a device is
appropriately signing their basic safety
messages can also assess whether a
device is changing its security
credentials as required if our test lasts
for an appropriate amount of time.
Based on our proposed requirements,
PO 00000
Frm 00059
Fmt 4701
Sfmt 4702
3911
we believe that it is appropriate to test
the device for 100 minutes twice,
separated by 7 days.
Testing the device for a 100 minute
duration would sufficiently assess
whether the device is rotating
certificates every five minutes and using
a different certificate every five minutes
for the duration of 100 minutes (i.e., 20
certificates × 5 minutes per certificate).
Finally, conducting this test twice
(separated by 7 days) would allow the
test to confirm whether the device is
using 20 new certificates that are
different from the certificates the device
used in the first test.
(e) Preventing Message Transmission
Without Valid Certificates From a SCMS
The agency is also considering
whether to require that devices stop
transmitting basic safety messages if
they lack valid security credentials, i.e.
device transmission problems or being
identified as a misbehaving device. The
purpose would be for devices to avoid
sending basic safety messages due to
incorrect credentials. However, at this
time, the agency does not have
performance requirements or a test
method for assessing this aspect of
performance. In order to test this aspect
of performance, the agency would need
a method for exhausting the certificate
supply of a vehicle and observing
whether the vehicle would continue to
transmit basic safety messages. We
request comment on whether there is a
practicable and repeatable way for
producing these conditions in a vehicle
under test. We also request comment as
to whether this aspect of performance
should be included in the final rule.
(3) Potential Regulatory Text for SCMS
Based Message Authentication
The agency has included no
regulatory text for SCMS-based message
authentication and instead has a
bracked placeholder for where it would
be if this were to be part of a final rule.
The agency expects that regulatory text
in any final rule would include:
• Additional definitions in S.4
Definitions for ’’ SCMS-based message
authentication, which would be
consistent the discussion in this
proposed rule and any public
comments.
• A provision on signing the BSM,
which would require that the device
must generate a signature for each BSM.
• A provision on rotating certificates.
(c) Alternative Approach—PerformanceBased Message Authentication
(1) Overview
The agency is also bringing forth
potential alternatives to the SCMS-based
E:\FR\FM\12JAP2.SGM
12JAP2
3912
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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 realworld conditions and also define those
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 selfdiagnosis 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 geolocation, time-stamp, and a digitally
signed (encrypted) certificate from the
misbehaving device would be recorded
PO 00000
Frm 00060
Fmt 4701
Sfmt 4702
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
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
• 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 rereported 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
PO 00000
Frm 00061
Fmt 4701
Sfmt 4702
3913
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 SCMSBased 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).
E:\FR\FM\12JAP2.SGM
12JAP2
3914
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
is not operating normally and some
form of repair is necessary. The
requirements proposed in this section
are consistent across any potential
technology employed in V2V
communications. The agency is not
specifying a format for the notification
mechanism, as elaborated below—it can
be an illuminated telltale, a message in
the message center, or something else—
but it must be presented in the vehicle
itself for OBE or on the device itself for
non-integrated aftermarket products.
This proposed requirement aligns with
the proposed misbehavior requirements
and cost estimates, in that misbehavior
detection requires devices to perform
self-diagnostics and report to users a
failure condition. Likewise, the cost
estimates for the proposal include costs
for some type of malfunction indicator
and reflect what we would consider to
be a ‘‘minimalist’’ approach.
The agency has a long history of
requiring both diagnostics and
malfunction indicators. FMVSSs for
electronic stability control (No. 126),
tire pressure monitoring systems (No.
138), and air bags (No. 208), among
others, include requirements for
indicating when the system is in a
failure condition. In these cases, the
agency believed, and therefore required,
that proper maintenance to ensure
system operation is vitally important to
driver and passenger safety. The agency
has no reason to believe any differently
for V2V devices, other than potentially
strengthening those beliefs based on the
cooperative nature of V2V and how the
benefits are a ‘‘networked good,’’ where
one device has the potential to
benefitting many others.
(b) Malfunction Indication
Requirements
• Any device participating in the V2V
system shall clearly indicate to their
users a malfunction condition occurring
in the device, its supporting equipment
or the inputs used to form, transmit, and
receive a basic safety message.
Malfunction indication shall be
provided in instances such as:
Æ Device components not operating
properly
Æ Input sensor data not within
appropriate tolerances
Æ On Board memory failures
Æ GPS receiver failures
Æ Unable to transmit or receive basic
safety messages
Æ Any other failure that could prevent
normal operation
• Malfunction indication shall be
clearly presented to device users in
the form of a lamp or message
• Owner’s information shall clearly
describe the malfunction indication,
PO 00000
Frm 00062
Fmt 4701
Sfmt 4702
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
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
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,
https://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, https://
articles.sae.org/14834/ (last accessed: Dec 7, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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 vehicleresident 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
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 riskbased framework reduces the
probability of an attack’s success and
mitigates the ramifications of a potential
unauthorized access.
NHTSA’s vehicle cybersecurity
approach is built upon the following
principles:
• Based on the risk-based prioritized
identification and protection of safetycritical 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.
162 See ‘‘NHTSA and Vehicle Cybersecurity’’,
https://www.nhtsa.gov/staticfiles/administration/
pdf/presentations_speeches/2015/NHTSAVehicleCybersecurity_07212015.pdf (last accessed
Dec 12, 2016).
PO 00000
Frm 00063
Fmt 4701
Sfmt 4702
3915
(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 bestpractices 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 cyberaware and cyber-resilient posture and
will take necessary actions to ensure
that there are no unreasonable safetyrisks.
(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:
E:\FR\FM\12JAP2.SGM
12JAP2
3916
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
(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 performancebased 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
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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 performancebased 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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 Endof-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.
• 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,
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.
PO 00000
Frm 00064
Fmt 4701
Sfmt 4702
the following information shall be
stored in FIPS–140 Level 3 storage:
D All individual pseudonym certificates
D RA, Intermediate CA, and PCA
certificates
D the RA address
D system configuration files
D security policies
D Root CA certificate
D Device Enrollment certificate
D All system private keys
D The System CRL
D 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
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
PO 00000
Frm 00065
Fmt 4701
Sfmt 4702
3917
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 safetyconscious 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?
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
164 See ‘‘GPS Under Attack as Crooks, Rogue
Workers Wage Electronic War’’ at https://
www.nbcnews.com/news/us-news/gps-underattack-crooks-rogue-workers-wage-electronic-warn618761 (last accessed Dec 7, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
3918
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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?
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 FiatChrysler 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.
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, WiFi). 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
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 https://illmatics.com/
Remote%20Car%20Hacking.pdf (last accessed Dec.
7, 2016).
167 NHTSA Recall Campaign Number:
15V461000.
PO 00000
Frm 00066
Fmt 4701
Sfmt 4702
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.
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
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
169 ‘‘Over-the-air Software Updates to Create Boon
for Automotive Market, IHS Says’’ at https://
press.ihs.com/press-release/automotive/over-airsoftware-updates-create-boon-automotive-marketihs-says (last accessed: Dec. 7, 2016).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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,
PO 00000
Frm 00067
Fmt 4701
Sfmt 4702
3919
and data tables. Each funded test
laboratory is required to utilize the
OVSC test procedure to establish even
more detailed test procedures with stepby-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
E:\FR\FM\12JAP2.SGM
12JAP2
3920
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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 3axis accelerations, vehicle yaw rate,
vehicle systems status information, and
radio performance data.
IV. Public Acceptance, Privacy and
Security
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 V2Vequipped 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
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.
PO 00000
Frm 00068
Fmt 4701
Sfmt 4702
to the fact that the safety applications
under evaluation were still prototypes.
Part of the goal of the SPMD was to
provide vehicle manufacturers with the
opportunity to gain real-world
experience with V2V safety
applications; providing the opportunity
to improve their ‘‘tuning’’ to maximize
safety while minimizing false positives.
Driver complaints, particularly
regarding IMA warnings triggered by
cloverleaf highway on-ramps and
elevated roads that crossed over other
roadways, led manufacturers to adjust
the safety applications to accommodate
the these originally-unexpected
‘‘warning’’ conditions. The SPMD
experience proved that these
adjustments significantly reduced false
positive warnings for this application.
At this time, NHTSA cannot account
preemptively for the possibility of
future false positive warnings. Given
that we are only proposing today to
mandate V2V transmission capability
and are not yet requiring specific safety
applications, we are not developing
requirements for how safety
applications must perform, and we
recognize that doing so would be a
significant undertaking. We do expect,
however, that manufacturers will
voluntarily develop and install safety
applications once V2V communications
capability is required available. As with
existing advanced crash avoidance
systems and as in the SPMD, we expect
manufacturers to address false positive
issues that arise in use in order to
improve customer satisfaction. Because
false positive issues with V2V-based
safety applications are typically a
software issue rather than a hardware
issue Manufacturers may even be able to
solve by deploying solutions to such
problems through over-the-air software
updates, rather than requiring vehicles
to be brought in for adjustment. Data
from the SPMD suggests that it is
possible to reduce false positives in
production safety applications and thus
we believe it should not pose a
significant public acceptance issue for
V2V. Additionally, if NHTSA
determines in the future that false
positives in the field create an
unreasonable risk to safety, NHTSA
could pursue remedies for them through
its enforcement authority.
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
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
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 multilayered 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
171 Section 522 of the Consolidated
Appropriations Act, 2005, Public Law 108–447.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
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
172 ‘‘PRIVACY
PRINCIPLES FOR VEHICLE
TECHNOLOGIES AND SERVICES’’ available at
https://www.autoalliance.org/?objectid=865F3AC068FD-11E4-866D000C296BA163 (last accessed dec
7, 2016).
PO 00000
Frm 00069
Fmt 4701
Sfmt 4702
3921
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 alreadyinstalled 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 automotivegrade 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 safetycritical 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
173 Additional information about NHTSA’s
approach to automotive cybersecurity is available at
https://www.nhtsa.gov/About+NHTSA/
Speeches,+Press+Events+&+Testimonies/
NHTSA+and+Vehicle+Cybersecurity (last accessed
Sept. 23, 2015).
E:\FR\FM\12JAP2.SGM
12JAP2
3922
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
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:
• All legal inputs shall be specified
precisely using a grammar. Inputs shall
only represent data, not computation,
and all data types shall be unambiguous
(i.e., not machine-dependent).
Maximum sizes shall be specified to
help reduce denial-of-service and
overflow attacks.
• Every input shall be checked to
confirm that it conforms to the input
specification. Interface messages shall
be traceable to mission-critical
functionality. Non-required messages
should be rejected.
• Parsers and serializers shall be
generated, not hand-written, to ensure
they do not themselves introduce any
security vulnerabilities. Evidence
should be provided that
Æ parse(serialize(m)) = m, for all
messages m, and
Æ parse(i) = REJECT, for all non-valid
inputs i.
174 See, e.g., King, Rachel, ‘‘GM Grapples with Big
Data, Cybersecurity in Vehicle Broadband
Connections,’’ Wall Street Journal, Feb. 10, 2015.
Available at https://blogs.wsj.com/cio/2015/02/10/
gm-grapples-with-big-data-cybersecurity-in-vehiclebroadband-connections/ (last accessed Dec 7, 2016).
175 See Launchbury, John, Dylan McNamee, and
Lee Pike, Galois Inc., ‘‘A Technique for Secure
Vehicle-to-Vehicle Communication,’’ Mar. 9, 2014.
Available at https://galois.com/wp-content/uploads/
2014/07/whitepaper_SecureInterfaces.pdf (last
accessed Dec 7, 2016).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
• 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
PO 00000
Frm 00070
Fmt 4701
Sfmt 4702
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
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
176 ‘‘Vehicle to Vehicle Crash Avoidance Safety
Technology: Public Acceptance Final Report’’
December, 2015. Available at Docket No. NHTSA–
2016–0126
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
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.
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
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).
178 See 49 U.S.C. 30122(b).
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
PO 00000
Frm 00071
Fmt 4701
Sfmt 4702
3923
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
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
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).
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).
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3924
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
reduce these risks while setting
requirements that would provide lifesaving 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 consumerfriendly 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
PO 00000
Frm 00072
Fmt 4701
Sfmt 4702
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.
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 riskmitigating 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
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.
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 intragovernmental 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 nongovernmental third parties prior to
publication. However, NHTSA looks
forward to receiving comments on the
privacy issues discussed in the NPRM
and PIA from a broad range of
stakeholders and other interested
entities.
With regard to the scope of NHTSA’s
PIA, the agency wishes to emphasize
that, to the extent possible in the
185 Section 522 of the Consolidated
Appropriations Act, 2005, Public Law 108–447.
PO 00000
Frm 00073
Fmt 4701
Sfmt 4702
3925
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 nongovernment entities, other nongovernmental 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
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3926
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00074
Fmt 4701
Sfmt 4702
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 publiclyaccessible 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
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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 crashavoidance safety applications.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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 safetyrelated 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 locationbased 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 https://
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
PO 00000
Frm 00075
Fmt 4701
Sfmt 4702
3927
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
E:\FR\FM\12JAP2.SGM
12JAP2
3928
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
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.
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 nonV2V methods of tracking a motor
vehicle that currently exist.
4. V2V Data Flows/Transactions With
Privacy Relevance
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
PO 00000
Frm 00076
Fmt 4701
Sfmt 4702
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 decisionmakers.
(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.
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
(which appears to be faulty) and other
information, such as:
• Reporter’s pseudonym certificate
• Reporter’s signature
• Time at which misbehavior was
identified
• 3D GPS coordinates at which
misbehavior was identified
• List of vehicles (device/pseudonym
certificate IDs) within range at the
time
• Average speed of vehicles within
range at the time
• Suspicion type (warning reports,
proximity plausibility, motion
validation, content and message
verification, denial of service)
• Supporting evidence
Æ Triggering BSM(s)
Æ Host vehicle BSM(s)
Æ Neighboring vehicle BSM(s)
Æ Warnings
Æ Neighboring devices
Æ Suspected attacker
(d) Distribution of Certificate Revocation
List
As explained above, by evaluating
misbehavior reports, the security entity
envisioned may identify misbehaving
V2V devices in vehicles and place
information about those devices on the
CRL. The security entity then would
make updated CRLs available to V2V
system participants and other system
parts on a periodic basis to alert OBEs
to ignore BSMs coming from the
defective V2V equipment. There is only
one type of CRL. Current system design
plans do not include placing individual
security certificates on the CRL. Rather,
each CRL would contain information
(specifically, linkseed1, linkseed2, time
period index, and LA Identifiers 1 and
2) that OBEs could use to calculate the
values of the certificates in messages
that should be ignored.
5. Privacy-Mitigating Controls
From the inception of the research
program that would result in V2V
technology over a decade ago, NHTSA
has worked with its research partners,
CAMP and the VIIC, to purse an
integrated, privacy positive approach to
the V2V system. For this reason, the
V2V system described in our proposal
would contain multiple layers of
technical, policy and physical controls
to help mitigate potential privacy
impacts system-wide. Below, we discuss
the privacy impact-mitigating controls
that would apply to each of the three
privacy-relevant data flows discussed
above. In the course of this discussion,
we detail some of the key privacy
controls that we expect to see in a
National SCMS (based on the current
SCMS technical design, see Section
V.B.2).
PO 00000
Frm 00077
Fmt 4701
Sfmt 4702
3929
(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
E:\FR\FM\12JAP2.SGM
12JAP2
3930
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
PO 00000
Frm 00078
Fmt 4701
Sfmt 4702
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.
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
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?
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?
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?
4. Do BSMs in misbehavior reporting provide sufficient information about the past location of
the reporting or other vehicles to retrospectively track the vehicle’s path?
5. Does information regarding blacklisted vehicles’ security certificates enable all vehicle security certificates to be associated with one another and thus, with the same specific vehicle?
BSM Broadcast Transaction ...............................
BSM Broadcast Transaction ...............................
Broadcast and Receipt of a Misbehavior Message.
Certificate Revocation List (CRL) Distribution
Transaction.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
186 ‘‘Electromagnetic Hypersensitivity Comment
Review and Analysis’’, NHTSA V2V Support—Task
3, dated March 13, 2015, Noblis.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
1. Overview
According to the World Health
Organization (WHO), EHS is
characterized by a variety of nonspecific 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
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
187 ‘‘Electromagnetic
fields and public health:
Backgrounder’’, The World Health Organization
(WHO), December 2005. Available at https://
www.who.int/peh-emf/publications/facts/fs296/en/
(last accessed Sept. 28, 2015).
PO 00000
Frm 00079
Fmt 4701
Sfmt 4702
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
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
188 ‘‘Wireless Devices and Health Concerns’’,
Federal Communications Commission (FCC),
Consumer and Governmental Affairs Bureau,
updated March 12, 2014. Available at https://
www.fcc.gov/guides/wireless-devices-and-healthconcerns (last accessed Dec 12, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
3932
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
Western exposure limits are designed on
the basis of identified thresholds for
hazards of RF and thus are sciencebased. 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 asyet unidentified hazard of RF exposure
at low levels.189
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
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 realtime, 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)
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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 https://ewh.ieee.org/
soc/embs/comar/standardsTIS.pdf (last accessed
Dec. 12, 2016).
190 Department of Energy ‘‘Smart Grid’’ Web site.
Available at https://energy.gov/oe/services/
technology-development/smart-grid (last accessed
Dec 12, 2016).
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. https://
energy.gov/oe/downloads/demand-response-andsmart-metering-policy-actions-energy-policy-act2005-summary-state (last accessed: Dec 12, 2016)
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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
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
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
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-advmetering.asp (last accessed Dec. 12, 2016).
193 Federal Communications Commission, (FCC),
2011. Radio frequency safety, available at https://
www.fcc.gov/encyclopedia/radio-frequency-safety
(last accessed Dec 12, 2016).
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%20
Co%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).
PO 00000
Frm 00080
Fmt 4701
Sfmt 4702
an array of meters, were at levels similar
to those from other devices that produce
RF in the home and surrounding
environment.196
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.
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 communitybased organizations in effort to convey
196 ‘‘RF Exposure Levels from Smart Meters: A
Case Study of One Model’’, Electric Power Research
Institute (EPRI), February 2011. Available at https://
www.epri.com/abstracts/Pages/Product
Abstract.aspx?ProductId=000000000001022270
(last accessed Dec 12, 2016).
197 Radio Frequency FAQ, https://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/mailarchive/web/its/current/pdfqf992dHy9x.pdf (last
accessed Dec. 12, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
these messages to the end-user
community.200
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
• 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 handheld 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
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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. https://energy.gov/sites/prod/
files/2013/06/f1/EAC_SGConsumerRecs.pdf (last
accessed Dec 12, 2016).
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).
202 ‘‘Evaluating Compliance with FCC Guidelines
for Human Exposure to Radio frequency
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
• National Telecommunications and
Information Administration: NTIA is an
agency of the U.S. Department of
Commerce and is responsible for
authorizing Federal Government use of
the RF electromagnetic spectrum. Like
the FCC, NTIA also has NEPA
responsibilities and has enacted similar
guidelines and processes to those of
FCC to ensure compliance.
• Food and Drug Administration
(FDA): by authority of the Radiation
Control for Health and Safety Act of
1968, the FDA’s Center for Devices and
Radiological Health (CDRH) develops
performance standards for the emission
of radiation from electronic products
including: X-ray equipment, other
medical devices, television sets and
microwave ovens, laser products, and
sunlamps. The CDRH has not adopted
performance standards for other RFemitting products. The FDA is the
leading federal health agency in
monitoring the latest research
developments and advising other
agencies with respect to the safety of
RF-emitting products used by the
public, such as cellular and mobile
devices.
• Environmental Protection Agency
(EPA): EPA activities pertaining to RF
safety and health are presently limited
to advisory functions. EPA has chaired
an Interagency Radiofrequency Working
Group, which coordinates RF healthrelated activities among federal agencies
who have regulatory responsibilities in
this area.
• Occupational Safety and Health
Administration (OSHA): OSHA is
responsible for protecting workers from
exposure to hazardous chemical and
physical agents. In 1971, OSHA issued
a protection guide, which V2V devices
are anticipated to operate within, for
exposure of workers to radiation (29
CFR 1910.97). The guide covers
frequencies from 10 MHz to 100GHz.
The guide was later ruled to be only
advisory and not mandatory.203
• National Institute for Occupational
Safety and Health (NIOSH): NIOSH is
part of the U.S. Department of Health
and Human Services, Centers for
Disease Control and Prevention (CDC)
and conducts research and
investigations into issues related to
occupational exposure to chemical and
Electromagnetic Fields’’, Federal Communications
Commission, Office of Engineering & Technology,
OET Bulletin 65 (Edition 97–01), August 1997.
Available at https://transition.fcc.gov/Bureaus/
Engineering_Technology/Documents/bulletins/
oet65/oet65b.pdf (last accessed Dec 12, 2016).
203 OET Bulletin #56, Federal Communications
Commission, FCC, available at https://
transition.fcc.gov/Bureaus/
Engineering_Technology/Documents/bulletins/
oet56/oet56e3.pdf (last accessed Dec 12, 2016).
PO 00000
Frm 00081
Fmt 4701
Sfmt 4702
3933
physical agents. NIOSH research is
focused on radio frequencies, extremely
low frequencies (ELF) and static
magnetic fields. CDC/NIOSH provides
various guidance documents related to
the focused research areas.204
• The Architectural and
Transportation Barriers Compliance
Board (Access Board): The Access Board
is the federal agency devoted to the
accessibility for people with disabilities.
In November 1999, the Access Board
issued a proposed rule to revise and
update their accessibility guidelines.
During the public comment period on
the proposed rule, the Access Board
received approximately 600 comments
from individuals with multiple
chemical and electromagnetic
sensitivities. The Board issued a
statement recognizing that people with
these sensitivities may be considered
disabled under the ADA if conditions
perceived to be caused by these
sensitivities ‘‘so severely impair the
neurological, respiratory, or other
functions of an individual that it
substantially limits one or more of the
individual’s major life activities.’’ The
Board contracted with the National
Institute of Building Sciences (NIBS) to
establish the Indoor Environmental
Quality (IEQ) Project. The overall
objectives of the IEQ project were to
establish a collaborative process among
a range of stakeholders to recommend
practical, implementable actions to both
improve access to buildings for people
with EMS while also improving indoor
environmental quality to create
healthier buildings for the entire
population. The NIBS IEQ Final Report
was issued in July 2005 and provides
recommendations for accommodations
for people with chemical and/or
electromagnetic sensitivities. The
agency is unaware of any further actions
by the Access Board on this issue.205
• Department of Defense (DOD): The
DOD conducts research on the
biological effects of RF energy.
6. EHS in the U.S. and Abroad
(a) Americans With Disabilities Act
The Americans with Disabilities Act
(‘‘ADA’’) does not contain a lengthy list
of medical conditions that constitute
disabilities. Instead, the ADA provides a
general definition for ‘‘disability,’’
which requires a showing of a having a
physical or mental impairment that
substantially limits one or more major
204 ‘‘EMF (ELECTRIC AND MAGNETIC FIELDS),’’
available at https://www.cdc.gov/niosh/topics/emf/
(last accessed Dec 12, 2016).
205 ‘‘IEQ Indoor Quality Final Report, National
Institute for Building Services, July 14, 2005. https://
apps.fcc.gov/ecfs/document/view?id=7520945309
(last accessed: Dec 12, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
3934
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
life activities, a history or record of such
an impairment, or being perceived by
others as having such an impairment.
Several states have enacted even more
liberal policies on disability rights that
afford greater potential protections than
the ADA as it relates to EHS.
To date, the agency is unaware of any
finding that EHS constitutes a disability.
As mentioned above, the NIBS IEQ
provided some recommendations, but
did not conclude the EHS was in fact a
disability. The agency is unaware of any
further actions, either by the Access
Board or some other entity, which
recognized EHS as a disability or any
science that would prove this.
(b) Global Recognition
Globally, some nations have
heightened awareness of EHS by
requiring provisions to accommodate
those claiming its effects. In Sweden, for
example, these provisions could include
unique lighting fixtures and/or
computer monitors for places of
employment. The Canadian
Government, The Canadian Human
Rights Commission (CHRC) has also
recognized EMS, describing
environmental sensitivities as follows:
‘‘The term ‘‘environmental sensitivities’’
describes a variety of reactions to
chemicals, electromagnetic radiation,
and other environmental factors at
exposure levels commonly tolerated by
many people.’’ 206 The CHRC published
a series of recommendations for
building environments in effort to
reduce potential EMS conditions.207 In
2009, the European Parliament urged
member states to follow Sweden’s
example to provide people with ES
protection and equal opportunities.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
7. Conclusion
The agency appreciates the ANPRM
comments bringing attention to V2V
technology and a potential relationship
to EHS. The agency takes these concerns
very seriously. The literature review
conducted by the agency highlighted
long, and still ongoing, activities to
better understand the relationship to
electromagnetic radiation and the
symptoms of individuals reporting
electromagnetic hypersensitivity. As a
Federal government agency focused on
automotive safety, NHTSA
acknowledges the expertise of our sister
206 ‘‘What You Should Know About
Electromagnetic Sensitivity (EMS)’’, Christiane
Tourtet. B.A, International MCS/EMS Awareness,
available at https://www.nettally.com/prusty/
CTEMS.pdf (last accessed Dec. 8, 2016).
207 Sears, Margaret E., ‘‘The Medical Perspective
on Environmental Sensitivities,’’ May 2007.
Available at https://www.chrc-ccdp.ca/sites/default/
files/envsensitivity_en_1.pdf. (last accessed Dec. 8,
2016).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
agencies such as the Federal
Communications Commission and the
Food and Drug Administration, among
others, which have been involved with
electromagnetic fields, in parallel with
the pervasiveness of cellular phone
deployment in the United States and
globally.
The FDA currently states in response
to the question, ‘‘Is there a connection
between certain health problems and
exposure to radiofrequency fields via
cell phone use?’’ that ‘‘The results of
most studies conducted to date indicate
that there is not. In addition, attempts
to replicate and confirm the few studies
that did show a connection have
failed.’’ 208 However, NHTSA
acknowledges that research is still
ongoing and, as technology evolves;
wireless communications will most
likely continue to increase. The agency
believes the continued efforts of the
Radiofrequency Interagency Work
Group (RFIAWG) 209 may yield any
potential future guidance for wireless
device deployment and usage.
V2V devices are currently certified for
use in the 5.9 GHz frequency allocation
by the FCC, and the agency additionally
anticipates any future certifications by
the FCC will ensure that V2V devices
will comply with all criteria related to
RF emissions.
Currently, the FCC publishes a very
helpful guide on ‘‘Wireless Devices and
Health Concerns,’’ 210 in which the
Commission states, ‘‘While there is no
federally developed national standard
for safe levels of exposure to
radiofrequency (RF) energy, many
federal agencies have addressed this
important issue.’’ The Commission
acknowledges the efforts the interagency
working group, its members, and their
ongoing monitoring and investigating
issues related to RF exposure.
V2V devices would operate at
distances to humans significantly
further that the distance relationship of
a portable cellular phone to its operator,
where the device is generally carried on
a person or pressed directly to the ear.
V2V devices used in the Safety Pilot
operated at similar power levels to
handheld cellular phones and the
agency expects power levels for
208 Radiation-Emitting Products, ‘‘Current
Research Results,’’ available at https://www.fda.gov/
Radiation-EmittingProducts/
RadiationEmittingProductsandProcedures/
HomeBusinessandEntertainment/CellPhones/
ucm116335.htm (last accessed Dec. 8, 2016).
209 Group members can be found at https://
www.emrpolicy.org/litigation/case_law/docs/
workgroupmemberslist.pdf (last accessed: Dec 8,
2016).
210 See ‘‘Wireless Devices and Health Concerns’’
https://www.fcc.gov/guides/wireless-devices-andhealth-concerns (last accessed Dec. 8, 2016).
PO 00000
Frm 00082
Fmt 4701
Sfmt 4702
production deployment to remain
consistent with the levels used in the
Safety Pilot activities. Based on these
two conditions, we believe it is
reasonable to anticipate that any new
guidance issued by the RFIAWG and its
participating federal agencies on future
cellular phone or wireless device usage
could potentially be relevant to V2V
devices, albeit in a somewhat
diminished magnitude based on the
distances the devices will operate in
relation to persons.
V. Device Authorization
A. Approaches to Security Credentialing
As part of exploring different methods
of authenticating V2V messages, the
agency has examined in addition to the
primary message authentication
proposal’s PKI base SCMS (single-root
approach), two potential approaches to
ensuring V2V messages are secure.
These include a vehicle based approach,
and an approach where multiple roots
of confidence would be utilized. Each
approach is described in the following
sections.
B. Federated Security Credential
Management (SCMS)
1. Overview 211
For V2V communications to work
effectively and as intended to facilitate
crash avoidance safety applications, it is
critical that users of the network have
confidence in the validity of basic safety
messages received from other system
users—indistinct users whom they have
never met and do not know personally.
For this reason, DOT and its research
partners have developed a sophisticated
security system that allows for the
creation and management of digital
security credentials (referred to as
‘‘certificates’’) that enable users to have
confidence in one another, and the
system as a whole. In fact, the security
system designed to create confidence in
the V2V environment is a more complex
and sophisticated version of the same
public key infrastructure (PKI) system
that consumers and merchants use every
day to verify credit card transactions at
the supermarket or make on-line
purchases (any time you see the ‘‘https,’’
for example). PKI systems also have
long been used by the Federal
government and corporate America,
211 The SCMS overview and governance
discussions in this notice are based in significant
part on a report DOT entitled, ‘‘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.
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
successfully and securely, to verify the
identity of their employees for access
and security purposes.
In the V2V context, system
participants use digital certificates to
validate the integrity of safety messages
exchanged 10 times per second by V2V
devices in motor vehicles. The body of
each safety message is unencrypted; the
sender signs the message with a digital
certificate and the receiver checks to
ensure that the signature is valid before
relying on the message content. This
PKI verification process requires an
organization referred to as a Security
Credential Management System (SCMS)
to provide those necessary signing
credentials (i.e., digital certificates) and
conduct related security functions, such
as identifying and removing
malfunctioning V2V devices from the
system. The V2V Readiness Report
details the SCMS component of the V2V
system.212
When NHTSA issued its V2V
Readiness Report, for a variety of
reasons discussed therein, the agency
envisioned that the SCMS would be
established, funded, and governed
primarily by one or more private
entities—possibly a consortium of
automobile and V2V device
manufacturers—with limited Federal
involvement. Through comments to the
ANPRM, the SCMS RFI process,
collaborative research with the VIIC,
and additional DOT policy research,
NHTSA now has developed several
different potential processes by which a
V2V SCMS might be stood up, owned,
operated, and governed. DOT is
committed to playing a central predeployment role in developing the
organizational framework of a viable
and sustainable V2V SCMS, as well as
the policies and procedures required to
support the SCMS—depending on
comments received in response to this
NPRM. In order to do so, DOT has
expanded the scope of its predeployment policy research
significantly to include several
additional critical activities. DOT
intends to work closely with
experienced PKI and organizational
management consultants and
stakeholders to:
• Deploy a Proof-of-Concept SCMS
based on the current design to support
additional privacy and security
research, as well as the certificate needs
of CV Pilots funded by DOT and early
industry adopters of V2V;
• Develop policies and procedures
(based on industry best practices,
standards, comparable privacy-sensitive
PKIs, and individual input from SCMS
212 See
Section IX.B of the V2V Readiness Report.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
and V2V stakeholders) that could be
used to govern the organization,
accreditation, and operation of a V2V
SCMS and its components, including
drafts of an SCMS Certificate Policy
(CP), Certification Practice Statement
(CPS), and Privacy Policy;
• Develop a model for, and then
prototype a private, multi-stakeholder
governance entity (on the basis of
existing multi-stakeholder models) that
could support deployment of an
operational SCMS.
• Develop one or more public-private
governance models (on the basis of
existing comparable organizations) that
could support deployment of an
operational SCMS, given appropriate
funding.
We are hopeful that this critical
technical and policy research will
provide government and private
stakeholders with a detailed blueprint of
several viable options for standing up an
SCMS. One promising path that DOT
actively will continue to explore is that
of working with a private sector, multistakeholder entity that could serve as an
SCMS Manager to deploy, govern, and
coordinate operation of a fullyoperational V2V SCMS, in which DOT
would play an ongoing advisory role.
However, DOT’s planned research also
encompasses robust exploration of other
paths that could support the
deployment of a sustainable, operational
V2V SCMS, given appropriate public
and/or private funding.
We begin this discussion with a
description of the technical and
organizational design of the SCMS that
will support V2V, V2I, and V2X
communications. We then summarize
and address comments on the technical
design received by NHTSA in
connection with the ANPRM, V2V
Readiness Report, and RFI process. As
the foundation to a discussion of SCMS
governance, we identify the diverse
group of public and private entities and
stakeholders with interests in
deployment of a V2V SCMS (together
described in this document as members
of a ‘‘SCMS ecosystem’’ or ‘‘SCMS
industry’’ requiring governance for
successful deployment of V2V
communications). We summarize and
address governance comments received
in response to the ANPRM, V2V
Readiness Report, and during the RFI
process. We detail DOT’s planned
deployment of the proof-of-concept
(POC) SCMS. We then detail planned
work with experts and SCMS
‘‘industry’’ participants to develop
policies and procedures for the National
SCMS, and to flesh out one or more a
viable model for organization,
ownership, and governance of the
PO 00000
Frm 00083
Fmt 4701
Sfmt 4702
3935
National SCMS. Following is a
discussion of ICANN as a comparative
industry example of successful, private
sector multi-stakeholder governance, the
evolution of which is instructive to
government and private sector
stakeholders in the SCMS ecosystem.
Finally, we outline NHTSA’s plan to
issue, on the basis of this additional PKI
and organizational research, a policy
statement on SCMS governance on
which we will seek comment from
stakeholders representing all aspects of
the SCMS ecosystem.
2. Technical Design
The technical design for a SCMS
reflects the processes associated with
certificate production, distribution, and
revocation, and illustrates how these
SCMS functions interact with each other
and with OBE. Several functions work
together in a PKI system. The V2V
SCMS is based on a standard PKI design
to which additional functions have been
added specifically to address the
identified security and privacy needs of
V2V, V2I, and V2X technologies. The
term ‘‘pseudonym functions’’ is used to
refer to those functions responsible for
creating the short-term certificates used
by the OBE in V2V messaging. The term
‘‘pseudonym’’ is used to indicate that
short-term certificates contain no
unique or personally-identifying
information about users or their
vehicles, but still allow users to
participate in the system, in essence
allowing use of a pseudonym. The
pseudonym functions differ from those
functions that take part in the
‘‘bootstrap’’ process, described later in
this section. Pseudonym functions
create, manage, distribute, monitor, and
revoke short-term certificates for
vehicles.
These functions are listed below in
alphabetical order:
• Intermediate Certificate Authority
(Intermediate CA)
• Linkage Authority (LA)
• Location Obscurer Proxy (LOP)
• Misbehavior Authority (MA)
• Pseudonym Certificate Authority
(PCA)
• Registration Authority (RA)
• Request Coordination
• Root Certificate Authority (Root CA)
• SCMS Manager
Distinct from the pseudonym
functions that execute the short-term
certificate processes are the functions
that carry out the ‘‘bootstrap’’ process
(the initialization of the device into the
system). The bootstrap process
establishes the initial connection
between OBE and the SCMS. This
process is characterized by its chief
E:\FR\FM\12JAP2.SGM
12JAP2
3936
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
component, the Enrollment Certificate
Authority (ECA), which is responsible
for assigning an enrollment certificate to
each OBE. The bootstrap functions
remain separate from the pseudonym
functions because of the potential
connection to individual identifying
information (like a VIN) during
bootstrap.
The functions within the bootstrap
process are listed below in alphabetical
order:
• Certification Lab
• Device Configuration Manager (DCM)
• Enrollment Certificate Authority
(ECA)
A brief description of each SCMS
function is provided in Table V–1.
TABLE V–1—SCMS COMPONENTS AND DESCRIPTION
Abbreviation
Function name
Activities
Certification Lab ...................
Certification Lab .............................
DCM .....................................
Device Configuration Manager ......
ECA ......................................
Intermediate CA ...................
Enrollment Certificate Authority .....
Intermediate Certificate Authority ..
LA .........................................
Linkage Authority ...........................
LOP ......................................
Location Obscurer Proxy ...............
MA ........................................
Misbehavior Authority ....................
PCA ......................................
RA ........................................
Pseudonym Certificate Authority ...
Registration Authority ....................
Request Coordination ..........
Root CA ...............................
Request Coordination ....................
Root Certificate Authority ..............
SCMS Manager ...................
Security Credentials Management
System Manager.
Tests OBE and informs ECA that units of a particular type are eligible for
enrollment certificates.
Coordinates initial distribution with OBE and enables OBE to request certificates from RA.
Activates OBE and credentials users.
Shields Root CA from system and provides more flexibility for trust management.
Each pair of LAs communicates with the RA to provide linkage values necessary for certificate production, and assists the MA in misbehavior processes.
Obscures the locations of requesting devices (e.g., OBE requesting certificates) from other functions, such as the RA.
Collects misbehavior reports from OBE and analyzes system-wide misbehavior. Coordinates with PCA and RA to produce CRL. Other activities
include CRL generation, broadcast, and store; internal blacklist manager
(IBLM); and global detection.
Generates and signs short-lived certificates.
Coordinates certificate production with other functions; sends certificates to
OBE (during full deployment).
Coordinates certificate requests from OBE to RA.
Provides system-wide confidence through CME certificates issued to all
CMEs; represents the basis of confidence in the system.
Defines and oversees standards and practices for the SCMS, related to both
technical and policy issues.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
The technical design of the SCMS is
focused on communications and
activities of the various PKI functions.
Among other fundamental principles,
the technical design for the system
incorporates a ‘‘privacy by design’’
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
approach that separates information and
organizational functions in order to
mitigate potential risks to consumer
privacy. The model depicted in Figure
V–1 below illustrates one way these
functions could be grouped into legal/
PO 00000
Frm 00084
Fmt 4701
Sfmt 4702
administrative organizations within the
larger SCMS ‘‘industry,’’ while still
protecting consumer privacy
appropriately and ensuring secure,
efficient communications.
E:\FR\FM\12JAP2.SGM
12JAP2
Blue boxes in the diagram represent
Certificate Management Entities (CMEs),
or groupings of SCMS functions.
Functions carried out within the CMEs
are represented by the white boxes. For
purposes of this illustrative model,
these groupings clarify those functions
that may be owned by multiple
organizations, versus those that may be
best handled in a more centralized
manner. However, as noted in the V2V
Readiness Report, ultimately, the
decision as to which SCMS functions
may be perform by a single entity and
whether central and non-central
functions may be combined are matters
of governance defined by the system’s
Certificate Policy. For this reason, if this
PKI technical design for the SCMS is
implemented, the final decision on
which organizations can be owners/
operators and how scope and
responsibility will be divided among the
CMEs will likely be a central policy
issue determined jointly by NHTSA and
the entity that takes the lead in
governing and coordinating operation of
the V2V SCMS.
3. Independent Evaluation of SCMS
Technical Design
The design of the Security Credential
Management System has gone through
many iterations and adjustments
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
throughout V2V research program as the
system has evolved to meet revised or
additional needs. Additionally,
evolutionary changes have occurred as a
result of implementation and operation
in support of the USDOT’s Safety Pilot
Model Deployment.
To better understand maturity and
robustness of the SCMS, the USDOT
retained the MITRE Corporation to
conduct an independent evaluation and
risk assessment of both security and
privacy design features of the SCMS.
This work was used to inform
continuing refinements and provide
USDOT with a basis for future policy
and technical decisions related to
deployment.
MITRE was directed to conduct: (1)
An independent and comprehensive
evaluation and risk assessment of the
July 2013 SCMS design for a V2V
connected vehicle environment; and (2)
a technical analysis of the potential
privacy risks of the entire V2V system
that includes security but also focuses
on the operation of V2V
communications in support of crash
avoidance safety applications.
The independent evaluation by
MITRE identified security requirements
needed to support secure V2V
communications, and revisited threats
and risks in relation to the design and
PO 00000
Frm 00085
Fmt 4701
Sfmt 4702
3937
how the identified requirements
addressed the potential risks. The
results of the SCMS design evaluation
are detailed in Final Requirements
Report, September 11, 2015, Report
Number: FHWA–JPO–15–235, and Final
Design Analysis Report, September 18,
2015, Report No: FHWA–JPO–15–237.
The MITRE evaluation was based on
the previous 6 years of research that
investigated core issues related to:
Securing DSRC communications;
privacy implications; achieving
interoperability; governance and
organizational structure; and identifying
and addressing communication threats
and risks. The Government provided
reports associated with these studies to
the MITRE Corporation as a basis to
conduct their evaluation and identify
the minimum requirements of the SCMS
that would support the three primary
components of the system that are:
1. V2V devices that support DSRC
messages broadcast to and received from
other devices; and the ability to send/
receive messages to/from the Security
Certificate Management System for
digital security credentials that provide
the means of message authentication;
2. A Security Certificate Management
System (SCMS) which is the security
organization that issues, distributes, and
revokes digital security credentials. The
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.010
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3938
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
SCMS is comprised of a number of
entities and functions. It is also
designed to detect and remove
misbehaving devices; and
3. A communications network that
facilitates two-way encrypted
communications between an SCMS and
a DSRC device (to include both vehicles
and roadside units).
The MITRE evaluation focused on a
revised SCMS technical design that
benefited and evolved from knowledge
gained during operation of a technical
prototype implemented as part of the
Safety Pilot Model Deployment. This
prototype implementation exercised
initial technical functionality needed to
produce and manage security certificate
material for the deployed devices, and,
there was a rudimentary technical
organization and management structure.
This early SCMS prototype provided
technical data related to PKI
architecture and functions, and there
were new insights gained regarding the
over-the-air transmission of security
materials and use of alternate
communication media that include
DSRC and cellular.
Prior to the MITRE evaluation were
years of research conducted to
understand and develop the SCMS
design. The first forma research was
conducted in 2010. CAMP
commissioned 5 leading
communication/internet security
entities to assess the security needs and
identify a security approach for DSRC
communications. Security Innovations,
Escrypt, Telcordia Technologies
Carnegie Mellon University, University
of Illinois at Urbana-Champaign, and
General Motors India Science Lab
investigated aspects of the system and
collaborated on recommendations.
Security Innovations and Escrypt
conducted a risk analysis and identified
initial risks related to broadcast
communications among vehicles and
devices. These risks included denial of
service attacks, Sybil attacks, altered
messages, replay of messages, and
compromised nodes. The risks were
rated and mitigation techniques
identified. The risk analysis was
combined with investigations by:
Telcordia Technologies (design and
analysis of applicable and scalable PKI
systems); Carnegie Mellon and
University of Illinois at UrbanaChampaign (adaptations to address
privacy); and General Motors India Lab
(misbehavior detection solutions). The
overall recommendation was a PKI
based system with frequently changing
certificates.
Two years later after preliminary
work was done on the SCMS design,
USDOT and CAMP conducted a risk
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
assessment based on the NIST 800–30
publication, Guide for Conducting Risk
Assessments. Using the NIST
framework, attackers and attack
scenarios were identified. Identified
attackers included, for example, a clever
outsider and a well-funded foreign
hostile organization. Attack scenarios
included local and widespread Sybil
attacks, Root Compromise, Intermediate
Certificate Authority Compromise,
Registration Authority Compromise,
False Misbehavior Report, False
Certificate Requests, and Trust
Management Compromise. For various
attack scenarios risk was estimated
based on likelihood and impact. The
estimates were based on a modified
NIST risk matrix given the NIST matrix
did not rate any scenario as ‘‘high’’. The
risk assessment identified Root
Compromise, Intermediate Certificate
Authority Compromise, Registration
Authority Compromise, and Trust
Management Compromise to have high
risk even after possible mitigation
techniques were considered. This work
informed the next stage of SCMS design
refinement which included (among
other refinements) an objective of
finding new innovative techniques to
move high risks to medium risks, and
medium risks to low risks.
An updated high level SCMS design
was completed July 2014 and
documented via 4 separate but
connected reports that included: (1)
Study 1, Security Credential
Management System, Final Report, July
2014; (2) Vehicle Safety
Communications Security Studies Final
Report, July 2014; (3) Study 3 Final
Report, Definition of Communication
Protocols Between SCMS Components,
July 2014; and, (4) Phase 2 Final Report
Volume 3: Security Research for
Misbehavior Detection, Nov 2014.
These reports formed the base of the
information available to MITRE
regarding the latest design of the SCMS.
Other reports provided to MITRE
included past research findings
concerning interoperability, initial
communications security needs, and
SCMS organizational analysis.
MITRE also had access the standards
referenced in the reports that included
SAEJ2735, IEEE 1609, and the latest
input to SAEJ2945 that was being
developed during the MITRE
evaluation.
MITRE used the information
described above to identify the
minimum or essential requirements
needed for a SCMS design to support
the three primary components identified
above (Final Requirements Report—
September 11, 2015, Report Number:
FHWA–JPO–15–235), and an
PO 00000
Frm 00086
Fmt 4701
Sfmt 4702
assessment of how the latest SCMS
design aligns with these minimum
requirements (Final Design Analysis
Report—September 18, 2015, Report No:
FHWA–JPO–15–237). The Requirements
Report also includes a risk assessment
where MITRE reviewed past risk
assessments and identified threats,
threat actors, attacks, vulnerability,
consequence, likelihood, impact
severity, and risk in relation to the
minimum requirements and latest
design information base on the NIST
800–30, Guide for Conducting Risk
Assessments.
The risk assessment assessed a
number of possible threats to the
system, some described by the CAMP
reports, others identified by the MITRE
team. Of the twenty-one threats
identified, MITRE concluded that
fourteen may be mitigated by a system
design that conforms to the minimum
requirements, but for seven of the
threats, no system design requirements
seemed to apply.213 In some cases,
threats may be mitigated by additional
system design features that perform to
the minimum requirements. For other
threats, no system requirements are
listed. These include threats that
involve compromises of or unauthorized
access to SCMS or OEM system
components or databases. For these,
mitigation will depend not on system
technical design but rather on
implementation of security policies and
operational practices that would be part
of the SCMS operational governance
function. Further, MITRE noted that
such Governance functions and policies
may be captured in documents such as
a Certificate Policy and the Certificate
Practice Statement. These documents
and other governance policies and
protocols will be developed as part of
the SCMS PoC operations project that
will support V2X deployment projects
as discussed in Section V.B.6.e).
The MITRE Final Design Analysis
report evaluates the SCMS design (as
documented in the above listed Reports
from CAMP) against a list of derived
minimum requirements from the Final
Requirements Report.
MITRE noted that the design of the
SCMS has several innovative elements
that deserve further development and
analysis in future design revisions and
system operational implementations.
The list below identifies areas
213 The threats list from the MITRE report is not
a comprehensive list of threats or risks to overall
V2V system success, but are focused on threats to
the objectives of providing secure V2V
communication, protecting the privacy of vehicle
operators, and enabling the identification and
removal of bad actors from system participation.
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
recommended by MITRE for further
development:
• Required cyber-resiliency
capabilities, such as designs for
continuous monitoring for proper
operation, anomaly detection functions,
and systematic software reset of
installed software components.
• Misbehavior Authority (MA)
design. The MA constitutes a critical
single point of failure as conceived.
Additionally, it presents enticing points
for adversary compromise against key
system objectives surrounding
trustworthiness, misbehavior handling,
and acceptance.
• Design of capabilities that would
enable secure updating of on board
equipment (OBE), Security Credential
Management System (SCMS), and other
component software, especially given
the complexity and lifetime of the
system and its components.
• Completion and clarification of the
specifications of the operation and
reporting functions around misbehavior,
blacklist, revocation, and of the data
elements maintained.
• Evaluation of the reduction of risks
in privacy protection with the
pseudonym certificate (PC) design
instead of other, less complex, yet
suitable privacy sensitive designs.
The above areas will be addressed by
USDOT and its industry partners as the
SCMS design continues to be refined,
and as part of the implementation and
operation of the first-ever fully
representative SCMS proof of concept
(PoC).
Further, even though it is not yet clear
whether the SCMS should be designated
as a ‘‘critical national infrastructure’’,
once the SCMS Proof-of-Concept
becomes operational, USDOT intends to
apply the NIST Framework for
Improving Critical Infrastructure
Cybersecurity, (currently, Version 1.0,
February 12, 2014). Much of the
guidance provided in The Framework
for Improving Critical Infrastructure
Cybersecurity is directed at
organizational practices to identify
cybersecurity risks; protect against
threats and detect cybersecurity events;
and respond to and recover from
cybersecurity breaches. As the SCMS
PoC organizational design and
governance policies mature and are
actually being implemented, then
USDOT will be able to apply the NIST
Framework to help identify and mitigate
residual risks.
In should be noted that USDOT (and
MITRE) were precluded from applying
the NIST Framework for Improving
Critical Infrastructure Cybersecurity
because the design of the SCMS was
only conceptual (not yet implemented)
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
and detailed organizational designs,
governance structures, and operational
policies and procedures remained to be
completed and implemented. However,
the risk assessment performed by
MITRE did follow the basic process of
identifying the state of the current
system and developing a target state of
cybersecurity to obtain through
refinement and additions to technical,
operational and governance aspects of
the system. Examples include the
MITRE risk assessment, the
investigation regarding the role,
functions, and governance
responsibilities of an SCMS manager,
and the analysis and evaluation of
cybersecurity protection needs that
moved the protection requirement from
FIPS–140 Level 2 to Level 3. The SCMS
design continues to mature to address
risks such as Root Compromise 214 and
software updates. Continued refinement
is also evident through the ‘‘SCMS
Proof-of-Concept End-Entity
Requirements and Specifications
Supporting SCMS, Software Release
Version 1.1, being used by Connected
Vehicle Pilots as they prepare to
connect to the SCMS PoC for
security.215
Further, it should be understood that
the SCMS PoC is being implemented at
this time by USDOT to serve USDOT
sponsored demonstrations and early
deployments—and to allow for a better
understanding both technically and
operationally of how the SCMS may be
deployed at a national level. To this
extent, the designs, methods, policies
and procedures implemented to ensure
secure communications, manage privacy
risks, and address cybersecurity threats
will need to be accepted and
implemented by the private entities that
choose to establish and operate a
National SCMS.
We welcome comment concerning:
The cybersecurity risks associated with
the SCMS; the analysis methods used to
date to assess risk; and what framework/
assessment methods should be used
during SCMS PoC implementation and
operation; and any other information
regarding possible threats and risk that
have not yet be identified.
4. SCMS RFI Comments and Agency
Responses
As discussed in Section II.F, NHTSA
issued a Request for Information
214 See Root Elector System Design at https://
www.mycreativeregistry.net/IPCOM/000245336 (last
accessed Dec 4, 2016).
215 The EE Requirements and Specifications can
be found via the following link: https://
www.its.dot.gov/pilots/pdf/
SCMS_POC_EE_Requirements.pdf (last accessed
Dec 7, 2016).
PO 00000
Frm 00087
Fmt 4701
Sfmt 4702
3939
(RFI) 216 regarding a potential Security
Credential Management System (SCMS)
that could support the National
deployment of a secure V2V
communication system.
The purposes of the RFI were to help
the agency: (1) Become aware of private
entities that may have an interest in
exploring the possibility of developing
and/or operating components of a V2V
SCMS; (2) Receive responses to the
questions posed about the establishment
of an SCMS provided in the last section
of the RFI; and (3) Obtain feedback,
expressions of interest, and comments
from all interested public, private, and
academic entities on any aspect of the
SCMS.
NHTSA received twenty-one
responses to the RFI with approximately
eleven of the responses indicating an
interest in running aspects of, or the
entire, SCMS. The respondents included
vehicle manufacturers, software
component developers and suppliers,
cryptography experts, certificate
management entities, satellite and
cellular service providers, and
academia.
Deployment of a V2V
communications system, and of an
SCMS to support confidence in V2V
communications, are unprecedented
activities. For this reason, the agency
believed it was appropriate to meet with
a subset of respondents, the eleven
expressing interest in operating aspects
of the SCMS or the SCMS as a whole,
to ensure there was a shared
understanding of respondents’
comments, potential role in an SCMS,
and the agency’s position on a possible
SCMS creation and implementation.
The agency was able to meet with ten
of the eleven respondents that had
indicated interest in operating aspects of
a potential SCMS. One respondent,
Verizon, was not able to meet with the
agency. The meetings took place
between January and March of 2015 at
DOT headquarters either in person or
via teleconference.
Overall, the meeting discussions were
very informative and the agency greatly
appreciated the time and effort the
respondents expended following-up
their RFI responses. In general, based on
the RFI comments and the discussions
with respondents, the team identified
the following key themes concerning
various aspects of the SCMS.
• Government must play a significate
role in the establishment and
management of the SCMS.
• Business opportunities are seen at
the CME and Security services levels.
216 79
E:\FR\FM\12JAP2.SGM
FR 61927 (Oct 15, 2014).
12JAP2
3940
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
• Security system entities understand
the relationship of the design to privacy,
with some indicating they may be able
to find some efficiency as they develop
their systems.
• One respondent indicated that the
design sets a new paradigm that other
regions may adopt in the future.
• An SCMS Board of Directors needs
to be initialized by the Federal
Government—specifically citing the
existing ICANN Model,217 charged with
managing the world-wide-web domain
and server naming allocation and
standard, as an example framework that
could transcend to V2V.
• Establishment of the SCMS
Manager would require capital/initial
funding.
• One entity discussed being the
SCMS Manager.
• One entity indicated they would
build and operate the entire SCMS
system but would need another entity to
be the SCMS Manager.
• Little information provided about
potential financial models.
• Possible revenue sources included:
CME license fees, certificate
subscription fees, yearly service fees.
• To move forward with
development/deployment, all indicated
they need more information regarding
the Government role, the SCMS
Manager, and details about the security
design.
• Liability was a major concern, with
a strong interest from all participants in
some form of Federal indemnification.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(a) SCMS RFI Comments
(1) UMTRI
The University of Michigan’s
Transportation Research Institute
(UMTRI) met with representatives from
the NHTSA V2V NRPM Team to discuss
their SCMS RFI response. UMTRI’s
response provided views regarding
privacy, governance, potential SCMS
component separation and linkage.
UMTRI’s RFI response indicated other
parties may be better suited to respond
on specific governance organizational
aspects but supported a public-private
partnership model for overall
governance, a potential model discussed
in the V2V Readiness Report. UMTRI
went one step further by offering the
suggestion of an additional ‘‘publicprivate-academic’’ model that could
potentially benefit from an academic
partner’s fundamentally neutral stance,
little commercial interests and direct
access to significant research resources.
More specifically, UMTRI expressed
217 See, e.g., https://www.icann.org/resources/
pages/chart-2012-02-11-en (last accessed Dec. 7,
2016).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
interest in participating in the SCMS
Manager and potentially being ‘‘a proper
candidate’’ for operating the two
Linkage Authorities identified in the
current system design. UMTRI indicated
their regular work on classified projects,
existing infrastructure, and their
experience ‘‘running highly privacy
sensitive computer systems such as the
University of Michigan Health System
support their interest in operating the
Linkage Authorities.’’
UMTRI indicated other parties may be
better suited to provide a response
regarding financial sustainability. In our
meeting, however, UMTRI indicated
they could possibly pose the SCMS
financial sustainability proposition to
their MBA students as a potential
project.
When discussing potential SCMS
operational and policy standards,
UMTRI indicated support for NHTSA’s
approach that SCMS components like
the CME should be legally distinct.
Support for keeping SCMS components
legally separate is rooted in the need to
ensure privacy and based on the key
notions that firewalls within a single
legal entity might not be sufficient to
ensure privacy, different legal
organizations will most likely protect a
data center with a differing
technologies, and that distinct legal
organizations inhibit the possibility of a
single point of entry into multiple
systems.
UMTRI suggested two types of
operational policies, Type 1 for
applications that are under governance
of SCMS Manager (e.g., V2V safety
applications) and Type 2 for
applications that are not under the
governance of SCMS Manager but are
part of the V2X application portfolio
(e.g., mobility applications provided by
third party providers).
(2) Certified Security Solutions, Inc.
Certified Security Solutions, Inc.
(CSS) represented the exposure to new
potential stakeholders, suppliers, and
services V2V is bringing to NHTSA. CSS
supplies security solutions such as
security certificate management systems
and managed public-key infrastructures
(PKI). CSS also provides digital security
consulting services related to PKI and
identity and access management.
Historically, the agency has not
interacted with suppliers such as CSS in
the course of regulating vehicle
manufacturers and, similarly, CSS has
been involved with industries far
removed from the auto industry, such as
supporting digital certificates for
surgical devices like heart pacemakers.
CSS indicated interest in three areas
of the SCMS: (1) Participation in an
PO 00000
Frm 00088
Fmt 4701
Sfmt 4702
advisory board regarding the policy,
specifications, and requirements of the
SCMS, V2V initiative, and its
components, (2) creating components
and solutions, such as the Registration
Authority or Device Configuration
Manager, and (3) creating software and/
or managed service offerings for
operations and oversight such as
‘‘dashboards’’ used for monitoring
system performance.
CSS’s response to the RFI centered on
the first question related to governance.
CSS foresees a large and diverse array of
participants involved in the operation of
a National SCMS deployment. As such,
CSS indicated examples of ‘‘selfgovernance’’ advisory boards that have,
‘‘proven to be relatively effective in
improving the interoperability and
overall security of their respective
areas.’’ In their view, CSS suggested that
this sort of overall model ‘‘makes the
most sense when considering the
magnitude and importance of an
initiative such as the SCMS.’’ These
examples included:
• The certification authorities (CA)/
Browser forum (https://cabforum.org),
comprised of CA and web browser
vendors with a focus on defining a
coordinated set of guidelines to improve
browser and SSL security.
• The Internet Engineering Task
Force (IETF) (www.ietf.org) and its
collection of specific Working Groups.
• The Industrial Internet Consortium
(www.iiconsortium.org), an industrydriven working group aimed at solving
the challenges posed by large-scale
machine-to-machine (M2M)
communication.
The agency’s meeting with CSS
yielded additional details on their
written response along with ideas for
potential approaches to a National
SCMS deployment. At the highest level,
CSS indicated a potential SCMS
advisory board would be responsible to
define the appropriate certificate policy
standards to ensure consistent and
successful implementations that will be
required for the anticipated multiple
CAs deployed across multiple systems.
CSS indicated that utilizing multiple
root CAs may benefit from redundancy
versus a single root CA, and also
brought forth the notion of ‘‘bridged’’
root CAs that could be cross-signed to
allow different vehicle or device
manufacturers to ‘‘trust’’ each other
while maintaining their own ‘‘root of
trust,’’ enhancing confidence in message
exchanges.
SCMS financial sustainability
discussions were limited to existing
approaches for certificate management
services, where per certificate fees could
potentially be avoidable.
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(3) Trustpoint Innovation Technologies,
Ltd.
Representatives from Trustpoint
Innovation Technologies met with the
V2V NPRM Team to discuss their
submission to the RFI response.
Trustpoint was founded in 2012 by Dr.
Scott Vanstone and Sherry Shannon.
Mr. Vanstone was also a co-founder of
Certicom, whom also provided a
response the SCMS RFI, which was
acquired by BlackBerry in 2009.
Trustpoint has been involved with the
SCMS and security design research
conducted with the agency’s research
partner, CAMP. Trustpoint’s response to
the RFI focused on their interest in
helping to develop deployment-ready
SCMS components such as the
Pseudonym CA, Registration Authority,
Linkage Authority, Enrollment CA,
Intermediate CA, and Root CA.
Trustpoint indicated that significant
investment and development in
software and testing will be necessary to
deploy a National SCMS. This is based
on their belief the PKI approach used for
SCMS research will need to be extended
and extensively proven for a production
system, based on the need for a new
software stack 218 built around new
cryptography and protocols. Trustpoint
is interested in being part of a
consortium to deploy production SCMS
components.
When meeting with the agency,
Trustpoint expanded on their views of
a National SCMS deployment. The key
discussion points included
cryptography approaches, attack
vectors, participation in a consortium,
and thoughts on production deployment
that includes clear policies and
procedures, and thoughts on device
level security. In addition, Trustpoint
reviewed the cost model the agency
provided with the ANPRM and V2V
Readiness Report.
Trustpoint discussed how Elliptic
Curve Cryptography (ECC) is, in their
opinion, the only feasible security
solution for resource-constrained
environments where processing power,
power consumption, storage space, and
bandwidth are limited. In comparison to
RSA,219 an early wide-spread remote
device security mechanism, ECC is
much more compact yet provides a
higher level of security. Trustpoint
indicated that 500 bits of ECC
information is equivalent to nearly 1500
bits of RSA cryptographic information.
Trustpoint supported the
development of a ‘‘test bed’’ for
components that could operate in a
National, deployed system. Successful
deployment and verified operation in
the test bed could be considered
‘‘certified for deployment.’’ Components
certified in the test bed would support
an ‘‘off-the-shelf’’ software component
approach that, for example, would yield
Registration Authorities for each
manufacturer. Trustpoint stressed the
need to have standardized components
for consistent system interaction while
allowing each OEM to manage their
vehicle fleets individually versus a
central management approach. The
SCMS Proof of Concept project
currently under development by the
agency and CAMP, to support
connected vehicle test beds that will be
deployed regionally along with
expansion of the Safety Pilot Model
Deployment environment more broadly
throughout southeastern Michigan,
could potentially serve as a test bed for
broader, National system deployment.
Trustpoint suggested, however, that
additional definition and
implementation will be needed in the
areas of operation, management, and
auditing for a successful National SCMS
deployment.
Trustpoint suggested the cost model
provided by the agency and used in the
V2V Readiness Report cost calculations
needed some adjustment in the areas of
bandwidth, hardware security module,
and software development costs. More
specifically, Trustpoint indicated
replication for hardware security would
be needed for redundancy and
continuous, uninterrupted system
operation. Trustpoint estimates the
annual issuance of 36 million
certificates will have additional
bandwidth needs beyond that estimated
in the cost model. Finally, Trustpoint
believed the software development cost
used in the cost model was substantially
underestimated.
218 A software stack is a set of programs that work
together to produce a result; typically an operating
system and its applications. For example, a
smartphone software stack comprises the operating
system along with the phone app, Web browser and
other basic applications. See https://
www.pcmag.com/encyclopedia/term/51702/
software-stack (last accessed Dec. 8, 2016).
219 RSA is a cryptosystem for public-key
encryption, and is widely used for securing
sensitive data, particularly when being sent over an
insecure network such as the Internet. See https://
searchsecurity.techtarget.com/definition/RSA (last
accessed Dec. 8, 2016).
(4) DURA Automotive Systems, LLC
Dura Automotive Systems, LLC is a
Tier 1 supplier to the automotive
industry supplying structural body
systems, mechatronic control systems,
and exterior systems including window
systems and exterior trim. Dura
responded to the SCMS RFI with a
vision of how the SCMS Manager could
be formed, implemented and sustained.
Dura indicated they would like to fulfill
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00089
Fmt 4701
Sfmt 4702
3941
the role of developing and
implementing the SCMS governance
board and participating as a member.
Dura was the only respondent
indicating interest in taking the role of
developing functions at the SCMS
Manager level and above.
Dura favored a private model
governance approach for the SCMS,
excluding some identified issues. In
their response, DURA identified two
successful examples of both private and
public models currently in place that
address requirements similar to those
identified in the RFI. A private model
example is the Internet Corporation for
Assigned Names and Numbers
(‘‘ICANN’’),220 a private, not-for-profit
corporation established in 1998. The
public model cited by Dura is the
operating arrangement for the Federal
Aviation Administration (FAA) and the
national air traffic control system.221
DURA specifically suggested, ‘‘a
policy statement from the Department of
Transportation advising the public that
the U.S. government is prepared to enter
into an agreement with a new, not-forprofit corporation formed by private
sector transportation multi-stakeholders
to administer the Security Credential
Management System’’ and suggested the
corporation be referred to as, ‘‘the InterConnected Automotive Safety Network
(‘‘ICASN’’). Additionally, Dura
suggested that its incorporation,
governance and operation mirror as
much as possible to that of ICANN.’’
Dura suggested a subscription-based
approach for ongoing SCMS
sustainability and further recommended
‘‘aligning the subscription period with
vehicle licensing/annual license plate
renewal.’’ Dura also commented on how
liability for system operation could
influence costs; more specifically, from
an insurance cost perspective.
(5) Bosch—ESCRYPT
Robert Bosch LLC affiliate ESCRYPT
provided a response to the SCMS RFI
with comments on potential governance
strategies and expressed interest in
implementing the Pseudonym
Certificate Authority (PCA) and Linkage
Authority (LA) components.
Bosch-ESCRYPT supported a privatepublic collaboration versus a selfgovernance model and commented that
SCMS ownership should take a multilayered approach, with high level
220 For more information on the ICANN private
model, see https://www.icann.org/resources/
unthemed-pages/icann-mou-1998-11-25-en (last
accessed Dec. 8, 2016).
221 For more information on the public FAA
model, see https://www.faa.gov/about/office_org/
headquarters_offices/agc/pol_adjudication/agc400/
litigation/ (last accessed Dec. 8, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
3942
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
policies residing within the USDOT and
lower level implementation
responsibility given to private
organizations. ESCRYPT supported
having the SCMS spread amongst
differing, distinct organizations to help
maintain privacy, and recommended a
governance board to fulfill the SCMS
Manager function, with membership
defined by NHTSA but to include
representatives from government,
vehicle manufacturers, private
organizations, and privacy groups.
ESCRYPT expressed interest
implementing a production SCMS PCA
and LA based on their support of the
Safety Pilot Model Deployment. In their
SCMS RFI response, ESCRYPT
proposed an architecture that utilizes
two types of certificates to ensure
privacy. The first is short term
pseudonyms, lasting from seconds to
hours and being switched frequently.
The second is long-term certificates
along with three Certification
Authorities: Long-Term; Pseudonym;
and a Resolution Authority, the latter of
which strips anonymity from
pseudonym certificates that are believed
to be a potential threat.
When meeting with the agency,
Bosch-ESCRYPT expressed the
importance of regional policy
harmonization and stable standards,
indicating that, once implemented,
these important pieces will be not be
changed easily or quickly.
The agency asked ESCRYPT for their
experience on device management and
how ESCRYPT has handled conditions
such as managing and closing security
breaches, device ‘‘end of life’’
management, and hardware security to
help inform potential approaches for
this NPRM. ESCRYPT indicated that
over-the-air (OTA) software update is
the best approach to closing potential
security breaches and in support of
NHTSA’s vital recall efforts. When
discussing device ‘‘end of life’’
scenarios, ESCRYPT suggested the
approach of revoking existing
certificates for an identified device and
preventing future certificate updates
allowing, in theory, the device to ‘‘fade
away’’ from the system. Finally, when
discussing potential hardware security
needs, Bosch indicated they have
experience with hardware security
modules (‘‘HSM’’) and secure hardware
extensions (‘‘SHE’’) successfully
deployed in Europe and that, in terms
of V2V, a lower-security
implementation limits potential use
cases of a system. The agency interprets
this discussion, overall, that proposing
a hardened device could extend a
device’s capability and contribute to
overall system confidence.
(6) Certicom/Blackberry Technology
Solutions
Certicom, a wholly owned subsidiary
of Blackberry Ltd., provided a response
to the SCMS RFI and also met with the
agency to follow-up their response.
Certicom provides ‘‘applied
cryptography and security solutions for
the embedded market’’ including
engagement with governments and
vehicle OEMs. Certicom has experience
implementing Elliptic Curve
Cryptography (ECC), ‘‘which provides
the most security per bit of any known
public key cryptosystem.’’ Certicom’s
parent company, BlackBerry, builds
devices used by government and
enterprise organizations, and operates a
global secure network and mobile
messaging platform. BlackBerry
Technology Solutions also operates
BlackBerry’s QNX group which has
presence in automotive telematics
implementations.
Certicom supported a private
consortium to manage a V2V SCMS,
indicating that this approach could help
‘‘accelerate the deployments of V2X
systems’’ serving both infrastructure and
aftermarket devices. They stated that a
possible ‘‘concern could arise if
regulation unnecessarily limits the
opportunity for participants to drive
commercial innovation.’’ Certicom
expressed interest in the SCMS
operational roles of the Certificate
Management Entity (CME) such as
operating a Certification Authority (CA)
and/or a Registration Authority (RA).
However, Certicom indicated revenue
models and costs would need to be
better understood before committing
definitively to any portion of the system
operation.
Certicom commented that long-term
viability of the SCMS is highly
dependent on public acceptance. As
such, participants in the system need a
strong public identification (brand) and
experience with successful security,
safe, reliable and privacy
implementations.
During the agency’s meeting with
Certicom, the discussion focused on
clarifying the RFI responses but also in
key areas of revenue generation, security
approaches, and certificate and device
management approaches used for
Blackberry devices and other
implementations that Certicom has
supported, which includes public utility
installed residential ‘‘smart meters.’’
Certicom indicated there could be
many reasons that entities would want
to participate in a National SCMS and
there could be potential opportunities
presented such as the support of the
security needs for manufacturing and
system operations. In addition,
expanded future roadside equipment
could lead to yet-unknown revenue
generation opportunities. Overall, V2V
and a supporting SCMS could, in
theory, ‘‘create a whole new market.’’
Certicom also suggested participants in
the SCMS could generate on-going
revenue by royalties from device
manufacturers.
In terms of approaches to device
security, Certicom indicated there are at
least three security key-scenarios for
devices. The following table provides an
overview of these approaches and a
corresponding, relative level of security
provided by each.
TABLE V–2—OVERVIEW OF SECURITY APPROACHES
PKI ......................................
Example ...............................
Relative Security ..................
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Security Method ...................
Thermostat ..........................
Sufficient .............................
When discussing device and
certificate management, Certicom
provided an overview of three certificate
distribution and management systems:
Blackberry PKI, the ZigBee Smart
Energy public utility residential meter
system, and Certicom’s approach to
certificate and asset management for
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
Keys/Certificates sent to device at time of manufacture.
Telematics ..................................................................
Better ..........................................................................
device original equipment
manufacturers (OEMs).
The certificate service for Blackberry
devices is designed for scalability, and
secures devices from ‘‘birth’’ where a
registration ‘‘seed’’ is embedded in the
a device’s onboard microchip
(‘‘silicon’’) at the time of device
PO 00000
Frm 00090
Fmt 4701
Sfmt 4702
In device chipset (‘‘silicon’’).
Blackberry.
Best.
manufacturer. The registration seed
could be viewed like a V2V enrollment
certificate, all of which is linked to the
‘‘root of trust’’ for the Blackberry
ecosystem.
Certicom’s overview of the ZigBee
public utility smart meter certificate
system varies from Blackberry devices,
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
3943
performed to confirm that each device’s
media access control (MAC) 222 address
is unique. Key pairs for each device are
then bound to the device MAC address
and vendor ID through the certificate.
Figure V–2 shows a graphic
representation of the ZigBee certificate
management system.
are assembled at geographicallydispersed locations, similar to how
vehicles are assembled. The system
described provides operational visibility
and control of secure key injection into
a device at time of manufacture or
initialization, secure device serialization
and tracking, and support for anticloning and anti-counterfeiting. Figure
V–3 provides a representation of this
system and shows the remote
management across various locations.
The ‘‘tester’’ would be the point of
security key injection into a device.
222 Media Access Control address refers to the
unique 48-bit serial number in the network circuitry
of Ethernet and Wi-Fi devices that identifies that
machine from every other globally. See https://
www.pcmag.com/encyclopedia/term/46422/macaddress (last accessed Jul. 14, 2015).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00091
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.011
utilize an EQCV format issued in
batches of one million. Certicom
indicated they are able to issue
approximately one million certificates
in approximately one and half hours of
processing. Each device participating in
the system is identified by unique
vendor identification, and verification is
Finally, Certicom provided an
overview of a certificate authority and
asset management system that they are
able to supply for device original
equipment manufacturers. The system is
designed to enable OEMs and silicon
vendors to remotely secure devices that
srobinson on DSK5SPTVN1PROD with PROPOSALS2
in that devices participating in that
system are supplied from various
manufacturers—similar to how V2V
device implementation is envisioned,
but the ecosystem itself could be viewed
as localized.
In this implementation, ZigBee
‘‘Smart Energy’’ device certificates
3944
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
loading security information to a device
in an untrusted manufacturing
environment.
EP12JA17.013
information, to an untrusted contract
manufacturing environment supplying
components for their end product.
Figure V–4 shows the process flow for
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00092
Fmt 4701
Sfmt 4725
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.012
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Certicom indicated that this system
enables OEMs to manage and distribute
the sensitive security keying material,
along with potentially other sensitive
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
3945
As mentioned elsewhere in this
section, device management also
involves potential updates to device
software to support technology updates
and, importantly, in support of potential
device recall scenarios. Certicom
discussed Blackberry’s OTA update
service used for updating, configuring,
and managing software and
applications. Their updates leverage the
existing Blackberry exclusive secure
infrastructure for global distribution.
This system also gathers status and data
to support fleet monitoring capabilities
for device operation. A graphic
overview of the system is shown in
Figure V–5.
With end-of-life and misbehavior
being key elements of a national V2V
deployment, the agency inquired about
approaches for managing devices under
these conditions. Certicom indicated
that Blackberry devices can be remotely
made non-functional (‘‘bricked’’) when
a device is determined to be out of
service, stolen, not functioning properly
or potentially ‘‘misbehaving.’’
Reactivation of a ‘‘bricked’’ device
requires interaction with Blackberry.
not have roadside units deployed.
SiriusXM indicated that their
infrastructure ‘‘could provide the
ubiquitous, simultaneous, and robust
distribution of security certificates and
the certificate revocation list (‘‘CRL’’) in
a V2V system.’’ SiriusXM’s satellite
network covers the contiguous United
States and portions or Canada and
Mexico, which could possibly assist
with potential cross-border challenges.
Their network also includes signal
repeating equipment to supplement
service in urban areas where satellite
reception could be blocked by buildings
or other obstacles.
According to SiriusXM, 69 million
vehicles are currently equipped with
their radios, and they expect this to
increase to 100 million vehicles by 2017
as approximately 70% of new vehicles
are equipped with their receiver.
When discussing privacy, SiriusXM
indicated that no subscription would be
required to receive satellite V2X data
and that it would be available to any
vehicle equipped with their satellite
receiver. SiriusXM did not present any
potential revenue generation concepts
during the discussion. Additionally,
SiriusXM stated V2X will be a
transparent data service on its system,
meaning that no V2X-related data is
collected on the vehicle, and that the
satellite delivery system has no
knowledge of which vehicles are active
and receiving data or where vehicles are
located.
In terms of device management,
SiriusXM suggested a hardware security
module (HSM) for V2V-enabled devices
as part of a trusted, secure data
exchange environment. SiriusXM
provided very detailed technical
descriptions of how device-level
security could be implemented and
managed using satellite radio service.
This included discussing the potential
use of group codes, interaction with the
HSM, in-use certificate downloads,
available service channels, and revoked
vehicle identification, all of which
leverages its experience with the
development and deployment of its
satellite radio network that appears to
have addressed many similar challenges
found in V2V device deployment and
management.
SiriusXM Satellite Radio provided a
response to the SCMS RFI and also met
with the V2V NPRM team as follow-up.
Their written response to the RFI
focused on the opportunity for satellite
transmission to perform non-safetycritical, ‘‘back haul’’ type operations for
a SCMS. This could include certificate
distribution, over the air updates, and
certificate revocation list distribution,
among other potential supporting
transactions. SiriusXM commented that
employing a satellite network as an
alternative distribution path for safety
certificates and the CRL would promote
the development of a V2V system by
enhancing scalability and the SCMS
network footprint, and enable faster
distribution of security information for
V2V-equipped vehicles.
SiriusXM indicated that satellite
transmission could potentially ‘‘bridge
the gap’’ between initial V2V
deployment and roadside unit
deployment and, in the longer term,
support more remote regions that may
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00093
Fmt 4701
Sfmt 4702
(8) Ford Motor Company and
Volkswagen Group of America
Ford Motor Company (‘‘Ford’’) and
Volkswagen Group of America
(‘‘Volkswagen’’) submitted joint
comments to the SCMS RFI. Together,
Ford and Volkswagen indicated they are
encouraged by the progress made in the
collaborative activities between NHTSA
and CAMP, in which they participate.
However, they state in their comments
that remaining items need resolution to
enable an effective deployment of a V2V
communications system, such as: (1)
NHTSA’s authority to mandate an
SCMS; (2) an acceptable and stable
funding model, and; (3) measures to
address potential liabilities associated
with participating in and/or being
subject to a SCMS.
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.014
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(7) SiriusXM Satellite Radio
3946
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
Ford and Volkswagen commented
that the SCMS cannot be a private entity
because vital functions of the SCMS
cannot be delegated to a ‘‘private’’
entity, ‘‘which lacks the authority to
require all participants in a V2V (let
alone V2X) communication system to
adhere to the system’s necessarily
rigorous operational policies, and
enforce revocation based on
unacceptable performance.’’ Ford and
Volkswagen stated that they, other
OEMs, and others that will necessarily
rely on the SCMS must have a role,
along with government, in establishing
SCMS operational policy. Additionally,
they stated that Federal authority over
the SCMS is essential and a binding
governance board for SCMS
management is needed.
Finally, Ford and Volkswagen stated
that funding for centralized SCMS
components or functions should come
from a federal source. They do not
support any funding model relying on
the sale of data to third parties, and,
additionally, the SCMS funding model
‘‘should not be based on a potential
requirement that specific services must
be enabled within the vehicle to offset
operational costs.’’ Conversely, noncentralized components, like the
certificate management entity (CME) or
registration authority (RA), could be
established independently for their own
use.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(9) SAE International
The Society of Automotive Engineers
(‘‘SAE’’) responded to the RFI with
interest in playing a supporting role in
SCMS deployment. SAE indicated
interest in working with SCMS
stakeholders in a partnership and/or
larger consortium to support the SCMS
functions, ‘‘through a combination of
standards development, conformance
programs and training.’’
SAE International standards J2735
and J2945 were revised and are being
developed to support a national V2V
deployment by providing a consistent,
standardized approach to V2V device
implementation across the industry.
(10) The American Motorcyclist
Association
The American Motorcyclist
Association (‘‘AMA’’) commented to the
SCMS RFI by urging DOT to test the
V2Vcommunication systems to ensure
that motorcyclists’ safety and privacy
are secure. AMA expressed their
support for DOT’s position ‘‘for further
testing before adopting the rule
authorizing U–NII devices (e.g., Wi-Fi)
to operate in the band to ensure vehicles
using advanced crash-avoidance and
vehicle-to-vehicle technologies are not
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
compromised.’’ AMA also expressed
concern about the potential for
‘‘hacking’’ into a future V2V network,
and specifically, the potential to
manipulate traffic signals which could
be ‘‘especially disconcerting for
motorcyclists who comprise the most
vulnerable roadway user group.’’ AMA
closed their comments stating that the
safety of all highway users should
always be a priority whenever new
technologies are considered.
(11) Alliance of Automobile
Manufacturers, Inc.
but must be conducted under the
authority and supervision of a
significant governmental entity.’’
Global Automakers further stated that,
to be effective, the SCMS must be a
monopoly, which is not allowed under
law for a private entity, and that funding
for the SCMS should come from the
government rather than from revenue
generated by consumers; less potential
consumer subscription funding
opportunities for some potential V2I
services. Additionally, the SCMS should
be developed to support V2V and V2X
holistically, at the outset, in partnership
with the Federal Highway
Administration (FHWA) and possibly
other agencies such as the Federal
Communications Commission and the
Federal Trade Commission where
privacy is of concern. Global
Automakers stated that cross-agency
coordination and harmonization is
critical to the effective operation of the
SCMS.
Global Automakers expressed concern
with the potential approach for the
‘‘Device Non-compliance and Potential
Recalls’’ discussion in the RFI materials,
specifically, that it believed that the
approach suggested by the agency
would undermine consumer privacy, be
impractical, and be redundant to
systems that are already in place to
manage recalls. It commented that the
proposed ‘‘link between specific
installed V2V devices or production lots
of devices and enrollment certificates’’
would create a potential perception that
V2V communications could be traced to
individual vehicles and drivers.
The Alliance of Automobile
Manufacturers, Inc. (‘‘Alliance’’)
reiterated their comments to NHTSA’s
V2V ANPRM where they ‘‘agreed with
NHTSA’s assessment that a strong
SCMS is necessary for a properly
functioning V2V communications
system.’’ The Alliance also reiterated its
ANPRM comments expressing concerns
with how a privately-run SCMS could
address the broad structural and
governance challenges that an SCMS
manager would need to address, such
as:
• Funding, deployment, operation and
maintenance of a DSRC-based V2X
security communications network
• Sustainable funding for V2X PKI
security system operations and
management
• Governance of a V2X security system
(Rules of Use, Certification, and
system access)
• Protection of consumer privacy
• Liability, risk management, and
intellectual property protections
• International considerations including (13) Verizon Communications, Inc.
possible Canada-US-Mexico crossVerizon Communications’ RFI
border traffic, international
response focused on potential steps and
agreements, or standards
pathways to achieving a National SCMS
harmonization.
deployment and focused on three key
The Alliance maintained in its RFI
approaches to SCMS policies and
response that addressing the above
operations standards and potential
policy issues, which are necessarily
adjustments to the PKI implementation.
national in scope, requires strong
In more detail, Verizon suggested that:
unified Federal leadership, not just
(1) NHTSA should define a system of
presence.
policies, regulations, workflows, and
technical interoperability that provides
(12) Association of Global Automakers
for the management and control of the
The Association of Global
overall SCMS; (2) implement an
Automakers (‘‘Global Automakers’’)
‘‘identity PKI’’ as a baseline and
provided general comments along with
‘‘bootstraps’’ anonymously allowing
direct responses to the RFI questions. In linkage between certificates and
its comments, Global Automakers
supporting potential device recalls; and
strongly supported a public-private
(3) an ‘‘anonymity PKI’’ solution that
partnership model for SCMS operation
allows the device to perform any
by stating that ‘‘the agency has
necessary operations anonymously.
underestimated the necessary
(14) General Motors, LLC
governmental role in managing the
General Motors, LLC (‘‘GM’’)
SCMS and too narrowly constrained the
participation of other agencies in SCMS submitted comments to the SCMS RFI
that also included broader V2V
operations. Contractor operation of
rulemaking comments. GM stated, in the
many aspects of the SCMS is feasible
PO 00000
Frm 00094
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
broader context of V2V, that they
support NHTSA’s rulemaking initiative
for all passenger cars and light trucks to
be sold in the United States, and that ‘‘a
comprehensive and connected
ecosystem must be developed and
implemented offering seamless and
trusted communication between
vehicles’’ to obtain all the potential
benefits of V2V technology. GM
commented that it strongly believes that
a NHTSA rulemaking process is the
only method to successfully establish a
V2V ecosystem; that, as envisioned, the
system cannot be established and
managed by a single manufacturer or
industry group.
Focused comments regarding the
SCMS stated its belief in the
requirement for Federal oversight of the
SCMS Manager, the central root
authority organization, direct
engagement with the Misbehavior
Authority and coordination of
certification labs.
proposed system has gaps that must be
addressed before it is implemented.
Tesla narrowed its primary concerns
into the following: (1) Because inputs
are insecure, false messages are likely,
even with secure V2V subsystems; (2)
vehicles must have some way to
determine whether messages,
particularly misbehavior reports, are
legitimate; (3) certificate revocation lists
(‘‘CRLs’’) do not scale well for
widespread use; (4) public-key
cryptography is poorly suited to the
demands of an embedded, high-speed
environment; and (5) transmitted
messages could be the source of privacy
breaches.
Tesla concluded their comments by
stating that ‘‘the Company believes that
the CAMP system has fundamental
issues and challenges that must be
revisited in order to allow for successful
implementation of the SCMS.’’
(15) CTIA—The Wireless Association
Intercede, Ltd. is a software company
solely focused on producing and
delivering identity and credential
management solutions to entities such
as Government, Aerospace and Defense,
Finance, Healthcare, Large Corporations
and Managed Service Providers.
Intercede’s response to the RFI focused
on the need for the SCMS to provide a
secure and trusted environment for
V2X, and stated that it will be necessary
to consider the V2X communication
devices over their entire lifetime, which
was defined as:
• Initial manufacture;
• Upgrade;
• Maintenance;
• Transfer of ownership;
• Renewal;
• Compromise;
• Natural end of life.
Intercede’s response went on to state
that ‘‘it is also important to consider the
interactions beyond the communication
channels that must be established into
a secure trust system. Failure to do so
would open up potential back doors
into this trust system that could allow
for compromise to occur from within.’’
Follow-up discussion with Intercede
stressed its views regarding the need for
a complete, systems approach to
security—encompassing ‘‘cradle to
grave’’ for devices. And that, ‘‘By
adopting a controlled and secure
approach to device identity
management, NHTSA will enable a
strong trust environment to be
established that can then be built on for
large-scale key generation during the
lifetime of the device in the field for
V2X communications.’’
CTIA is an international nonprofit
organization representing the wireless
communications industry. CTIA’s
members include wireless carriers and
their suppliers, as well as providers and
manufacturers of wireless data services
and products. CTIA’s comments to the
SCMS RFI focused on the benefit of
leveraging existing authentication and
security technology, along with utilizing
existing networks and infrastructure to
promote standardization and
interoperability. CTIA also stated that
the private sector is best positioned to
address V2V SCMS cybersecurity and
privacy concerns and should be utilized
to help implement cybersecurity best
practices.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(16) Tesla Motors, Inc.
Tesla Motors, Inc. (‘‘Tesla’’)
commented primarily on the security of
the SCMS design presented in the V2V
Readiness Report by urging NHTSA ‘‘to
ensure that all possible security aspects
are considered and accounted for when
implementing its chosen design.’’ Tesla
commented that much more analysis
and consideration needs to be given to
the SCMS before it is implemented as
proposed. Tesla acknowledges that it
has not been involved with the Crash
Avoidance Metrics Partnership (CAMP)
consortium and that this brings a new
perspective to the CAMP SCMS design.
Tesla believes that, as envisioned, the
CAMP system fails to consider
adequately how the system could be
attacked or the vast amounts of
information that will necessarily pass
between vehicles and that NHTSA’s
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
(17) Intercede Ltd.
PO 00000
Frm 00095
Fmt 4701
Sfmt 4702
3947
(b) SCMS RFI Agency Response
The RFI responses and subsequent
meetings benefitted NHTSA greatly by
providing additional technical
perspectives on the SCMS PKI design.
For example, DOT had originally
dismissed the use of satellites as a
viable communications media for
transmission of security materials
between the SCMS and OBE, but our
meeting with Sirius XM Radio brought
to NHTSA’s attention the fact that, due
to advances in technology and the close
working relationship between the auto
and satellite industries, satellite could
in fact be a technologically and
economically viable, secure and private
media for such security transmissions.
Similarly, the PKI technical model put
forth by NHTSA in its Readiness Report
assumes that a single root must form the
basis for trust system-wide. However, as
a result of meetings with CSS, NHTSA
now is aware of the possibility that,
through use of a trust bridge, one or
more SCMS organizations, possibly
representing different regions or even
manufacturers, may be able to co-exist
and together, provide more redundancy
in security for V2V and V2X DSRC
communications.
5. SCMS ANPRM Comments and
Agency Response
(a) ANPRM SCMS Comments
With limited exception, comments
received in response to the ANPRM
generally endorsed the PKI design as an
appropriate security solution for V2V
and V2I DSRC communications. For
example, GM, the Alliance, Toyota, and
the Automotive Safety Council all
concurred that the SCMS design
described in the ANPRM and the V2V
Readiness Report should provide the
required level of security while also
protecting the privacy of the end users.
Throughout all the comments there
were two major concerns with the
SCMS design that were cited by
multiple commenters: (1) The overall
complexity of the design; and (2) a
fallback plan for a compromised root.
One of the recurring comments in the
ANPRM focused on the overall
complexity of the design of the SCMS
and the plan for implementing such a
system. The design of the SCMS is more
complicated than any existing PKI
systems due primarily to the need to
protect the privacy of the end users both
from outsider and insider attacks. As
such the various functions in the system
are separated logically and
organizationally in an attempt to ensure
that one organization does not have
access to all the information needed to
identify the end users. Therefore, this
E:\FR\FM\12JAP2.SGM
12JAP2
3948
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
level of complexity is necessitated by
the system requirements.
The second technical concern
highlighted in the comments is the
impact on the system if the private key
of the SCMS root certificate authority is
compromised. If the root CA is
compromised, then this would
compromise certificates for all V2V
devices, roadside infrastructure devices,
and SCMS components. Reissuing the
certificates for over 350 million end
users would require a significant
amount of time and resources to
complete. For example, all V2V devices
would need to be re-initialized in order
to receive a new enrollment certificate;
however, this process must occur over
a secure communications channel. This
may require all devices to return to the
dealership or service center in order to
have access to the secure
communications channel required for
the initialization process.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(b) ANPRM Agency Response
In response to the first concern, the
agency agrees that the level of
complexity of the design does increase
the risk associated with the
implementation and deployment of this
system. To combat that risk, one
commenter suggested that the system be
implemented through a phased
development approach where
components of the system are
developed, tested, and deployed
incrementally. This approach would
ensure that the deployed components
are secure and reliable for additional
components are deployed into the
system. The agency agrees with this
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
recommendation and is employing in it
the development of the SCMS Proof-ofConcept. This system is being
developed using an incremental
approach that focuses on first
implementing and testing the core
components of the system, followed by
the non-core components. After the
system is developed and tested, it will
be operated for a significant period of
time by DOT. During this operational
period, existing V2V and V2I test beds
will be integrated with the SCMS POC,
and it will provide the necessary
security credential materials to these
test beds. The knowledge gained from
the operation of the SCMS POC will
inform the development of the National
SCMS that will be required to support
an eventual FMVSS.
The agency also concurs that it would
be a catastrophic event for the root CA
to be compromised, and as such we are
exploring various approaches for
disaster recovery that can be
implemented to mitigate this risk. The
SCMS Proof-of-Concept will implement
and test root management and disaster
recovery solutions that will allow a root
CA to be revoked without requiring the
recall and re-initialization of all the V2V
and V2I devices in a secure
environment. One of the solutions to be
tested in the SCMS POC is a distributed
root management approach that utilizes
root electors to manage the trust
relationships in the system. Another
solution being evaluated includes the
use of redundant root CAs where only
a single root is active at any one time.
These approaches will be tested and
evaluated during the operation of the
PO 00000
Frm 00096
Fmt 4701
Sfmt 4702
SCMS POC to ensure that in the event
of a compromised root, the system can
be recovered without the need to recall
every V2V and V2I device.
6. SCMS Industry Governance
(a) The SCMS ‘‘Industry’’
Deployment of an SCMS PKI to secure
V2V DSRC communications will require
governance of a wide range of complex
functions and involve numerous public
and private stakeholders, which
together we refer to here as the SCMS
‘‘industry’’ or SCMS ‘‘ecosystem.’’ We
expect that SCMS stakeholders will
include: Manufacturers of OBE, RSU,
and aftermarket safety devices (ASD);
certification labs that test OBE (and
potentially ASDs); organizations
supporting V2V communications; auto
manufacturers; standards organizations;
PKI experts; State and local government
users, and others. In Figure V–6, below,
the shapes represent different groups of
organizations that interact with the
SCMS in some way. Some of these
organizations will need to be stood up,
while others currently exist today and
will likely expand their operations to
play a role in the SCMS. The
overlapping of shapes represents mutual
reliance in executing operations, and
the arrows represent communication
and the need for inter-organizational
arrangements. The SCMS is the focal
point of the certificate management
industry, as it encompasses the CMEs
that oversee all PKI functions
responsible for establishing the
foundation of security in the V2V/V2I/
V2X system.
E:\FR\FM\12JAP2.SGM
12JAP2
Some of the questions that NHTSA
raised in the V2V Readiness Report
about industry governance structure for
the SCMS include:
• How and by whom are decisions
made about various policies, standards,
requirements, and practices?
• Who has the authority to mandate
and enforce compliance with the
policies, standards, and industry
requirements?
• Who makes up the overseeing
financial, legal, management, and
executive operations of the entities in
the SCMS?
• Is there a central industry body and,
if so, who oversees it? Who is part of
this central industry body?
• How do the various entities interact
with each other?
• How is risk and liability allocated
across the organizations?
• Who will own the intellectual
property (data and software) of the
system and how will it be licensed
(allocated) among responsible entities?
In answering these questions, NHTSA
continues to explore a variety of
governance models (ranging from public
to public-private to private) as potential
options for governing the SCMS
industry. Due primarily to the absence
of Federal funds to support a public
SCMS, to date NHTSA has focused
primarily on fleshing out a model of
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
private SCMS ownership and
governance that assumes costs will be
covered by increases in the purchase
price of new vehicles and V2V safety
devices. As we noted our V2V
Readiness Report, in a private SCMS
industry the organizational structure
and operation of the SCMS would be
determined largely by private owners
and operators of CME components,
under oversight of an SCMS Manager
(ideally an industry-wide coalition of
CME owners and other stakeholder
representatives who, together, agree on
the terms of self-governance and systemwide rules and policies). The SCMS
Manager would provide critical system
management by enforcing and auditing
compliance with uniform technical and
policy standards and guidance systemwide. Uniform standards and guidance
would establish and ensure consistency,
effectiveness, interoperability,
sustainability, and appropriate privacy
protections across the CMEs to facilitate
necessary communications, sharing of
information, and operational
connections, and would be based in
large part on existing technical and
policy standards applicable to PKI
systems.
The Readiness Report explained
NHTSA’s view that, in the context of a
privately owned SCMS ‘‘industry,’’ a
PO 00000
Frm 00097
Fmt 4701
Sfmt 4702
3949
private model could be a viable
mechanism for SCMS governance in
which NHTSA would have only a
minimal role in ensuring system
integrity, largely through its traditional
regulatory activities. We also indicated
that NHTSA’s existing legal authority
would accommodate the use of grants,
cooperative agreements, or other
agreements to facilitate stakeholder—
and even DOT—input into governance
of a private SCMS.
(b) ANPRM Governance Comments
Comments to the ANPRM and
Readiness Report relating to SCMS
ownership and governance came mostly
from members of the automotive
industry and their trade groups. While
agreeing with NHTSA’s assertion that a
V2V system is not complete without a
robust SCMS, almost without exception,
industry commenters vehemently
disagreed that a private self-governing
industry coalition could be a viable
mechanism for SCMS system
governance. Commenters believed that a
private SCMS could not provide the
security, privacy, certainty, stability,
long-term functionality, or management
of costs and risk required for a
nationwide SCMS to support V2V DSRC
communications, and lacked the legal
authority to address cross-border issues
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.015
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
3950
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
or require industry-wide participation
and compliance with uniform
requirements. For these reasons,
virtually all industry commenters took
the position that a strong leadership role
for the Federal government in the SCMS
would be required for successful
deployment of V2V and V2X DSRC
communications.
For example, both the Alliance and
Mercedes described the SCMS as a
‘‘core government responsibility.’’
Noting that ‘‘for V2V to work effectively,
every vehicle manufacturer will have to
participate in the SCMS and abide by its
rules,’’ the Alliance explained that:
srobinson on DSK5SPTVN1PROD with PROPOSALS2
a private organization, such as a voluntary
coalition of manufacturers, cannot compel
unwilling manufacturers to join the
organization, and cannot enforce deviations
from the organization’s rules except by
expelling misbehaving members. There is no
effective mechanism to ensure the universal
participation of all manufacturers and to
compel their obedience to the necessary
common SCMS requirements. . .
The Alliance also stated that
‘‘resolution of policy issues requires
coordination among multiple federal
agencies (FHWA, FTC, FCC, EPA),’’ and
that ‘‘Congress was best positioned to
provide the needed coordination and
nationwide-scope for addressing
infrastructure, governance of networks
and SCMS, consumer privacy,
sustainable funding, international crossborder and liability/IP policy issues.’’
Global commented that ‘‘private
sector options for operating the Security
Credential Management System (SCMS)
do not guarantee certainty over the
management or the cost of operation the
system and its long-term stability.’’ GM,
likening the issuance of security
certificates to the minting of coinage by
the Federal government, argued that
ensuring a secure V2V system would
require that the Federal government: (i)
Operate or support operation of a
central root CA that all V2V certificates
must use, or mandate that all V2V
certificates use a central root CA; and
(ii) review and approve minimum levels
of security for the keys and
cryptography used by the root CA and
subordinate CAs authorized by the root
CA. Mercedes described the SCMS as a
‘‘backbone infrastructure, which must
be set up and controlled with the
leadership of state and federal
authorities’’ and echoed the comments
of the Alliance that only Federal
government oversight would ensure
industry-wide participation in an SCMS
and compliance with its requirements.
Similarly, Honda commented that the
federal government should be
responsible to ensure the safe and
efficient operation of the V2V security
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
framework, and should consider a
public-private partnership as an option
for the operation and management of the
SCMS, with federal oversight,
supervision and funding.
The agency agrees with commenters
that, for a variety of policy reasons,
ideally the Federal government should
play a more central leadership role in
the establishment and governance of a
V2V SCMS. For this reason, as detailed
above, DOT now has taken the lead in
working with SCMS stakeholders to
develop the policies and standards that
should form the basis for governance of
a National V2V SCMS, as well as to
model and prototype organizational
options for a governance entity to
manage SCMS operations.
(c) A Comparative Industry Example:
ICANN
In analyzing SCMS governance
options, NHTSA and its research
partners have investigated a variety of
industries with characteristics similar to
those seen as critical for a V2V SCMS
governance model, including security,
privacy protection, stability,
sustainability, multi-stakeholder
representation and technical
complexity.223 We investigated an array
of public, public-private and private
governance models, with particular
emphasis on safety-critical and privacysensitive systems. We also examined
how risk was managed in the context
these models. Some of the industries
researched included:
• Internet Corporation for Assigned
Names and Numbers (ICANN)
• DTE Energy Company
• Aeronautical Radio Incorporated
(ARINC)
• End of Life Vehicle Solutions
Corporation (ELVS)
• The FAA’s Next Gen Air
Transportation System
• The FRA’s Positive Train Control
• Smart Grid
• The Rail/Transit Train Control
Systems (ATC and CBTC)
• FMCSA’s EOBR
• Coast Guard’s MSSIS
• Army Corp of Engineer’s MRGO
• Medical Devices failure and liability
• Security in nuclear industry and
liability
• Warning/Signal Failures
• UAVs
• HIPAA/Health Care industry/
Electronic Health Records (EHRs)/
CONNECT system
223 VIIC Assessment of Key Governance Policy
Considerations for a Connected Vehicle Cooperative
Safety Communications System,’’ dated March 12,
2013, at page 11 https://www.regulations.gov/
#!documentDetail;D=NHTSA-2014-0022-0046 (last
accessed Dec. 8, 2016).
PO 00000
Frm 00098
Fmt 4701
Sfmt 4702
• Credit Card Payment industry and PCI
standards
• Hospital/Health care industry
Of the governance models we
examined, governance of the internet
naming protocol systems (DNS) by the
Internet Assigned Numbers Authority
(ICANN) possessed numerous
characteristics that seem to translate
most directly to a private or publicprivate governance model for the V2V
SCMS. ICANN is a private, not-for-profit
corporation created by private sector
entities in direct response to efforts by
the Federal government to privatize
certain Internet-related tasks in a
manner that permits robust competition
and international participation in its
management. ICANN is managed by a
multi-stakeholder Board of Directors
(representative of the functional and
geographic diversity of the Internet) that
oversees a number of Internet-related
functions previously performed directly
on behalf of the Federal government by
other organizations, notably the Internet
Assigned Numbers Authority (IANA)
(formerly located within the Department
of Commerce but now operated by
ICANN). Pursuant to various
Memoranda of Understanding with
ICANN (ICANN MOUs), the Department
of Commerce agreed gradually to
transfer to ICANN certain Internetrelated functions, with the goal of
having ICANN carry out operational
responsibility for these functions in a
financially self-sustaining manner after
a limited transition period. At the same
time, the Department of Commerce also
entered into a series of funded project
agreements with ICANN, on a sole
source basis, to perform technical and
policy activities required to facilitate the
transition of authority for those
functions to ICANN.224
The ICANN MOUs and project
agreements called for the Federal
government to exercise significant
oversight of ICANN’s activities until
such time as ICANN was stable and
could provide certain stability,
sustainability and policy assurances to
the Federal government. After 11 years,
the Department of Commerce gave up its
oversight of ICANN with respect to the
operation and governance of specific
Internet naming protocol functions, but
committed to ongoing participation in
ICANN’s Governmental Advisory
Committee (GAC). ICANN continues to
perform certain technical maintenance
tasks under contract to Commerce, as do
other Commerce contractors. In 2014,
224 ICANN background information, contract and
agreement content can be found at https://
www.ntia.doc.gov/page/docicann-agreements (last
accessed Dec. 8, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
Commerce announced its intention to
work with ICANN to privatize key
Internet domain name functions still
remaining under its control.
How is ICANN relevant to governance
of the V2V SCMS? ICANN provides
NHTSA with a potential road map for
how it can work with public and private
stakeholders to develop a successful
governance structure for a multistakeholder, geographically and
functionally diverse technology-intense
system not unlike V2V. Like the V2V
SCMS, successful deployment of an
Internet naming protocol required
uniform and consistent application of
technical and policy standards enabling
interoperability and system-wide
confidence. As would be required for
enforcement in a privately governed
SCMS, ICANN uses a binding Registry
Agreement as the enforcement
mechanism through which it ensures
that its policy and technical standards
are applied Internet-wide. Like the
SCMS ecosystem or ‘‘industry,’’ the
Internet ‘‘industry’’ involves numerous
commercial, academic, geopolitical, and
other private and public stakeholders
involved in a broad range of Internetrelated functions, the success of which
requires system-wide, coordinated
governance. As would be likely in the
SCMS context, ICANN was developed
and operates on a foundation of the
fundamental principles of security,
stability, resiliency, multi-stakeholder
participation, openness, fairness and
robust completion. Additionally, as
detailed in the ICANN MOUs, after a
period of direct government oversight
and funding, the privatized functions
governed and coordinated by ICANN
were designed to be financially selfsufficient (i.e. financed by fees paid for
services).
We agree with Dura and the VIIC that
ICANN’s organizational structure could
translate well to a potential V2V SCMS
governance model. The details of
ICANN’s mission, core values, powers,
responsibilities, governing principles
and procedures are set forth in its
Articles of Incorporation, Bylaws,
Charter, and other publicly available
documents. In accordance with those
documents, ICANN is governed by the
binding decisions of a Board of
Directors, consisting of both voting
Directors and non-voting liaisons. The
voting Directors consist of members
selected by a functionally and regionally
diverse nominating committee that
reflects the diversity of Internet
ecosystem, as a whole: the AddressSupporting Organization (ASO), the
Country-Code Names Supporting
Organization (CCNSO), the Generic
Names Supporting Organization
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
(GNSO), the At-Large Community and
the President ex officio. Directors may
not be officials of countries or
multinational geo-political entities.
Only ICANN’s President can be both a
Director and ICANN employee. Nonvoting liaisons are a means for the Board
to obtain input from world-wide
governments, through the Government
Advisory Committee (GAC), and three
function-specific expert committees, the
Internet Engineering Task force (ETF),
Security and Stability Advisory
Committee (SSAC) and Root Server
System Advisory Committee (RSSAC).
The organization has an Ombudsman
appointed by the Board to act as a
neutral dispute resolution practitioner
and provide an independent internal
evaluation of complaints by members of
the ICANN community who believe that
the ICANN staff, Board or an ICANN
constituent body has treated them
unfairly.
NHTSA also found quite instructive
the procedures used by the Department
of Commerce to effectuate the process of
successfully privatizing certain Internetrelated functions. In July 1997, the
Department of Commerce first
published a Request for Comments on
behalf of an interagency working group
examining the appropriate future role of
the Federal government in the DNS and
other issues related to the
administration of the DNS. The
following year, in early 1998, based on
the 1400 pages of comments it received
to its Request for Comments, it issued a
rulemaking notice proposing certain
actions designed to privatize the
management of Internet names and
addresses in a manner that allowed for
the development of robust competition
and facilitates global participation in
Internet management.225 The proposed
rulemaking addressed a variety of issues
relating to DNS management including
private sector creation of a new not-forprofit corporation (the ‘‘new
corporation’’) managed by a globally
and functionally representative Board of
Directors. The rulemaking proposed,
among other things, the new
corporation’s authorities, detailed the
role of the federal government in policy
oversight during the transition,
identified funding, and contained a
detailed proposed governance structure
(specific to the number of seats on the
Board of Directors) with substantive
stakeholder participation and openness
requirements. The rulemaking
explained that, the new corporation
would:
225 https://www.gpo.gov/fdsys/pkg/FR-1998-02-20/
html/98-4200.htm (last accessed Dec. 8, 2016).
PO 00000
Frm 00099
Fmt 4701
Sfmt 4702
3951
Act much like a standard-setting body. To
the extent that the new corporation operates
in an open and pro-competitive manner, its
actions will withstand antitrust scrutiny. Its
standards should be reasonably based on,
and no broader than necessary to promote its
legitimate coordinating objectives. Under
U.S. law, a standard-setting body can face
antitrust liability if it is dominated by an
economically interested entity, or if
standards are set in secret by a few leading
competitors. But appropriate processes and
structure will minimize the possibility that
the body’s actions will be, or will appear to
a court to be, anti-competitive.226
Later the same year, in July 1998, the
Department of Commerce opted to
proceed with privatizing management of
the internet DNS not through
rulemaking but by issuing a Statement
of Policy expressing the Government’s
intent to ‘‘recognize, by entering into
agreement with, and to seek
international support for, a new, not-forprofit corporation formed by private
sector Internet stakeholders to
administer policy for the Internet name
and address system.’’ 227 In a July 7,
2000 report,228 the GAO confirmed the
appropriateness of the Department of
Commerce’s actions. The GAO
determined, among other things, that:
• Department of Commerce had the
authority to support privatization of the
DNS on the basis of its general
authority 229 to foster, promote, and
develop foreign and domestic commerce
and NTIA’s more specific authority to
coordinate the telecommunications
activities of the executive branch; 230
• The APA notice and comment
requirements did not apply to the
Department of Commerce’s general
statement of policy, as it contained not
substantive regulatory requirements but
a general framework for privatizing the
DNS;
• Establishment of ICANN by the
private sector was not subject to the
Government Corporation Control Act or
various other legal requirements
applicable to entities that are part of or
controlled by the Federal Government;
• Department of Commerce had
authority to enter into the MOUs,
226 https://www.ntia.doc.gov/files/ntia/
publications/022098fedreg.txt, at page 8818 (last
accessed Dec. 8, 2016).
227 See https://www.ntia.doc.gov/federal-registernotice/1998/statement-policy-management-internetnames-and-addresses (last accessed Dec. 8, 2016).
228 See Department of Commerce: Relationship
with the Internet Corporation for Assigned Names
and Numbers, July 7, 2000 (B–284206) https://
www.gao.gov/new.items/og00033r.pdf (last accessed
Dec. 8, 2016).
229 In so doing, GAO noted that ‘‘there is no
explicit legislation requiring the government to
exercise oversight over the domain name system.’’
Id at 3.
230 47 U.S.C. 902(b)(2)(H).
E:\FR\FM\12JAP2.SGM
12JAP2
3952
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
cooperative agreements and sole source
contracts with ICANN based on its
general legal authority to work with and
enter into these types of agreements
with non-profit entities.
It must be noted that the
circumstances that led to creation of
ICANN are different, in significant
respects, than those that now necessitate
the creation of an SCMS to support V2V
DSRC communications. When it issued
its Policy Statement, Department of
Commerce had funds dedicated to
administration of the DNS it sought to
privatize and already had taken on
responsibility for performing that
function, in accordance with Federal
law. For this reason, the Department of
Commerce had a legal obligation closely
to oversee ICANN’s assumption of
responsibility for the DNS during a
transition period. It also continued to
fund ICANN in the performance of
certain additional functions previously
performed by IANA, even after it ceased
to oversee ICANN’s policies and
operation of the DNS in 2009. By
contrast, to date, NHTSA has not
assumed responsibility for carrying out
any security functions relative to
mandated automobile equipment, so no
infrastructure or funding for this
purpose now exists. Additionally,
NHTSA seeks not to privatize existing
federal security functions or
infrastructure, but to work closely with
public and private V2V stakeholders to
take the technical design, intellectual
property and body of policy developed
through DOT’s SCMS research and
facilitate the creation of a new
operational entity—a National SCMS to
support V2V, V2I, and V2X DSRC
communications.
Despite these differences, NHTSA
believes that ICANN serves as a strong
comparative industry model of how
NHTSA can work with stakeholders in
the SCMS ecosystem to facilitate
creation and support of a multistakeholder private sector entity to
govern and coordinate operation of the
V2V SCMS.
(d) Potential SCMS Implementation
Model
It is clear that there are numerous
different paths that government and
private stakeholders theoretically could
follow in implementing a National
SCMS to support the V2V ecosystem—
paths the organization, governance and
financial viability of which DOT expects
its expanded policy research to develop
and assess. There may even be other
viable security models that could
provide sufficient confidence and
consumer privacy protection to V2V
messages. However, if NHTSA mandates
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
V2V communications equipment in
light motor vehicles and moves forward
with implementing the SCMS technical
design described above, the agency
believes that one promising path was
that pursued by Department of
Commerce when it spurred private
sector establishment of ICANN.
Specifically, DOT could facilitate the
creation of a multi-stakeholder entity
capable of governing and coordinating
operation of a National SCMS. DOT’s
expanded policy research, including
stakeholder input, modeling, and
prototyping of potential governance
models, as well as comments on the
NPRM, will help determine whether
such an SCMS should be a purely
private entity in which DOT plays an
advisory role—or whether the Federal
government should assume control over
some critical SCMS functions (for
example, ownership of the definitive
root).
The process followed by the
Department of Commerce as it
privatized certain DNS functions could
be a useful roadmap for how NHTSA
might work with the private sector to
establish a new, multi-stakeholder
entity to take on governance and
coordinate operation of a V2V SCMS.
NHTSA’s 2014 ANPRM, V2V Readiness
Report and SCMS RFI could be viewed
as the first steps in this process. NHTSA
used the input the agency received in
response to these public documents, in
meetings with RFI respondents, and
through SCMS policy research
performed by the VIIC and others, to
expand the scope its planned SCMS
governance and policy research
discussed in Section V.B.6. This critical
SCMS policy research is intended to
give DOT a central role in, and direct
control over, development of draft
policies, procedures and standards that
could the basis for governance of a
National SCMS, including draft a
Certificate Policy, Certificate Practice
Statement, Registration Agreements, and
Privacy Policy. Another central aspect
of DOT’s planned SCMS policy research
will be working with PKI and
organizational consultants and
stakeholders to prototype a multistakeholder governance structure (much
like ICANN’s Board of Directors)
capable of satisfying the needs of the
broad range of diverse participants in
the SCMS ecosystem. If successful, this
prototype could serve as a model for a
private sector entity that could establish
and oversee a deployed National SCMS.
If appropriate based on the
Department’s planned research, DOT
then could issue a draft V2V SCMC
Policy Statement describing a process
(similar to that followed by DOC and
PO 00000
Frm 00100
Fmt 4701
Sfmt 4702
ICANN) by which the Department
could, if it chooses to, work
collaboratively with a new multistakeholder private entity to develop the
binding policies and technical standards
required for stable and sustained
operation of a V2V SCMS. After an
initial period of joint policy
development and direct DOT oversight
under contract, prior to full SCMS
deployment, DOT gradually could
terminate some or all its oversight of the
new entity’s activities, completing the
transition of authority prior to full
SCMS deployment. Thereafter,
representatives of NHTSA and other
Federal government agencies, both
within DOT (DOT–R, FHWA, FMCSA,
and the others) and elsewhere in the
Federal Government (FCC, FTC), could
serve in an advisory capacity on a
Government Advisory Committee or as
nonvoting SCMS Manager Board
Members.
(e) SCMS Proof-of-Concept Operational
Model Development Plan
As a result of a better understanding
obtained from operating the prototype
security system during Model
Deployment, as well as feedback from
the SCMS Request for Information, ITS–
JPO and NHTSA realized that
expanding to a National level SCMS
would require an intermediate step.
Specifically, that additional research
was required to prove the concept and
develop a SCMS working model that
allows for investigating the full range of
technical, policy, and organizational
elements involved in deploying and
operating the SCMS. Investigating these
components includes providing security
certificate management services to
continuing vehicle communications
research activities and early
deployments.
As part of developing a working
SCMS model, DOT will:
• Develop and implement a proof of
concept SCMS (the SCMS PoC) that is
fully representative of the Final SCMS
design, and which will provide
certificate management services to early
deployments and demonstrations,
including but not limited to CV pilots,
• Act as the overall SCMS PoC
Manager, including developing policy
and procedures that will govern the
interactions between the various entities
involved in the V2X eco-system, and
• Based on stakeholder input, will
advanced and adapt SCMS PoC policies
and protocols such that they would
represent possible policies and
protocols suitable for the establishment
and operations of a SCMS that could
support a national deployment of
vehicle communication technology.
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
The SCMS proof-of-concept (PoC) will
be fully representative of a production
SCMS in terms of functionality,
features, and capabilities. It will support
all certificate management ‘‘use-cases’’
envisioned for a production system, and
incorporates all elements of the final
design developed by DOT and its
industry partners. While not intended to
be ‘‘full-scale’’, the SCMS PoC will be
capable of servicing up to 17 million
vehicles annually. The SCMS PoC is
being developed to:
1. Support end-to-end testing of the
certificate management use-cases thus
demonstrating feasibility and
practicality of system;
2. Demonstrate the extensibility of the
SCMS design (multiple non-central
components);
3. Support scalability testing through
modeling, simulation, and real-world
deployments;
4. Support integrity, robustness and
system vulnerability testing;
5. Will be used in actual connected
vehicle operations by servicing a variety
of early deployments and
demonstrations including the
Connected Vehicle pilots (Tampa, NYC,
Wyoming), the Smart City Challenge
program recipient, as well as other
government sponsored (state & local)
and private sector deployments that we
anticipate emerging over the next
several years; and
6. Will be able to support future
connected vehicle application
demonstrations programs for FMCSA,
FTA, and FRA (e.g., wireless roadside
inspections; electronic credentialing;
grade-crossing safety; transit-pedestrian
safety; and other applications).
NHTSA and its industry partners
(CAMP) are currently in the process of
prototyping an SCMS system that is
capable of executing all the core usecases associated with the security
certificate management life cycle
including enrollment, certificate
generation, certificate request and
fulfillment, and revocation. This proofof-concept SCMS (the SCMS PoC) is
being developed to support real-world
operations of early V2V deployments at
connected vehicles pilots sponsored by
DOT (in Florida, New York City, and
Wyoming and elsewhere). NHTSA and
its industry partners will continue to
refine, test and mature the design of the
SCMS—including addressing the
functions and features listed above—by
leveraging this prototype environment.
To support these refinement efforts, we
are establishing multiple instantiations
of the SCMS including Production,
Quality Assurance and Development
environments. Further, we are in the
process of retaining an additional (in
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
addition to MITRE) independent cybersecurity testing and evaluation Team to
conduct a thorough design review on
the Final SCMS design, and to complete
focused penetration testing and
vulnerability discovery on the actual
SCMS prototype by leveraging the
Development environment platform.
DOT will develop, operate, and
manage the SCMS PoC through multiple
contract/agreements with multiple
entities, illustrated via Figure 1. Figure
1 identifies five research activities
including the SCMS PoC Governmental
Management that represent the SCMS
PoC Manager Environment. This
environment depicts the boundaries of
the SCMS PoC Governmental
Management activities. DOT has already
established an agreement that is
currently developing an initial
prototype of the SCMS PoC that will be
the basis for the operational
environment and support ongoing
functional (refinement) development.
SCMS PoC Governmental Management
includes the development of policies
that support the technical processes and
procedures and the organizational
protocols that establish interfaces
(communications) between entities that
support policy and operational
execution. DOT, with the support
provided by the Governmental
Management contractor, will be the
SCMS Manager and set policies and
protocols that will address threats in
relation to access and change authority.
The SCMS Manager will develop and
establish a Certificate Policy and
Certificate Practice Statement that sets
the policies and protocols that must be
accepted and followed to be approved to
participate in the SCMS environment.
A separate agreement will establish
the operational SCMS PoC (provides the
technical functions that enables
generation, distribution and monitoring
of SCMS security materials). Related to
the separate agreement that establishes
PoC operations is an agreement that
provides for the technical management
that encompasses the development and
documentation of technical process and
procedures end entities will use to
initialize devices and obtain security
materials. Another contract will provide
Connected Vehicle Support Service that
supports the initial interactions
regarding end entity applications for
device initiations, technical support
questions, and questions about policies
and procedures. The Connected Vehicle
Support contractor will establish and
operate the initial interface with end
users.
Beyond the SCMS PoC manager
environment, the SCMS PoC
Governmental Manager will in most
PO 00000
Frm 00101
Fmt 4701
Sfmt 4702
3953
cases indirectly interface with other
research activities such as the CV Pilots,
and other support entities that include
Certification Service entities, and
Device Suppliers. The most direct
outside relationship will be with the
National SCMS Prototype Policy
Development research. The SCMS
Governmental Management effort will
need to interface with the National
SCMS Prototype Policy Development
research to support national level SCMS
prototype policy development.
The SCMS PoC environment, together
with the connected vehicle pilot sites
sponsored by DOT, will provide an
opportunity to refine the SCMS Manager
concept and other non-technology
related policies and procedures needed
to address security threats.
(f) SCMS Request for Comment
NHTSA has invested considerable
resources and effort in refining and
maturing the Security Credential
Management System Design. The
Agency has enlisted the assistance of
leading PKI experts in developing the
design, and the design has been
formerly reviewed by MITRE
Corporation (see Section V.B.3 for
summary of MITRE review) and other
Federal Agencies including DARPA and
NIST have also reviewed the design.
NHTSA believes that the SCMS concept
and design offers a practical, efficient
and effective means for addressing the
need for confidence in V2V and V2I
communications—while simultaneously
addressing privacy concerns arising
from potential vehicle tracking using
V2V communications. Nevertheless, a
fully representative prototype of the
SCMS system has not yet been
developed and tested, although NHTSA
and the JPO are in the process of doing
just that, (see Section V.B.6.e) for
details).
In addition, the SCMS concept calls
for periodic (or routine)
communications between the vehicle
and various certificate management
entities (which reside in the
‘‘infrastructure’’ on the internet) to
execute a variety of certificate
management life-cycle services
including: re-provisioning of on-board
pseudonym certificates; distribution of
certificate revocation lists; and potential
a component for sending misbehavior
detection reports from vehicles to the
Misbehavior Authority of the SCMS as
described in the Proposal. While
NHTSA believes that such periodic
vehicle to infrastructure
communications can readily be
accommodated thru either V2V DSRC
communications (using roadside units,
or RSUs), or through the rapidly
E:\FR\FM\12JAP2.SGM
12JAP2
3954
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
to expand its governance role in
development of a viable organizational
model and policies and procedures
applicable to a National SCMS, and the
use of ICANN as a possible roadmap for
how to facilitate establishment of a
private, multi-stakeholder entity to
manage and oversee operation of the
National SCMS.
C. Vehicle Based Security System
(VBSS)
In late 2012 NHTSA began
investigating a certificate management
concept termed the ‘‘vehicle based
security system’’ (VBSS). VBSS is based
on principals associated with Group
Manager concepts for managing
cryptographic materials—and adapted
for vehicular application by NHTSA
engineers.
The major difference between SCMS
and VBSS is in generating short-term
certificates. The SCMS approach relies
on individual vehicles to periodically
request pseudonym certificates from
infrastructure-based entities, (most
notably a Pseudonym Certificate
Authority, or PCA) which in turn
generates and signs short-term
certificates. Vehicles then download
batches of certificates which are used to
digitally sign BSM messages. In
contrast, the VBSS concept calls for
delegating this authority to individual
vehicles, and as a result the
communications with the infrastructure
are reduced.
DOT funded a Feasibility Study of the
VBSS concept in 2014 (completed by
Oakridge National Laboratory, ORNL)
and the first phase of study was
completed in December, 2015.231 Figure
X depicts a high level comparison of the
VBSS and SCMS architectures.
Under the VBSS concept, the
Pseudonym Certificate Authority (PCA),
Registration Authority (RA), Linkage
Authorities (LAs) and Request
Coordination, that are fundamental
components in SCMS, are eliminated.
VBSS establishes a Group Manager/
Group Managers (GM) to provide
credentials that make it possible for
each vehicle to act as a certificate
authority—an entity that can generate
short-term certificates.
Each vehicle is a member of a group
and is assigned a unique membership
secret, a signing key. All member
signing keys for a particular group are
associated with a single group
certificate. A vehicle generates its own
ephemeral pseudonym certificates by
signing the public key from a selfgenerated key pair with its group
signing key; vehicles act as subordinate
Certificate Authorities and pseudonyms
are generated on demand based on
travel requirements. Pseudonym
verifiers use the group certificate to
authenticate the pseudonym certificate,
231 ‘‘Vehicle Based Safety Systems: A Feasibility
Study: December 23, 2015, ORNL.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00102
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.016
srobinson on DSK5SPTVN1PROD with PROPOSALS2
increasing connectivity of vehicles
using commercial wireless services
(cellular or satellite services that are
either integrated into vehicle or made
available through links with an
operator’s cell phone), NHTSA
nevertheless recognizes that security
certificate management concepts that
inherently minimize the need for such
periodic V2I communications may offer
advantages relative to maintaining
proper on-board certificate credentials.
To manage the normal risk associated
with any new and complex information
security system, and to address a means
for potentially reducing the need for V2I
security communications, NHTSA has
been, and continues to investigate
alternatives to the SCMS concept.
NHTSA seeks comments on all
aspects of the SCMS. In technical
design, development, and potential
deployment, including DOT’s proposal
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
and then the pseudonym certificate to
verify safety messages. The pseudonym
generator remains anonymous, since the
receiver uses a single group certificate to
authenticate signatures made by all
members from a particular group.
Groups are managed by one or more
infrastructure-based authorities.
Members may be removed from groups
by distributing information that allows
participants to update their group
credentials; this provides a means to
revoke misbehaving vehicles since the
pseudonyms they create will no longer
be authenticated by vehicles that have
updated their group credentials.
Use of pseudonyms (short-lived
identifiers) and separation of distributed
identifiers are the primary means of
achieving an acceptable level of privacy.
Within a VBSS, how groups are
designed will also affect the
preservation of individual privacy. As
the number of distinct groups increases
within a geographical area, privacy
protection decreases; if every vehicle
within a geographic area were in its own
group (the extreme case); the group
identifier becomes a unique vehicle
identifier. This situation can be
mitigated by ensuring group diversity is
minimized regionally.
Misbehavior detection and reporting,
and revocation are maintenance
operations that are common to both
SCMS and VBSS. There are misbehavior
reporting alternatives discussed in
SCMS security section of this proposal.
In relation to misbehavior and
revocation, VBSS may offer some
advantages relative to managing
communications associated with
revoked vehicles. With SCMS, as the
number of revoked vehicles grows—
including those vehicles revoked
because they are at the end of their
useful life, the CRL list must also grow.
NHTSA and its industry partners are
investigating mechanisms for managing
the size the CRL but nevertheless
remains a challenge. With VBSS,
instead of sending out CRLs to revoke
vehicles, a Group Broadcast (GB)
distributes group credential updates to
participating vehicles; this occurs when
a sufficient number of vehicle
misbehavior reports have been validated
resulting in one or more revocations;
otherwise, group credentials do not
change. With comparison to the SCMS
using CRL list to remove compromised
devices from the V2V communication
system, the size of CRL will increase
with the number of compromised
devices, VBSS revocation mechanism’s
advantage is that the size of group
credential updates will not increase
with the number of compromised
devices.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
The Phase I study of VBSS and
comparisons with other approaches
suggests VBSS is feasible because groupbased credentials provide a means to
delegate infrastructure-based operations
to vehicles in an effective way while
facilitating the basic requirements of
authentication, privacy, and
maintenance of confidence. However,
while Group-based signature schemes
are an active area of research they are
evolving and much less mature than
other cryptographic systems. For this
reason, VBSS remains in its preliminary
stages.
NHTSA is continuing its research of
the VBSS concept and is beginning a
Phase II research Study in 2016. This
work will focus on modeling a Group
Manager and enhancing our
understanding of the Group Manager
software engineering requirements.
NHTSA seeks comment on the viability
of the VBSS certificate management
approach including potential
advantages and disadvantages relative to
the SCMS approach. Specifically, we
seek comment on the following:
—Could requirements to update an
entire group’s credentials (to enable
revocation of selected vehicles)
actually increase V2I communications
during early deployment (versus
distribution of a CRL)?
—Are there CRL distribution schemes
that could limit, or otherwise manage,
the growth of the CRL—particular as
vehicles reach the end of their life and
are place on the CRL?
—How will requirement to self-generate
short-term certificates onboard the
vehicle impact processing and
memory requirements onboard the
vehicle—as well as the need to
provide high integrity hardware
security modules to support such
operations?
D. Multiple Root Authority Credential
Management
U.S. DOT research, performed in
partnership with European, Australian,
and Japanese partners, has recognized
that the world will evolve into a multiroot world and that crypto-agility will
be a required capability as a response to
increasing cybersecurity attacks.232
While these capabilities are not
required at the initiation of a connected,
cooperative environment, they are
useful technical and policy constructs to
incorporate as the threat profile shifts
and as the operational environment
grows.
232 This work and its outcomes are described at:
https://ec.europa.eu/digital-single-market/news/
harmonized-security-policies-cooperativeintelligent-transport-systems-create-international.
PO 00000
Frm 00103
Fmt 4701
Sfmt 4702
3955
There are three potential paths to
consider, all with advantages and
disadvantages (we further note that
these paths are not exclusive and that as
the technologies evolve, they may
converge):
(1) There is the path of establishing a
single chain to the Root Authority that
allows for devices/equipment or
operational entities to become enrolled
and implicitly trusted by the system. In
such a system:
a. The Root Authority requires a
significant level of security to ensure
that it is not comprised.
b. The root authority can authorize
intermediate certificate authorities
which can support a diversity of
operational parameters. However, all
intermediate certificate authorities
under a single root authority must
operate with the allowable policies of
the root authority.
c. There is a requirement for a
mechanism to manage root authorities
which is capable of transitioning the
fundamental cryptographic elements if
the Root Authority is compromised.
This mechanism must be similarly as
highly secured as the root authority and
has the ability to revoke the
compromised root and add a new root
in a controlled and efficient way for all
participants in the security system.233
While allowing for some diversity of
operational usage within the policies of
the root, there is a minimum of
interfaces between the root and other
nodes, consequently, the threat surface
remains smaller.
d. The mechanism for managing the
root, although requiring (and incurring
costs for) a high level of security, allows
for orderly migration of the security
system to incorporate root replacements
and cryptographic improvements (as
long as the devices within the system
are capable of adopting such new
cryptographic processes), thus futureproofing the overall system to the extent
possible within known parameters.
This is the path that the US is taking
to establish initial operations to support
emerging connected vehicle
environments.
(2) There is the path of establishing
multiple, co-existing roots in which
each Root Authority must have an
agreement with other root authorities
that describe an appropriate level of
trust. Based on the trust level, a host of
interfaces have to be enacted for data
transfer that assures one operational
root that the other operational root
remains trusted. See the report titled,
233 See Root Elector System Design at https://
www.mycreativeregistry.net/IPCOM/000245336 (last
accessed Dec 4, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3956
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
‘‘Cooperative-ITS Credential
Management System Functional
Analysis and Recommendations for
Harmonization Document HTG6–4
Version: 2015–09’’ 234 for greater details
on the trust levels and how to enact the
trust levels from both a policy
perspective as well as a data flow
perspective.
A benefit to this path is that with
multiple operational roots, if one is
compromised, another root could
potentially take over operations
(although this is highly dependent upon
the trust levels—if the other operating
root that has to take over does not trust
the credentials of the compromised root
(even if the credentials in use are still
valid and not compromised), then all
actors enrolled in the compromised root
will have to cease operations of the
cooperative applications until they can
be proven to be trusted actors and
enrolled in the uncompromised root
authority).
Understanding the different trust
levels is the key to understanding
whether there are benefits to a multiple
root world. A key conclusion to the
analysis on how to enact different trust
levels is that adding even one additional
root to the system increases the number
of interfaces among entities which
exponentially increases the attack
surface of the inter-related systems. This
model also increases costs of running
different organizations, increases the
costs associated with data analysis, and
increases the costs of auditing and
updating policies. In addition, it seems
that agreement of common security
policies under the initialization of
parallel operational roots, operated by
different organizations with different
priorities, is likely to be very difficult,
adversely affecting the level of trust that
may be established among various root
authorities.
Furthermore the Government will
have no authority to compel one Root
Authority to interface with another Root
Authority. This would adversely affect
interoperability given the equipment
under the different roots would not
interact in crash avoidance situations
reducing the effectiveness of V2V. For
example a group of OEMs could be
covered under one Root Authority were
as a group of aftermarket suppliers
could be covered under a different Root
Authority. If the OEM group decides
that the aftermarket devices do not meet
the OEM level of performance then no
agreement would be implemented and
equipment in the OEM group would not
interact with equipment in the
234 https://ec.europa.eu/newsroom/dae/
document.cfm?action=display&doc_id=11398.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
aftermarket group. This could create
market disparity and reduce consumer
choice.
(3) There is one additional path that
is very similar to path #2, but also
incorporates the use of different types of
security credentials (or security
certificates). The use of the NIST
elliptical curve SHA–256 offers a
significant advantage over other types of
credentials in that it includes the lowest
amount of overhead for an appropriate
level of trust and authentication among
vehicle moving at very high speeds.
This version of the model would
allow for different credentials (such as
‘‘brainpool’’ or other curves) to also be
used in operations. This version of the
model significantly increases the
complexity of the system. While it offers
greater crypto-flexibility, having the
ability to recognize and use different
credentials will require that ALL
equipment/devices/applications will
have to be able to recognize and trust
messages created with either type of
credential in order to ensure continued
interoperability. This path may increase
the cost and complexity of equipment
on the vehicle and/or change the nature
of the equipment, as the receivers will
have to recognize the different
cryptographic technologies and perform
additional/different validity checks for
the different cryptographic technologies.
Also, this capability/path is not yet
proven and would need to be
demonstrated under a number of
conditions to ensure that the
transactions and timing can still meet
the safety applications requirements for
latency of the exchange and scalability
of the dedicated spectrum available for
low-latency communications, such as
the V2V Basic Safety Message.
This is the path that is under
consideration within the European
Union at this time.
All of these paths are, in some sense,
multi-root in that it is necessary to have
at least a back-up root as part of an
internal system. The analysis of the
different paths highlights some of the
key issues that will need to be
addressed as the future evolves:
• Security credentials: At some point,
we can expect that the security
credentials based upon the current
cryptographic level will be broken due
to quantum computing and that new
security approaches and/or new
cryptographic curves will be needed.
Research is needed into new curves to
ensure that new security approaches do
not significantly increase the
communications overhead in order
support the latency requirements for
V2V communications.
PO 00000
Frm 00104
Fmt 4701
Sfmt 4702
• Governance/Certificate Policies:
New root management and recovery
solutions will need to be developed as
the initial, smaller connected vehicle
environments evolve into more
complicated, region-wide, overlapping
environments that may operate at
different levels of security. This has
been addressed in the first path through
the innovative creation of Root Electors
that provide the ability to revoke a
compromise Root and establish a new
Root without having to re-initialize
devices.235
VI. What is the agency’s legal authority
to regulate V2V devices, and how is this
proposal consistent with that authority?
A. What can NHTSA regulate under the
Vehicle Safety Act?
NHTSA has broad statutory authority
to regulate motor vehicles and items of
motor vehicle equipment under the
National Traffic and Motor Vehicle
Safety Act (the ‘‘Safety Act’’).236 As
applied in this context, the agency’s
authority includes all or nearly all
aspects of a V2V system. Congress
enacted the Safety Act in 1966 with the
purpose of reducing motor vehicle
crashes and deaths and injuries that
occur as a result of motor vehicle
crashes and non-operational safety
hazards attributable to motor
vehicles.237 The Safety Act, as amended,
is now codified at 49 U.S.C. 30101 et
seq.
The vehicle technologies that enable
vehicles to send messages to and receive
messages from each other are vastly
different from those that existed when
the Safety Act was enacted. Then, the
vehicle operating systems were largely
mechanical and controlled by the driver
via mechanical inputs and linkages.
Components and systems were either
designed into the vehicle at the time of
original manufacture or were later
235 See Root Elector System Design at https://
www.mycreativeregistry.net/IPCOM/000245336 (last
accessed Dec. 4, 2016).
236 For more discussion and analysis of NHTSA’s
authority to regulate advanced crash avoidance
technologies, including V2V technologies, under
the Safety Act, see the Potential Regulatory
Challenges of Increasingly Autonomous Vehicles,
52 Santa Clara L. Rev. 1423 (Wood et al., 2012) at
https://digitalcommons.law.scu.edu/lawreview/
vol52/iss4/9/ (last accessed Dec. 6, 2016).
For example, the agency’s authority to address
the privacy and security of vehicle data associated
with the operation of those technologies is
discussed at length. Id., at pp. 1448, 1465–72.
Addressing data security is necessary to safeguard
the effectiveness of these technologies and promote
their acceptance by vehicle users. Addressing
privacy is similarly necessary to promote public
acceptance. The views expressed in that article
fairly encompass the agency’s views of its
regulatory authority.
237 H.R. Rep. No. 89–1776, at 10 (1966).
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
attached to or physically carried into the
vehicle. Sensing of a vehicle’s
performance and the roadway
environment was done solely by the
driver.
Today, in contrast, an increasing
number of vehicle functions are
electronic. These functions can be
activated and controlled automatically
and do not necessarily require driver
involvement, unlike the mechanical
functions of previous generations of
vehicles. V2V technologies require no
driver involvement in order to send and
receive information that can be used for
vehicle safety functions. Other ways in
which V2V technologies differ from the
mechanical technologies prevalent
when the Safety Act was first enacted
include the fact that how they operate
can be substantially altered by postmanufacture software updates, and that
advances in communications
technology make it possible for nomadic
devices with vehicle-related
applications to be brought into the
vehicle.
The language of the Safety Act,
however, is broad enough to
comfortably accommodate this
evolution in vehicle technologies.
NHTSA’s statutory authority over motor
vehicles and motor vehicle equipment
would allow the agency to establish
safety standards applicable both to
vehicles that are originally
manufactured with V2V
communications devices, and to those
devices added after original
manufacture.
In the Safety Act, ‘‘motor vehicle’’ is
defined as a ‘‘vehicle driven or drawn
by mechanical power and manufactured
primarily for use’’ on public roads.238
The definition of ‘‘motor vehicle
equipment,’’ as cited below, is broader
and thus effectively establishes the limit
of the agency’s authority under the
Safety Act:
(A) Any system, part, or component of
a motor vehicle as originally
manufactured;
(B) any similar part or component
manufactured or sold for replacement or
improvement of a system, part, or
component, or as an accessory or
addition to a motor vehicle; or
(C) any device or an article or apparel,
including a motorcycle helmet and
excluding medicine or eyeglasses
prescribed by a licensed practitioner,
that—
(i) is not a system, part, or component
of a motor vehicle; and
(ii) is manufactured, sold, delivered,
or offered to be sold for use on public
streets, roads, and highways with the
238 49
U.S.C. 30102(a)(6).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
apparent purpose of safeguarding users
of motor vehicles against risk of
accident, injury, or death.239
NHTSA’s authority over these groups
of items—(1) systems, parts, and
components installed or included in a
vehicle, (2) replacements and
improvements to those systems, parts,
and components, (3) accessories and
additions to motor vehicles, and (4)
devices or articles with an apparent
safety-related purpose—is very broad.
The status of these items as motor
vehicle equipment does not depend on
the type of technology or its mode of
control (mechanical or electronic), or
whether an item is tangible or
intangible. The transition from
mechanical to electromechanical
systems has thus had no effect on the
extent of NHTSA’s authority over motor
vehicle performance. NHTSA has
regulatory authority under the Safety
Act over all the systems, parts, and
components installed on new motor
vehicles, even as motor vehicle control
systems become increasingly electronic,
and perhaps increasingly automated, in
the future.
Put in the context of V2V-related
motor vehicle equipment, NHTSA
considers the following items subject to
the agency’s regulatory authority:
(1) Any integrated original equipment
(OE) used for V2V communications or
safety applications reliant on V2V
communications.
(2) Any integrated aftermarket
equipment used for V2V
communications or safety applications
reliant on V2V communications, under
30102(a)(7)(B), if the equipment
‘‘improves’’ an already-existing function
of the vehicle or is an ‘‘addition’’ to the
vehicle.
239 Section 30102(a)(7)(C); MAP–21, Public Law
112–141, sec. 31201, 126 Stat. 405. Congress added
subparagraph (C) to the statutory definition of
‘‘motor vehicle equipment’’ in 1970 when it
amended the definition in order to clarify the
Department’s authority over additional objects such
as motorcycle helmets. See S. Rep. No. 91–559, at
5 (1970). However, Congress did not seek to limit
the extension of the Department’s authority only to
motorcycle helmets and instead utilized the broad
terms ‘‘device, article, and apparel’’ to describe the
universe of objects that are within the agency’s
authority. See id. Acknowledging the concerns of
those who authored the House version of the
amendatory language that utilizing the terms
‘‘device, article, and apparel’’ might unduly extend
the Department’s authority to objects that have only
a tangential relation to motor vehicle safety, the
conference committee added a use restriction. See
id. Congress relaxed this use restriction in the
statutory definition of ‘‘motor vehicle equipment’’
as part of the amendments to the Safety Act in
MAP–21. See MAP–21, Public Law 112–141, sec.
31201, 126 Stat. 405. Thus, the Department’s
regulatory authority under subparagraph (C) is
limited to those devices, articles, or apparel that are
used for ‘‘the apparent purpose of safeguarding
users of motor vehicles against risk of accident,
injury, or death.’’ See id. (Emphasis added.)
PO 00000
Frm 00105
Fmt 4701
Sfmt 4702
3957
(3) Some non-integrated aftermarket
equipment, depending on its nature and
apparent purpose, under 30102(a)(7)(B),
if the equipment is a motor vehicle
‘‘accessory’’ (something to be used
while the vehicle is in operation, that
enhances that operation), or
30102(a)(7)(C), if the equipment is a
device used for the apparent purpose of
traffic safety (purpose would be clearly
observable from the characteristics of
the object and the context of its use,
rather than necessarily defined by the
manufacturer’s intent for the
equipment).
(4) Software that provides or aids V2V
functions, and software updates to all of
this equipment, because, under
30102(a)(7)(B), updates can be
considered as replacements or
improvements.
(5) Potentially some roadside
infrastructure (V2I), under
30102(a)(7)(B) and (C), because if its
apparent purpose is safety, it may be an
‘‘accessory’’ or a ‘‘device . . .
manufactured . . . with the apparent
purpose of safeguarding users of motor
vehicles against accident, injury, or
death.’’ We currently anticipate that
only a small subset of roadside
infrastructure may fall within this
category.
A number of commenters to the
ANPRM and Readiness Report raised
issues with the agency’s discussion of
the bounds of its authority. While most
commenters agreed that the agency has
clear authority to require V2V
communications devices in new
vehicles and to regulate aftermarket V2V
devices,240 the Alliance argued that it
appeared that the agency sought to
regulate ‘‘the relationship between the
vehicle manufacturers and their
customers,’’ 241 given that NHTSA had
discussed the potential need for
additional security certificates during a
V2V communications device’s lifetime,
as well as the possibility of software
updates as needed. The Alliance argued
that the Safety Act did not authorize a
‘‘lifetime maintenance mandate’’ to
cover the potential need to provide
additional certificates or software
updates.242 Moreover, the Alliance
argued, NHTSA could not require
consumers to renew security certificates
or accept downloaded certificates
pushed directly to the vehicle, or to
ensure that DSRC remained operable
over the lifetime of the vehicle, and
therefore a FMVSS would not be
publicly accepted, and therefore
inconsistent with the agency’s authority
240 Alliance,
at 13, 15.
at 7.
242 Alliance, at 15.
241 Alliance,
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3958
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
under the Safety Act, because
consumers might not be confident that
DSRC would continue to work properly
over the vehicle’s lifetime.243 The
Alliance even suggested that it could
violate the Computer Fraud and Abuse
Act (18 U.S.C. 1030) to push new
certificates to consumers without their
consent.244
In response, NHTSA agrees that we
have authority under the Safety Act to
require V2V communications devices in
new vehicles and mandate specific
aspects of their performance, and to
require similar performance from
aftermarket V2V devices designed to
participate in the V2V system, as long
as those standards are consistent with
Safety Act requirements.
We disagree, however, with the points
raised by the Alliance regarding
certificate and software updates. At this
time, NHTSA is not requiring that
certificate and software updates be
pushed to vehicles without consumers’
consent—we are simply requiring that
manufacturers alert consumers, via a
telltale or message center indicator, to
the fact that V2V will not work if they
are out of certificates or in need of some
other kind of update, and that devices
be capable of receiving such updates.245
Consumers will need to know what
action the telltale or message center
indicator is telling them to take in order
to continue to obtain the safety benefits
of V2V, so vehicle or device
manufacturers will need to ensure either
that the message center indicator is clear
about the needed action and the
consequences of not taking that action,
or that the explanation for the message
or telltale is contained somewhere (like
the owner’s information) where the
consumer can easily find it and
understand what to do. Alternatively,
vehicle manufacturers could obtain
consumer consent for automatic
certificate and software updates at the
time of first sale, although that consent
would not cover subsequent vehicle
owners. Even if manufacturers make it
necessary for consumers to consent to
each new download, NHTSA expects
that the need to do so would be
sufficiently infrequent and wellexplained by vehicle manufacturers in
order to ensure that consumers
recognize the significant safety risk of
failing to accept the download. We
assume that, at this point in time, nearly
all consumers are already wellaccustomed to the need for software
updates on their electronic devices, like
computers and smartphones, and
243 Id,
and at 15, 47–48.
at 15.
245 See Section III.E.13, above.
246 Alliance,
at 7, 16.
in general; TIA at 6; CEA at 2–9; Wi-Fi
Alliance at 7.
244 Alliance,
VerDate Sep<11>2014
23:49 Jan 11, 2017
regularly accept and initiate such
updates. We seek comment from
manufacturers on how they plan to
develop succinct and compelling
explanations to accompany these
consent requests that would encourage
consumers to accept the updates in a
timely manner. We also seek additional
comment regarding all aspects of
consumer consent.
Alternatively, if manufacturers are
concerned that consumers would not
accept new certificate downloads and
would thereby lose the safety benefits of
V2V communications, manufacturers
could install V2V devices that are preloaded with all the certificates that the
device would need over its lifetime.
This approach would presumably
necessitate more storage capacity on the
V2V device (and thus more cost), and
could also present a potentially bigger
security risk if the device were
somehow compromised. We seek
comment on whether requiring devices
to come pre-loaded with a lifetime’s
worth of certificates could be a better
approach than requiring consumers to
consent to (and obtain) new downloads,
and if so, why.
Besides certificates, however, we
expect that software associated with
both the V2V communications device
itself, and with any accompanying
applications that rely on V2V
communications for information, would
likely need updating during the
vehicle’s lifetime. As explained above,
as for certificate updates, we are
proposing to require that manufacturers
include a means to communicate to the
driver if and when a software update is
needed. If the driver then chooses not to
accept the update, the system must
continue to warn them that V2V
functionality is not available. If
manufacturers choose not to update
software when issues with it are
discovered, and safety problems result,
NHTSA may choose to pursue those
problems under its enforcement
authority.
Some commenters disagreed with the
agency’s statements in the Readiness
Report that our Safety Act authority
extended to cover RSE.246 The Alliance
argued that RSE only indirectly served
a safety purpose, because they would
perform non-safety functions as well,
and therefore could not be motor
vehicle equipment. CTIA and others
presented a similar argument regarding
the agency’s authority to regulate mobile
devices and applications for mobile
devices, as it has elsewhere.247
247 CTIA
Jkt 241001
PO 00000
Frm 00106
Fmt 4701
Sfmt 4702
With regard to the agency’s authority
under the Safety Act over RSE, although
we are not proposing in this NPRM to
regulate any RSEs, we disagree that a
device that performs non-safety
functions in addition to safety functions
is necessarily not motor vehicle
equipment. Tires, for example, perform
the non-safety function of helping a
vehicle travel down the road by creating
friction between the wheel and the road,
but that friction also plays a safety role
by helping the vehicle stop rapidly
when the driver hits the brakes. Brakes
and steering wheels, for that matter,
help drivers execute turns which may
be necessary to reach their intended
destination, but they also help drivers
avoid crashing their vehicles. Many
items of motor vehicle equipment that
NHTSA regulates perform safety
functions in addition to being generally
necessary for the driving task. NHTSA
can regulate those items insofar as they
affect vehicle safety. By providing a link
between the SCMS and the vehicle, and
potentially being the mechanism by
which the vehicle’s V2V
communications device is able to obtain
new security certificates and
information about which other vehicles
to trust and not to trust, the RSE may
play a vital role in creating the
environment needed for safety. A BSM
cannot be sent without a certificate, and
a V2V communications device must not
trust an untrustworthy partner vehicle,
or safety applications may not function
properly.
That said, NHTSA does not currently
anticipate the need to specify
requirements for the RSE that may
participate in the overall V2V system.
We note that FHWA has already issued
specifications for roadside units that are
publicly available,248 and at this point,
we would expect the ones participating
in the overall V2V system and
interacting with V2V-equipped vehicles
to conform to these specifications, or to
updated specifications if and when they
exist. We seek comment on whether
additional regulation of RSE/RSU by
NHTSA might be important to ensure
that, among other things, they do not
collect information that could be
unnecessarily harmful to privacy; pose
no cybersecurity threat to the overall
V2V system; or perform (or risk failing
to perform) any other task that could be
harmful to vehicles or the V2V system
248 U.S. DOT Federal Highway Administration,
‘‘DSRC Roadside Unit (RSU) Specifications
Document, Version 4.0, April 15, 2014.’’ Available
at https://docplayer.net/11087167-Dsrc-roadsideunit-rsu-specifications-document.html (last
accessed Dec. 6, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
or in any way negatively impact safety
benefits associated with V2V.
Thus, the agency believes that our
existing Safety Act authority
comfortably allows us to require V2V
communications devices in new motor
vehicles and aftermarket equipment.
The following section examines what
the Safety Act requires NHTSA to
consider in developing an FMVSS, and
how the proposal in this NPRM may
meet those requirements.
B. What does the Vehicle Safety Act
allow and require of NHTSA in issuing
a new FMVSS, and how is the proposal
consistent with those requirements?
Under the Safety Act, NHTSA’s motor
vehicle safety standards are generally
performance-oriented.249 Further, the
standards are required to be practicable
and objective, and to meet the need for
safety.250 The following paragraphs will
discuss briefly the meaning of each of
these requirements, and then explore
how the agency believes that the
proposal may meet those requirements.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
1. ‘‘Performance-Oriented’’
In the Safety Act, the Secretary is
directed to issue motor vehicle safety
standards. ‘‘Motor vehicle safety
standards’’ are defined as ‘‘minimum
standard[s] for motor vehicle or motor
vehicle equipment performance.’’ 251
One point to note at the outset is the
party of whom performance is required:
NHTSA’s safety standards apply to
manufacturers of new motor vehicles
and motor vehicle equipment. It
therefore falls to those
‘‘manufacturers’’—from vehicle OEMs
to OE suppliers to aftermarket device
manufacturers to creators of V2V safety
applications—to certify compliance
with any safety standards established by
NHTSA, and to conduct recalls and
remedy defects if NHTSA finds them.252
249 49 U.S.C. 30102(a)(8) (defining ‘‘motor vehicle
safety’’ as ‘‘the performance of a motor vehicle . . .
in a way that protects the public against
unreasonable risk of accidents occurring because of
the design, construction, or performance of a motor
vehicle’’); and sec. 30102(a)(9) (defining ‘‘motor
vehicle safety standard’’ as ‘‘a minimum standard
for motor vehicle or motor vehicle equipment
performance’’). See also: S. Rep. No. 89–1301, at
2713–14 (1966) (stating that motor vehicle
standards issued by NHTSA should specify a
minimum level of safety performance).
250 49 U.S.C. 30111(a) (establishing requirements
for NHTSA to follow when issuing motor vehicle
safety standards).
251 Id.; See also: Sec. 30102(a)(9) (emphasis
added).
252 49 U.S.C. 30115(a), ‘‘Certification of
compliance; In general’’; sec. 30116, ‘‘Defects and
noncompliance found before sale to purchaser’’;
sec. 30117(a), ‘‘Providing information to, and
maintaining records on, purchasers; Providing
information and notice’’; sec. 30118, ‘‘Notification
of defects and noncompliance’’; sec. 30119,
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
Vehicle owners are not required to
comply with NHTSA’s safety standards,
which means that for vehicles already
on the roads, participation in the V2V
system would be entirely voluntary:
NHTSA can regulate how aftermarket
devices function, but it cannot require
manufacturers or drivers to add them to
used vehicles. The one exception to this
rule against retrofit is that NHTSA has
authority to require retrofit of
commercial heavy-duty vehicles,253 but
that is not part of this proposal on lightduty vehicles.
While NHTSA is directed to establish
performance standards, the case law and
the legislative history indicate that
when necessary to promote safety,
NHTSA can be quite specific in drafting
its performance standards and may
require or preclude the installation of
certain equipment. The cases have
reinforced this concept by determining
that NHTSA is ‘‘generally charged’’ 254
with setting performance standards,
instead of becoming directly involved in
questions of design.255 The legislative
history further illustrates that NHTSA’s
standards are to ‘‘[specify] the required
minimum safe performance of vehicles
but not the manner in which the
manufacturer is to achieve the specified
performance.’’ 256 An example cited in
the legislative history points to ‘‘a
building code which specifies the
minimum load-carrying characteristics
of the structural members of a building
wall, but leaves the builder free to
choose his own materials and
design.’’ 257 In that example, the agency
could require the wall to be built
(analogous to requiring certain
equipment in vehicles) but would be
expected to measure the wall’s
regulatory compliance by its
performance rather than its design.
Although the Safety Act directs
NHTSA to issue performance standards,
however, Congress understood that the
agency may preclude certain designs
through these performance standards.
‘‘Motor vehicle safety’’ is defined in the
Safety Act as the performance of a motor
vehicle in a way that protects the public
from unreasonable risks of accident due
to (among other things) the design of a
motor vehicle.258 The legislative history
indicates that this language is not
intended to afford the agency the
authority to promulgate design
standards, ‘‘but merely to clarify that the
public is to be protected from inherently
dangerous designs which conflict with
the concept of motor vehicle safety.’’ 259
This clarification is evidence that
Congress recognized that performance
standards inevitably have an impact on
the design of a motor vehicle.260
The courts have further elaborated on
the framework established by Congress
and have recognized that, when
necessary to achieve a safety purpose,
NHTSA can be quite specific in
establishing performance standards
even if certain designs will be
precluded. For example, the Sixth
Circuit found that an agency provision
permitting rectangular headlamps, but
only if they were of certain specified
dimensions, was not an invalid design
restriction and ‘‘serve[d] to ensure
proper headlamp performance,’’
reasoning that ‘‘the overall safety and
reliability of a headlamp system
depends to a certain extent upon the
wide availability of replacement lamps,
which in turn depends upon
standardization.’’ 261 Thus, the court
found it permissible for the agency to
establish very specific requirements for
headlamps even though it would restrict
design flexibility.262
Further, the cases indicate that
NHTSA can establish standards to
require the installation of certain
specific equipment on vehicles and
establish performance standards for that
equipment. For example, the Tenth
Circuit found in Washington v. DOT
that ‘‘NHTSA’s regulatory authority
extends beyond the performance of
motor vehicles per se, to particular
items of equipment.’’ 263 In that case, the
validity of NHTSA’s FMVSS No. 121
requiring ABS systems on air-braked
vehicles was challenged as ‘‘imposing
design specifications rather than
258 Sec.
30102(a)(9).
Rep. No. 89–1919, at 2732 (1966).
260 Courts have also recognized this fact. See
Chrysler Corp. v. Dept. of Transp., 515 F.2d 1053,
1058–59 (6th Cir. 1975); see also: Washington, 84
F.3d at 1224 (stating ‘‘the performance-design
distinction is much easier to state in the abstract
than to apply definitively-so. . . . This is
particularly true when, due to contingent
relationships between performance requirements
and design options, specification of the former
effectively entails, or severely constrains, the
latter.’’).
261 Chrysler Corp., 515 F.2d at 1058–59.
262 Id.
263 Washington, 84 F.3d at 1222, 1225 (citations
omitted).
259 H.R.
‘‘Notification procedures’’; sec. 30120, ‘‘Remedies
for defects and noncompliance.’’
253 Per 49 CFR 1.95, which delegates to NHTSA
the Secretary’s authority under Sec. 101(f) of the
Motor Carrier Safety Improvement Act of 1999 (Pub.
L. 106–159; Dec. 9, 1999) to promulgate safety
standards for ‘‘commercial motor vehicles and
equipment subsequent to initial manufacture.’’
NHTSA’s retrofit authority is coextensive with
FMCSA’s.
254 Washington v. Dept. of Transp., 84 F.3d 1222,
1224 (10th Cir. 1996) (citations omitted).
255 Id. at 1224 (citations omitted).
256 S. Rep. No. 89–1301, at 2713–14 (1966).
257 Id.
PO 00000
Frm 00107
Fmt 4701
Sfmt 4702
3959
E:\FR\FM\12JAP2.SGM
12JAP2
3960
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
performance criteria.’’ 264 The court’s
conclusion was based not only on the
fact that prior courts had upheld
NHTSA’s standards requiring particular
equipment,265 but also on the fact that
Congress had recognized NHTSA’s
former rulemakings and left NHTSA’s
authority unchanged when it codified
the Safety Act in 1994.
Thus, in summary, NHTSA is
required to issue performance standards
when regulating motor vehicles and
motor vehicle equipment. However,
NHTSA is able to be quite specific in
establishing performance standards and
may preclude certain designs that are
contrary to the interests of safety.
Further, NHTSA may require the
installation of certain equipment and
establish performance standards for that
equipment.
As Section III.E discusses at length
and as the regulatory text at the end of
this preamble discusses at length,
NHTSA has developed a set of proposed
performance requirements for DSRC
performance. These sections explain: (1)
What information needs to be sent to the
surrounding vehicles; (2) how the
vehicle needs to send that information;
(3) how a vehicle shows that it is a valid
source of information; and (4) how a
vehicle makes sure the prior three
functions work in various operational
conditions (i.e., broadcast under
congested conditions, detect/report
misbehavior, and obtain new security
materials). The proposal draws from
existing voluntary standards while also
explaining why a particular threshold or
requirements from a voluntary standard
is appropriate. The proposal contains a
mandatory Privacy Statement, set forth
in Appendix A. Finally, the proposal
includes a test method for evaluating
many of these aspects of performance.
Having a clear test method helps inform
the public as to how the agency would
evaluate compliance with any final
FMVSS. While research is ongoing in a
few areas (namely message congestion
mitigation, explicit details for
misbehavior detection, SCMS policies
and procedures), we have described for
the public the potential requirements
that we are considering for an NPRM
264 Id.
at 1223.
at 1225 (citing Chrysler Corp. v. Rhodes,
416 F.2d 319, 322, 322 n. 4) (1st Cir. 1969) (‘‘motor
vehicles are required to have specific items of
equipment . . . These enumerated items of
equipment are subject to specific performance
standards,’’ including lamps and reflective devices
requiring ‘‘specific items of equipment’’)); Wood v.
Gen. Motors Corp., 865 F.2d 395, 417 (1st Cir. 1988)
(‘‘requiring seat belts or passive restraints . . . has
elements of a design standard’’); Automotive Parts
& Accessories Ass’n v. Boyd, 407 F.2d 330, 332
(D.C. Cir. 1968) (‘‘factor equipped . . . head
restraints which meet specific Federal standards’’).
srobinson on DSK5SPTVN1PROD with PROPOSALS2
265 Id.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
and the potential test methods for
evaluating compliance with those
requirements. We believe that the public
comments that we will receive in
response (coupled with the agency’s
ongoing research) will produce a robust
record upon which the agency can make
a final decision.
The provisions allowing alternative
technologies to satisfy the mandate are
performance-oriented, but do not
specify a particular way of
communicating. The goal of this is to
maximize industry’s ability to innovate
and potentially employ future
communication technologies that may
be able to meet the performance
requirements (like, for example, latency)
for V2V-based safety warning
applications. While alternative
technologies would be subject to several
aspects of the test procedures set forth
for DSRC-based devices, it leaves open
for industry to develop a number of
aspects of performance, including
interoperability with all other V2V
communications technologies that
transmit BSMs. We believe that the
inclusion of some performance tests
makes these provisions consistent with
the Safety Act requirement of standards
being ‘‘performance-oriented.’’ We seek
comment on this tentative conclusion.
2. Standards ‘‘Meeting the Need for
Motor Vehicle Safety’’
As required by the Safety Act,
standards issued by the agency must
‘‘meet the need for motor vehicle
safety.’’ 266 As ‘‘motor vehicle safety’’ is
defined in the statute as protecting the
public against ‘‘unreasonable risk’’ of
accidents, death, or injury,267 the case
law indicates that there must be a nexus
between the safety problem and the
standard.268
However, a standard need not address
safety by direct means. In upholding
NHTSA’s authority to issue a safety
standard requiring standardized vehicle
identification numbers, the Fourth
Circuit Court of Appeals found that an
FMVSS requiring VINs met the need for
motor vehicle safety by such indirect
266 49
U.S.C. 30111(a).
U.S.C. 30102(a)(8).
268 See, e.g., Nat’l Tire Dealers Ass’n v. Brinegar,
491 F.2d 31, 35–37 (D.C. Cir. 1974) (stating that the
administrative record did not support a significant
nexus between motor vehicle safety and requiring
retread tires to have permanent labels because there
was no showing that a second-hand owner would
be dependent on these labels and no showing as to
how often such situations would arise); see also
H&H Tire Co. v. Dept. of Transp., 471 F.2d 350,
354–55 (7th Cir. 1972) (expressing doubt that the
standard met the need for safety because there was
little evidence that the required compliance tests
would ensure that retreaded tires would be capable
of performing safely under modern driving
conditions).
267 49
PO 00000
Frm 00108
Fmt 4701
Sfmt 4702
means as reducing errors in compiling
statistical data on motor vehicle crashes
(in order to aid research to understand
current safety problems and support
future standards, to increase the
efficiency of vehicle recall campaigns,
and to assist in tracing stolen
vehicles).269
We believe that there is a clear nexus
between the safety problem and the
proposals in this document. In the case
of DSRC-based devices, DSRC can
enable all of the safety applications
under consideration by the agency, such
as Intersection Movement Assist, Left
Turn Assist, and Electronic Emergency
Brake Light, which means that DSRC
can help to address the safety problems
of, e.g., intersection collisions,
collisions with forward stopped or
slowing vehicles, collisions that occur
because a driver chose to pass a forward
vehicle without enough room to do so
safely, etc. For some of the other safety
applications, which can also be enabled
by other technologies besides DSRC,
such as on-board sensors, radar, or
cameras, DSRC can add robustness to an
on-board system. DSRC will either be
the sole enabler of some safety
applications or present a possible
enhancement to on-board systems with
regard to other applications. In either
case, DSRC will address safety needs.
Moreover, case law supports that
DSRC need not directly create more
safety itself, as long as it is enabling
other safety applications. If VINs could
be upheld as meeting the need for motor
vehicle safety simply by virtue of the
fact that they aid research in
understanding safety problems and
supporting future standards, as well as
aiding recall campaigns and tracking of
stolen vehicles, then DSRC, which
would directly enable half a dozen
safety applications at its inception and
perhaps many more eventually, seems
even more clearly to meet the need for
safety in that respect.
Non-DSRC devices should have a
similar nexus to the safety problem.
3. ‘‘Objective’’ Standards
A standard is objective if it specifies
test procedures that are ‘‘capable of
producing identical results when test
conditions are exactly duplicated’’ and
performance requirements whose
satisfaction is ‘‘based upon the readings
obtained from measuring instruments as
opposed to subjective opinions.’’ 270 The
requirement that standards be stated in
269 Vehicle Equip. Safety Comm’n v. NHTSA, 611
F.2d 53, 54 (4th Cir. 1979).
270 Chrysler Corp. v. Dept. of Transp., 472 F.2d
659, 676 (6th Cir. 1972); see also Paccar, Inc., v.
Nat’l Highway Traffic Safety Admin., 573 F.2d 632,
644 (9th Cir. 1978).
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
objective terms matches the overall
statutory scheme requiring that
manufacturers self-certify that their
motor vehicles or motor vehicle
equipment comply with the relevant
FMVSSs.271 In order for this statutory
scheme to work, the agency and the
manufacturer must be able to obtain the
same result from identical tests in order
to objectively determine the validity of
the manufacturer’s certification.272
Using those two elements of
objectivity (capable of producing
identical results and compliance based
on measurements rather than subjective
opinion), the Sixth Circuit Court of
Appeals found that the test procedure in
question in an early version of FMVSS
No. 208 was not objective because the
test dummy specified in the standard for
use in compliance testing did not give
consistent and repeatable results.273 The
court in this case was unconvinced that
the standard met the objectivity
requirements even though NHTSA
based its test procedure on a test
dummy in a voluntary automotive
industry standard (Society of
Automotive Engineers Recommended
Practice J963). The court rejected
NHTSA’s explanation that, although
J963 ‘‘may not provide totally
reproducible results,’’ ‘‘dummies
conforming to the SAE specifications
are the most complete and satisfactory
ones presently available.’’ 274 Further,
the court rejected NHTSA’s reasoning
that, in the event that the agency’s test
results were different from those of the
manufacturers because of the difference
in the test dummies, NHTSA’s test
results would not be used to find noncompliance, stating that ‘‘there is no
room for an [ ] agency investigation [ ]
in this procedure’’ that enable the
271 49
U.S.C. 30115(a).
Corp., 472 F.2d at 675.
273 As the court stated,
The record supports the conclusions that the test
procedures and the test device specified . . . are
not objective in at least the following respects: (1)
The absence of an adequate flexibility criteria for
the dummy’s neck; the existing specifications
permit the neck to be very stiff, or very flexible, or
somewhere in between, significantly affecting the
resultant forces measured on the dummy’s head. (2)
Permissible variations in the test procedure for
determining thorax dynamic spring rate (force
deflection characteristics on the dummy’s chest)
permit considerable latitude in chest construction
which could produce wide variations in maximum
chest deceleration between two different dummies,
each of which meets the literal requirements of SAE
J963. (3) The absence of specific, objective
specifications for construction of the dummy’s head
permits significant variation in forces imparted to
the accelerometer by which performance is to be
measured.
Id. at 676–78.
274 Id. at 677.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
272 Chrysler
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
agency to compare results of differing
tests.275
Other courts have also reached similar
conclusions. The Ninth Circuit Court of
Appeals, relying on the same reasoning
adopted by the Sixth Circuit, found that
a compliance road test specifying the
use of surfaces specifically rated with
quantifiable numbers (defining the
‘‘slickness’’ of the surfaces) was
objective despite ‘‘[t]he fact that it is
difficult to create and thereafter
maintain a road surface with a
particular coefficient of friction,’’ which
the court held ‘‘does not render the
specified coefficient any less
objective.’’ 276 In this case, both NHTSA
and the manufacturer would perform
road tests on surfaces with identically
rated friction coefficients.277 In a later
case, the Sixth Circuit upheld NHTSA’s
decision not to incorporate a test
suggested by a commenter for
wheelchair crashworthiness performed
with a ‘‘test seat’’ that ‘‘shall be capable
of resisting significant deformation’’
during a test as not sufficiently
objective.278 In the absence of language
quantifying how much deformation is
significant, terms such as ‘‘significant
deformation’’ do not provide enough
specificity to remove the subjective
element from the compliance
determination process.
As discussed above, under the
proposal, we have developed and are
proposing performance requirements,
including compliance test procedures,
for DSRC. We will continue evaluating
the compliance test procedures further
and receiving public input during the
comment period that can assist us in
fine-tuning the procedures and ensuring
that they meet our statutory
requirements. For alternative
technologies, given that the testing to
this point that led to the development
of the test procedures for
interoperability did not evaluate the use
of non-DSRC communication
technologies, we seek comment on how
the regulatory text alternative
technologies can achieve
interoperability in an objective manner.
275 Id.
at 677–79.
Inc. v. Nat’l Highway Traffic Safety
Admin., 573 F.2d 632, 644 (9th Cir. 1978), cert.
denied, 439 U.S. 862 (1978).
277 Id. (stating that the ‘‘skid number method of
testing braking capacity meets the [objectivity]
definition. Identical results will ensue when test
conditions are exactly duplicated. The procedure is
rational and decisively demonstrable. Compliance
is based on objective measures of stopping
distances rather than on the subjective opinions of
human beings.’’).
278 Simms v. Nat’l Highway Traffic Safety
Admin., 45 F.3d 999, 1007–08 (6th Cir. 1995).
276 Paccar,
PO 00000
Frm 00109
Fmt 4701
Sfmt 4702
3961
4. ‘‘Practicable’’ Standards
In general, the practicability of a given
standard involves a number of
considerations. The majority of issues
concerning the practicability of a
standard arise out of whether the
standard is technologically and
economically feasible. An additional
issue is whether the means used to
comply with a standard will be accepted
and correctly used by the public.
First, significant technical
uncertainties in meeting a standard
might lead a court to find that a
standard is not practicable. For
example, the Sixth Circuit Court of
Appeals upheld NHTSA’s decision to
amend FMVSS No. 222 to include
requirements for wheelchair securement
and occupant restraint on school buses
with a static 279 compliance test instead
of a dynamic test,280 noting that the
administrative record showed that this
particular dynamic test was
underdeveloped and had many
unresolved technical problems.281 The
court noted that it is not practicable
‘‘[t]o attempt to fashion rules in an area
in which many technical problems have
been identified and no consensus exists
for their resolution . . . .’’ 282 In
another example, the Ninth Circuit
Court of Appeals found a compliance
test procedure using a specified friction
(slickness) coefficient to be
impracticable due to technical
difficulties in maintaining the specific
slickness test condition. As mentioned
279 Static testing tests the strength of individual
components of the wheelchair separately, while
dynamic testing subjects the entire wheelchair to
simulated real-world crash conditions. See Simms,
45 F.3d at 1001.
280 Id. at 1006–08. Petitioners argued that NHTSA
had acted unlawfully in promulgating standards for
the securement of wheelchairs on school buses
based only on ‘‘static’’ instead of ‘‘dynamic’’ testing.
Id. Static testing tests the strength of the individual
components of a securement device. Id. Dynamic
testing is a full systems approach that measures the
forces experienced by a human surrogate (test
dummy) in a simulated crash that replicates realworld conditions and assesses the combined
performance of the vehicle and the securement
device. Id.
281 Id. at 1005–07. NHTSA agreed that dynamic
testing is the preferred approach (because it more
fully and accurately represents the real-world
conditions in which the desired safety performance
is to be provided), but explained that it was not
practicable at that time to adopt dynamic testing
because there was:
(1) [N]eed to develop an appropriate test dummy;
(2) need to identify human tolerance levels for a
handicapped child; (3) need to establish test
conditions; (4) need to select a ‘‘standard’’ or
surrogate wheelchair; (5) need to establish
procedures for placing the wheelchair and test
dummy in an effective test condition; and (6) need
to develop an appropriate test buck to represent a
portion of the school bus body for securement and
anchorages.
Id. at 1005.
282 Id. at 1010–11.
E:\FR\FM\12JAP2.SGM
12JAP2
3962
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
above, the Ninth Circuit found the
specified coefficient test condition to be
objective.283 However, simply being
objective did not also make the test
condition practicable. Thus, the cases
show that when significant technical
uncertainties and difficulties exist in a
standard promulgated by NHTSA, those
portions of the standard can be
considered impracticable under the
Safety Act.
However, the requirement that a
standard be technologically feasible
does not include the additional
requirement that the agency show that
the technology to be used to comply
with the standard is already fully
developed and tested at the time that
the standard is promulgated. The Sixth
Circuit upheld a NHTSA standard
requiring ‘‘Complete Passive
Protection,’’ that required the
installation of airbags as standard
equipment by a future date, rejecting
petitioner’s contention that NHTSA may
only establish performance
requirements which can be met with
devices which, at the time of the
rulemaking, are developed to the point
that they may be readily installed.284
Relying on the legislative history of the
Safety Act, the court found that the
agency ‘‘is empowered to issue safety
standards which require improvements
in existing technology or which require
the development of new technology,
and is not limited to issuing standards
based fully on devices already
developed.’’ 285 Thus, the requirement
that standards be technologically
feasible is sufficiently broad that it can
be satisfied by showing that new
technology can be developed in time to
283 Paccar, Inc. v. Nat’l Highway Traffic Safety
Admin., 573 F.2d 632, 644 (9th Cir. 1978).
284 See Chrysler Corp. v. Dept. of Transp., 472
F.2d at 671–75. Stages one and two required vehicle
manufacturers to provide ‘‘Complete Passive
Protection’’ or one of two other options on vehicles
manufactured between January 1, 1972 and August
14, 1973 (for stage one) and after August 15, 1973
(stage two). See id. at 666–67. Stage three, requiring
solely ‘‘Complete Passive Protection,’’ was required
by August 15, 1975. Id. at 667.
285 Id. at 673. In making its decision, the court
stated
[I]t is clear from the Act and its legislative history
that the Agency may issue standards requiring
future levels of motor vehicle performance which
manufacturers could not meet unless they diverted
more of the ir resources to producing additional
safety technology than they might otherwise do.
This distinction is one committed to the Agency’s
discretion, and any hardships which might result
from the adoption of a standard requiring . . . a
great degree of developmental research, can be
ameliorated by the Agency under . . . The section
[that] allows the Secretary to extend the effective
date beyond the usual statutory maximum of one
year from the date of issuance, as he has done
[here].
Id. at 673.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
comply with the effective date of the
standard.286
Second, a standard can be considered
impracticable by the courts due to
economic infeasibility. This
consideration primarily involves the
costs imposed by a standard.287 In the
instances in which a court has been
called upon to assess whether a
standard is economically feasible,
typically with respect to an industry
composed largely of relatively small
businesses, the courts have asked
whether or not the cost would be so
prohibitive that it could cause
significant harm to a well-established
industry. In essence, this consideration
generally establishes a non-quantified
outer limit of the costs that can be
reasonably imposed on regulated
entities. If compliance with the standard
is so burdensome, i.e., costly, so as to
create a significant harm to a wellestablished industry, courts have
generally found that the standard is
impracticable in its application to that
industry.
Finally, a standard might not be
considered practicable if the public
were not expected to accept and
correctly use the technologies installed
in compliance with the standard. When
considering passive restraints such as
automatic seatbelts, the D.C. Circuit
stated that ‘‘the agency cannot fulfill its
statutory responsibility [in regard to
practicability] unless it considers
popular reaction.’’ 288 While the agency
argued in that case that public
acceptance is not one of the statutory
criteria that the agency must apply, the
court disagreed. The court reasoned that
‘‘without public cooperation there can
be no assurance that a safety system can
‘meet the need for motor vehicle
safety.’ ’’ 289 Thus, as a part of the
agency’s considerations, a standard
issued by the agency will not be
considered practicable if the
technologies installed pursuant to the
286 A corollary of the agency’s authority to issue
technology-driving standards is that the agency can
rely on data other than real-world crash data in
justifying those standards. Technology that is not
yet either fully developed or being installed on
production vehicles cannot generate real-world
performance data. Thus, in justifying the issuance
of technology-driving standards, it is permissible,
even necessary, for the agency to rely on analyses
using experimental test data or other types of nonreal world performance information in determining
whether such standards ‘‘meet the need for vehicle
safety.’’
287 E.g., Nat’l Truck Equip. Ass’n v. Nat’l Highway
Traffic Safety Admin., 919 F.2d 1148, 1153–54 (6th
Cir. 1990); Ctr. for Auto Safety v. Peck, 751 F.2d
1336, 1343 (D.C. Cir. 1985) (panel opinion by
Circuit Judge Scalia).
288 Pac. Legal Found. v. Dept. of Transp., 593
F.2d 1338, 1345–46 (D.C. Cir.), cert. denied, 444
U.S. 830 (1979).
289 Id.
PO 00000
Frm 00110
Fmt 4701
Sfmt 4702
standard are so unpopular that there is
no assurance of sufficient public
cooperation to meet the safety need that
the standard seeks to address.290
We believe that the proposal is
consistent with these requirements.
Technologically, DSRC has existed for
over a decade, and is currently being
used in Japan to support V2I
applications and electronic toll
collection. The performance
requirements and test procedures being
proposed to help ensure interoperability
should also ensure the technological
practicability of the proposal. In terms
of economic practicability, NHTSA
currently assumes that the cost of a
DSRC standard would include costs for
device hardware and software, as well
as costs for the security and
communications system that would be
necessary in order for DSRC to function
properly. As discussed in Section VII
below, we estimate the likely total cost
for a V2V system to the consumer
(vehicle equipment costs, fuel economy
impact, SCMS costs, and
communication costs) at approximately
$350 per new vehicle in 2020. Economic
practicability requires that compliance
with the standard should not be so
burdensome as to create a significant
harm to a well-established industry. It
does not seem likely that a court would
find the standards economically
impracticable either for the auto
industry, or for any small business
interests potentially implicated, since
those would more likely be in the
context of aftermarket devices (phone
apps and so forth), which are entirely
voluntary and do not represent a
mandate.
For the question of public acceptance,
the main concerns with regard to the
proposal likely relate to security and
privacy. To address such concerns, the
requirements in the proposal include
tests to ensure tamper-resistance of the
DSRC unit; security requirements for the
messages themselves; express
requirements that certain identifying
information not be included in the
BSMs, and so forth. We are also
proposing that manufacturers alert
drivers when software upgrades and
patches and certificate updates are
needed, and we are hopeful that such
updates would be as seamless as
possible.
290 Pursuant to concerns about public acceptance
of various seat belt designs, NHTSA issued a final
rule in 1981 adding seat belt comfort and
convenience requirements to Standard No. 208,
Occupant Crash Protection. Federal Motor Vehicle
Safety Standards; Improvement of Seat Belt
Assemblies, 46 FR 2064 (Jan. 8, 1981) (codified at
49 CFR part 571).
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
With respect to comments on the
agency’s authority received to the
ANPRM and Readiness Report,
commenters tended to support generally
the agency’s authority to establish an
FMVSS for V2V communications, while
some commenters offered their own
interpretations of what would be
necessary for a standard to be consistent
with the Safety Act. The Alliance, for
example, argued that a proposal to
mandate DSRC in new vehicles and set
standards for DSRC aftermarket devices
would not meet the Safety Act criteria
if (1) NHTSA could not prove that the
standard would improve safety as
compared with not adopting a new
FMVSS; (2) NHTSA did not present
how a security system would be
‘‘established, funded, governed and
operated’’: and (3) FCC opened the 5.9
GHz spectrum to unlicensed wireless
devices and the operation of those
devices resulted in harmful interference
to V2X communications.291
Additionally, the Alliance underscored
the importance of addressing public
perception issues in order to ensure that
consumers are willing to accept DSRC
technology, because otherwise a
mandate would not be practicable and
the market failure would not be
cured.292 The Alliance suggested that
the agency consider working with other
federal agencies with more direct
experience in addressing health and
privacy concerns to address potential
public acceptance issues.293 Global
Automakers agreed that it was
important to a DSRC mandate that
NHTSA work carefully with other
Federal agencies (i.e., FCC and NTIA) to
ensure that DSRC communications can
be effective and interoperable without
harmful interference.294 Toyota stated
that a necessary pre-condition for a
DSRC mandate was a limited
deployment of a production-ready,
DSRC-equipped fleet to confirm product
design.295 TIA commented that any
FMVSS for V2V communications
should be entirely technology agnostic
and focus on performance requirements
(data latency, size, interoperability) that
could be met by any technology, not
only DSRC, and allow technologies to
evolve over time.296
As discussed above, NHTSA
continues to believe that the proposal is
consistent with the Safety Act. As
Section III.E discusses at length and as
the proposed regulatory text for the
291 Alliance
at 6–7, 13–14.
at 9, 14.
293 Alliance at 10.
294 Global at 11.
295 Toyota at 1.
296 TIA at 4, 5.
292 Alliance
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
proposal at the end of this preamble
discuss at length, NHTSA has
developed proposed requirements for
DSRC performance. These sections
explain: (1) What information needs to
be sent to the surrounding vehicles; (2)
how the vehicle needs to send that
information; (3) how a vehicle shows
that it is a valid source of information;
and (4) how a vehicle makes sure the
prior three functions work in various
operational conditions (i.e., broadcast
under congested conditions, detect/
report misbehavior, and obtain new
security materials). The proposal draws
from existing voluntary standards while
also explaining why a particular
threshold or requirements from a
voluntary standard is appropriate.
Finally, the proposal includes a test
method for evaluating many of these
aspects of performance. Having a clear
test method helps inform the public as
to how the agency would evaluate
compliance with any final FMVSS
based on the proposal. While research is
ongoing in a few areas (namely message
congestion mitigation, explicit details
for misbehavior detection, SCMS
policies and procedures), we have
described for the public the potential
requirements in the proposal 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.
We do not agree with commenters
that the proposed standard must be
perfectly neutral regarding technology,
nor that all possible issues associated
with ensuring the long-term success of
V2V must be resolved prior to issuing a
proposal. As explained above, case law
supports the principle that an FMVSS
may restrict design flexibility if certain
designs would be contrary to the
interests of safety. Additionally, we do
not believe that waiting to issue a
proposal until, for example, DSRC is
more thoroughly tested in the fleet, or
an SCMS is fully funded and
operational, or every potential consumer
concern is resolved, would be in the
best interest of safety. S9 of the
regulatory text, however, is directly
responsive to the TIA comment
requesting that the agency consider a
technology agnostic approach. As
covered in the discussion concerning
why we are proposing to require V2V
communications, for a technology like
V2V, where a critical mass of equipped
vehicles is needed to create the
environment for safety benefits to be
PO 00000
Frm 00111
Fmt 4701
Sfmt 4702
3963
possible, the agency does not believe
that sufficient quantities of V2Vequipped vehicles will be introduced in
the market absent a mandate. By
proposing this FMVSS, we aim to create
an information environment which, we
believe, will then enable the market to
bring forth the safety, mobility, and
environmental benefits that we
anticipate V2V can provide. We intend
to continue working closely with other
Federal agencies and industry
stakeholders on spectrum issues, with
industry stakeholders and consumer
groups and others on consumer-related
concerns, and with all relevant parties
on developing an SCMS to support a
V2V network. We will also continue our
research to improve and refine potential
performance requirements and test
procedures, as discussed above. Again,
public comment on the proposal will
facilitate our careful consideration of
these issues, and we look forward to
hearing from commenters on how to
resolve them to best serve the interests
of safety.
C. How are the regulatory alternatives
consistent with our Safety Act
authority?
Besides the proposal, the agency is
considering two regulatory
alternatives—the first, a ‘‘mandate V2V
communications and safety
applications’’ alternative, under which
the agency also requires new vehicles to
have IMA and LTA capabilities; and the
second, an ‘‘if-equipped’’ alternative,
that would set baseline requirements for
V2V communications, but not require
new vehicles to have this technology on
any specific schedule. Under both the
‘‘mandate V2V communications’’
proposal and the ‘‘and safety
applications’’ alternative, the phase-in
rate for V2V communications for new
vehicles would be 50 percent in the first
required year, 75 percent in the second
year, and 100 percent in the third year
and beyond. We have evaluated the
‘‘and safety applications’’ alternative in
terms of two different phase-in
scenarios—in the first scenario, safety
applications would be required for new
vehicles at a phase-in rate of 0 percent—
50 percent—75 percent—100 percent
over four years; while in the second
scenario, safety applications would be
required for all new vehicles in the first
year that V2V communications are
required. The ‘‘if-equipped’’ alternative,
on the other hand, faces much greater
uncertainty regarding the technology
adoption. Based on the estimated costs
of V2V radios and the SCMS, and the
‘‘network’’ nature of V2V
communication, the agency believes
that Alternative 2 is unlikely to lead to
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3964
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
meaningful deployment of V2V
communications. Consequently,
Alternative 2 would delay, potentially
for a significant period of time, the
anticipated benefits of V2V
communications. Furthermore, there is
a high probability that the designated
spectrum for V2V safety applications
would be lost if a mandate was not
pursued. For these reasons, the ‘‘ifequipped’’ alternative is not a viable
alternative. Due to this, as well as to the
significant uncertainty surrounding the
technology adoption, the PRIA does not
examine the costs and benefits for this
alternative.
The ‘‘if-equipped’’ alternative is
consistent with the agency’s Safety Act
authority, which does not require
NHTSA to require technology for new
vehicles. It is therefore not discussed
further in this section.
The agency evaluated our authority to
mandate specific safety applications in
the Readiness Report 297 and sought
comment on that evaluation in the
ANPRM.298
As discussed in the Readiness Report,
an FMVSS for a safety application must
include minimum requirements for its
performance. This first requires a
determination of what tasks the safety
applications need to perform, which
would vary based on the types of safety
risks/crash scenarios that the
application is intended to address. The
agency explained in the Readiness
Report that it is examining the
currently-available (research-stage)
performance and test metrics associated
with each safety application, and
analyzing these metrics against the
available safety data to determine
whether these metrics cover the relevant
safety problem.
The Readiness Report explained that
the agency envisioned that an FMVSS
for one of the analyzed safety
applications would set performance
requirements that could be met by any
technology, but that if V2V
communications performance
requirements made it reasonable to
require more robust performance, we
could require that performance if V2V
communications were mandated. The
agency recognized for some
applications, like IMA and LTA,
performance requirements can likely be
met only with V2V communicationsbased technologies due to their ability to
detect crossing-path vehicles, but for
others, a variety of technologies could
potentially be used.
297 See
Readiness Report at Section IV.B.3.
298 79 FR at 49271 (Aug. 20, 2014).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
With regard to other Safety Act
requirements for an FMVSS, the
Readiness Report concluded as follows:
• Meet the need for safety: FMVSSs
for the V2V-based safety applications
would be issued to address safety
problems that continue to cause crashes
in the absence of regulation or market
forces driving their adoption, and would
address those problems by warning
drivers of dangerous conditions and
triggering a response to avoid the
danger. However, given that research
continues at this point to develop
driver-vehicle interfaces for each of the
safety applications, and given that the
agency was not yet able to demonstrate
how effective the DVIs we may
eventually mandate are at warning the
drivers and inducing them to avoid the
dangerous situation, our evidence could
be stronger that the V2V safety
applications will meet the need for
safety.
• Objective test procedures and
performance requirements: Test
procedures and performance
requirements for the V2V safety
applications are still being developed,
but NHTSA would ensure that any test
procedures it may require would meet
the criteria of being objective.
• Technological practicability:
Because test procedures and
requirements (including those for DVIs)
are still being developed for the V2V
safety applications, additional lead time
could be helpful to meet eventual
standards in order to ensure that
manufacturers have the opportunity to
work out how to comply.299 More
research will be helpful in informing
future assessments of technological
practicability.
• Economic practicability: NHTSA
currently assumes using preliminary
cost estimates that the cost of standards
for the V2V-based safety applications
would primarily include costs for
software that would be used by the
vehicle to interpret V2V signals and
make decisions about whether to warn
the driver, as well as costs for any
hardware that would be necessary to
make those warnings happen via the
DVI. While it seems unlikely that
economic practicability would be an
issue for potential safety application
FMVSSs, more research to determine
costs more precisely would be beneficial
to this assessment.
• Public acceptance: Based on the
research we have so far from the Safety
Pilot, driver enthusiasm for individual
V2V safety applications varies. Given
299 See discussion above regarding the Sixth
Circuit’s finding in Chrysler, 472 F.2d at 659, 666,
and 671–75 (6th Cir. 1972).
PO 00000
Frm 00112
Fmt 4701
Sfmt 4702
that DVI requirements remain under
development, and given the need for
continued research to avoid a high false
positive rate, more work needs to be
done before we can be confident that
eventual FMVSSs for V2V safety
applications will not have public
acceptance risks.
Commenters generally agreed with the
agency’s authority to issue FMVSSs for
V2V-based safety applications (both in
terms of mandating their installation
and regulating their performance), and
also agreed that more work was likely
needed before such FMVSSs would be
consistent with Safety Act requirements.
The Alliance, for example, agreed that
NHTSA could specify levels of
performance for safety applications that
‘‘indirectly eliminate[d] some forms of
delivering the safety application within
the motor vehicle,’’ but stated that much
work was needed before it would be
clear that an FMVSS for any safety
application met Safety Act criteria.300
Global commented that DSRC should be
widespread in the fleet and
manufacturers should already have
experience with applications before the
agency should mandate them; 301 Honda
provided similar comments.302 Ford
commented that NHTSA should not
mandate applications.303 Toyota, in
contrast, stated that NHTSA should
require IMA and LTA at the same time
as it mandates DSRC capability, in order
to speed introduction of safety
benefits,304 although it also stated that
any FMVSS for a safety application
must meet Safety Act criteria.305
Advocates for Highway and Auto Safety
provided similar comments.306
Hyundai, TIA, and Delphi commented
that if the agency decided to mandate
safety applications like IMA and LTA, it
should ensure that standards were
entirely performance-based and
technology-neutral.307 A number of
commenters raised concerns about the
need for additional research with regard
to DVIs and false positive alerts.308
NHTSA agrees with some commenters
that earlier introduction of safety
applications would guarantee earlier
achievement of safety benefits
associated with V2V capability, and we
also agree with other commenters that
additional work would likely be
necessary in order for the agency to
ensure that potential FMVSSs for safety
300 Alliance
at 17.
at 3.
302 Honda at 6.
303 Ford at 3–4.
304 Toyota at 1.
305 Toyota at 4.
306 Advocates at 1–2.
307 Hyundai at 2; TIA at 4; Delphi at 1.
308 Bendix at 10–11.
301 Global
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
applications were objective and
practicable. Developing minimum
standards for safety application
performance requires a determination of
what tasks the safety applications need
to perform, which varies based on the
types of safety risks/crash scenarios that
the application is intended to address.
The agency is examining the currentlyavailable (research-stage) performance
and test metrics associated with a
variety of safety applications, including
IMA and LTA, and analyzing these
metrics against the available safety data
to determine whether these metrics
cover the applicable safety problem(s).
Although this research is currently
underway, we request comment now on
whether and, if so, how the agency
could design requirements to mandate
certain safety applications.
In response to comments that
FMVSSs should be performanceoriented and technologically neutral, we
envision that each FMVSS for one of
these safety applications would set
performance requirements that could be
met by any technology. However, if V2V
communication performance
requirements made it reasonable to
require more robust performance, we
could require that performance when
V2V communication is mandated.
We continue to believe that any
FMVSSs for the V2V safety applications
would meet the need for safety, insofar
as we would issue them to address
safety problems that continue to cause
crashes in the absence of regulation or
market forces driving the adoption of
these technologies. The safety
applications are clearly intended to
relate to safety—they warn drivers of
dangerous conditions and are intended
to promote safety by triggering a
response to avoid the danger.
There are several things that the
agency could do to help solidify the
nexus of safety application warning and
driver response. For example, and as
raised by commenters, research
continues at this point to develop
driver-vehicle interfaces for each of the
safety applications. We will want to be
able to demonstrate how effective the
DVIs we may eventually mandate are at
warning the drivers and inducing them
to avoid the dangerous situation. We
currently have reason to believe that the
V2V safety applications will meet the
need for safety, but additional
information and analysis will make that
case stronger and we request comment
on this.
FMVSSs for V2V safety applications
also need to be objective, meaning that
they specify test procedures that are
‘‘capable of producing identical results
when test conditions are exactly
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
duplicated’’ (meaning that the agency
and the manufacturer must be able to
obtain the same result from identical
tests) and performance requirements
whose satisfaction is ‘‘based upon the
readings obtained from measuring
instruments as opposed to subjective
opinions.’’ As discussed above, test
procedures and performance
requirements for the V2V safety
applications are still being developed,
but NHTSA would ensure that any test
procedures it may require would meet
the criteria of being objective, and also
technologically practicable. NHTSA
would provide appropriate lead time for
any FMVSSs to ensure these criteria are
met, as well.309 More research and
additional public comment will be
helpful in informing future assessments
of technological practicability.
In terms of economic practicability,
NHTSA currently assumes using
preliminary cost estimates that the cost
of standards for the V2V-based safety
applications would primarily include
costs for software that would be used by
the vehicle to interpret V2V
communications signals and make
decisions about whether to warn the
driver, as well as costs for any hardware
that would be necessary to make those
warnings happen via the DVI. As
discussed above, it seems unlikely that
economic practicability would be an
issue for potential safety application
FMVSSs, but more research to
determine costs more precisely would
be beneficial to this assessment.
While the Safety Pilot Model
Deployment provided participating
manufacturers with useful real-world
experience in tuning prototype
applications to maximize effectiveness
and minimize false positives, DVI
requirements remain under
development, and more work needs to
be done before we can be confident that
eventual FMVSSs for V2V safety
applications will not have public
acceptance risks.
D. What else needs to happen in order
for a V2V system to be successful?
1. SCMS
Under both the Vehicle Safety Act
and the Highway Safety Act, NHTSA
has other ways of affecting the parts of
the V2V system that cannot be regulated
directly. For example, 49 U.S.C. 30182
provides NHTSA authority to enter into
contracts, grants, and cooperative
agreements with a wide range of outside
entities to conduct motor vehicle safety
research and development activities,
309 See discussion above regarding the Sixth
Circuit’s finding in Chrysler, 472 F.2d at 659, 666,
and 671–75.
PO 00000
Frm 00113
Fmt 4701
Sfmt 4702
3965
including activities related to new and
emerging technologies. Separately, the
Highway Safety Act (23 U.S.C. 401 et
seq.) authorizes NHTSA to enter into
contracts, grants, cooperative
agreements, and other transactions for
research and development activities
with a similarly wide range of outside
entities in ‘‘all aspects of highway and
traffic safety systems . . . relating to [ ]
vehicle, highway, [and] driver . . .
characteristics’’ (sec. 403(b)), as well as
collaborative research and development,
on a cost-shared basis, to ‘‘encourage
innovative solutions to highway safety
problems’’ and ‘‘stimulate the marketing
of new highway safety related
technology by private industry’’ (sec.
403(c)). Because issues related to V2V
are cross-cutting, spanning both the
Vehicle Safety Act and the Highway
Safety Act, these separate authorities
provide the agency with sufficient
flexibility to enter into a variety of
agreements related to the development
of a V2V security system (although the
agency currently lacks sufficient
appropriations to incur any significant
Federal expenditures for these
purposes).
A principle of appropriations law
known as the ‘‘necessary expense
doctrine’’ allows NHTSA to take the
next step of entering into contracts or
agreements to ensure the existence of
sufficient communications and security
systems to support deployment of V2V
technologies, if V2V communications
are mandated or otherwise regulated by
a Federal Motor Vehicle Safety Standard
or other NHTSA regulation. According
to that principle, when an appropriation
is made for a particular purpose, it
confers on the receiving agency the
authority to incur expenses necessary to
carry out the purpose of the
appropriation.310 Under the necessary
expense doctrine, the spending agency
has reasonable discretion to determine
what actions are necessary to carry out
the authorized agency function. Here,
the agency assumes that the deployment
and operation of the SCMS is necessary
in order for V2V technology and on310 Under the necessary expense doctrine, an
expenditure is justified if it meets a three-part test:
(1) The expenditure must bear a logical relationship
to the appropriation sought to be charged (i.e., it
must make a direct contribution to carrying out
either a specific appropriation or an authorized
agency function for which more general
appropriations are available); (2) the expenditure
must not be prohibited by law; and (3) the
expenditure must not be otherwise provided for
(i.e., it must not be an item that falls within the
scope of some other appropriation or statutory
funding scheme. See U.S. Gen. Accounting Office,
Principles of Federal Appropriations Law 4–22 (3d
ed.2004) (the ‘‘GAO Redbook’’), available at https://
www.gao.gov/special.pubs/3rdeditionvol1.pdf (last
accessed Dec. 6, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
3966
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
board equipment to function in a safe,
secure and privacy-protective
manner.311 As designed, V2V
technology cannot operate without a
sufficient security system, and absent
such a security system, misbehavior by
hackers or others could compromise
V2V functionality and participant
privacy. If the problem of
‘‘misbehavior’’ were sufficiently
widespread, it might even cause
widespread disregard of or delayed
response to V2V warnings. Hence, a
robust SCMS is imperative in the V2V
regulatory environment.
For these reasons, in addition to
NHTSA’s research, development, and
collaboration authority under the
Vehicle Safety Act and the Highway
Safety Act, the necessary expense
doctrine provides sufficient authority
under the Vehicle Safety Act to take the
next step of entering into agreements or
contracts, either for cost or no-cost, with
the goal of ensuring the existence (i.e.,
the development and operation) of
sufficient communications and security
systems to support the reliability and
trustworthiness of V2V
communications. As is the case under
the agency’s research and development
authority, discussed above, the current
limiting factor is the absence of
sufficient appropriations to incur any
significant expenses in this regard.
NHTSA received comments to the
ANPRM and Readiness Report from
some stakeholders suggesting that
NHTSA itself must obtain funding for
and develop at least parts of the SCMS
as a Federal project.312 While NHTSA
agrees that we would have authority, as
discussed directly above, to facilitate
the development of an SCMS if we had
the appropriations to do so, conditions
have not changed since our issuance of
the ANPRM and Readiness Report that
would allow us to do so.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
2. Liability
The Readiness Report discussed the
issue of legal liability in the context of
V2V,313 and the ANPRM sought
comment on that discussion.314 For
purposes of that discussion, the agency
separated potential liability issues for
V2V into two categories: (1) Liability
associated with equipment on the
vehicle, particularly warning systems
311 Potentially, under some alternatives of this
proposal, the agency would not assume the future
presence of an SCMS, and would leave security
requirements more open. In this instance,
presumably the agency would not need to ensure
the existience of communications and security
systems to support V2V, so the invocation of the
necessary expense doctrine would not be necessary.
312 GM, at 4; Alliance, at 19.
313 See Section X of the Readiness Report.
314 79 FR at 49273 (Aug. 20, 2014).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
that rely on V2V systems, and (2)
liability associated with the SCMS.
For the first category, NHTSA stated
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, and that therefore, V2V
warning technologies do not create new
or unbounded liability exposure for
industry, because the driver remains
responsible for failing to avoid a crash
when the technology only warns and
does not intervene. Consequently,
NHTSA stated that it is not necessary,
nor would it be appropriate to advocate
the liability limiting agenda sought by
industry in connection with potential
deployment of V2V safety warning
technologies via government
regulation—and that, in any event, only
Congress has the authority to provide
the V2V-based liability relief sought by
industry.
For the second category, NHTSA
indicated that it was premature to take
a position on the need for liability
limiting mechanisms applicable to
operators and owners of the SCMS, and
that the appropriateness of such liability
limiting/risk sharing measures will turn
on: (1) The constitution and governance
of the SCMS; and (2) the extent to which
the primary and secondary insurance
markets make insurance coverage
available to SCMS entities and other
owners and operators of V2V
infrastructure.
NHTSA received a number of
comments in response. Generally,
commenters felt that NHTSA should
conduct additional research on liability
before proceeding with a V2V mandate,
including with respect to the liability of
automobile manufactures, owners and
operators of the SCMS and V2V
communications and security
infrastructure, and vehicle owners.
While NHTSA will continue to research
and analyze potential liability issues
stemming from a mandated V2V
System, the Agency does not believe
that additional research or work with
stakeholder and consultants on this
issue should delay the rulemaking
process or the deployment of this
important new safety technology.
Bendix and Cohda agreed with the
agency’s assessment of liability
issues,315 while other commenters
expressed less certainty on the topic and
requested that the agency consider
liability issues further.
Several commenters stated that
additional mechanisms to limit liability
are necessary before V2V can be
315 Bendix
PO 00000
at 3, Cohda at 12.
Frm 00114
Fmt 4701
Sfmt 4702
deployed. The National Motorists
Association stated that Congress needed
to define liability for individual
motorists and expressly distribute
liability among OEMs, operators,
drivers, and other public and private
stakeholders.316 Infineon and HarleyDavidson similarly commented that
Federal and/or state liability limitations
were necessary prior to V2V rollout.317
Automotive Safety Council stated that
liability should be based on ‘‘welldefined performance standards, and
should align with other global standards
for vehicle safety systems,’’ 318 while
Texas DOT commented more
specifically that laws will have to be
enacted allowing OEMs to ‘mandate’
specific operational standards of the
cars they sell.319 Meritor WABCO
argued that in order to reduce liability,
all involved parties needed to
understand that ‘‘the V2V system is not
a failsafe method to prevent crashes, the
V2V system will never be in 100 percent
of the motor vehicle population, and
that there is a big difference between
active safety systems and V2V safety
applications.’’
A number of commenters disagreed
with the agency’s assessment that V2Vbased safety warnings created no
additional liability than what already
exists for current on-board safety
warnings systems.320 The Alliance
argued that V2V-based warnings are
different from existing on-board-sensorbased warnings, because their operation
depends on input from another
manufacturer’s vehicle, because V2V is
a cooperative technology, and that this
changes the nature of ‘‘failure to warn’’
claims.321 Mr. Dennis provided similar
comments.322 Mercedes-Benz stated
more specifically that because V2V
systems depend on the ‘‘functionality,
quality, and timing of signals from
surrounding vehicles,’’ failure to warn is
no longer solely traceable to onboard
sensors of the manufacturer, which will
significantly increase the complexity of
liability claims.323 The National
Motorists Association offered several
specific research topics previously cited
also by the VIIC, including (1) whether,
and if so, how V2V warning
applications increase the risk of liability
for OEMs, operators, and drivers; (2)
whether owners may be legally
316 National
Motorists Association at 1.
at 5, Harley-Davidson at 2–3.
318 ASC at 7.
319 TX DOT at 2.
320 Alliance at 13, 18–20; CEI at 5; Mr. Dennis at
16; Global at 23; Harley-Davidson at 2; MercedesBenz at 9–10.
321 Alliance at 18
322 Mr. Dennis at 16.
323 Mercedes-Benz at 10.
317 Infineon
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
accountable for shutting off or failing
properly to maintain V2V warning
systems; and (3) whether the DVI
required for V2V warnings systems will
increase driver distraction in a way that
could affect liability.324 The Alliance
argued, in summary, that ‘‘the
traditional paradigm of automotive
product liability, in which driver error
is presumed to be at fault most of the
time, will not apply after V2V and other
autonomous technologies become more
prevalent.’’ 325 The Alliance also took
the position that NHTSA’s reliance on a
Risk Assessment Report prepared by the
Dykema law firm was misplaced
because that report assumed that a
public or quasi-public entity would run
V2V infrastructure when NHTSA itself
had assumed that the SCMS would be
private.
With regard to the agency’s
assessment of liability mitigation
through insurance, the Alliance argued
that it did not believe insurance would
necessarily be available to cover entities
involved in the SCMS since no data
existed yet on which to base
underwriting estimates, citing
cybersecurity insurance as an example
of another area where the insurance
industry is unwilling or hesitant to
provide insurance.326 The Alliance and
FCA both commented that costs
associated with defending against
SCMS-related lawsuits could be
significant.327 On whether terms of use
could limit liability for V2V, the
Alliance further argued that the agency
had overlooked ‘‘the strong disapproval
of liability-limiting clauses in contracts
with consumers,’’ and that while such
clauses might help in ‘‘allocating risk
among businesses,’’ the would not work
for ‘‘limiting liability for negligence that
allegedly causes personal injury to a
consumer.’’ 328
Other liability issues raised by
commenters included concerns about
liability associated with infrastructure.
Michigan DOT requested more
discussion of liability issues for owners/
operators of public RSE
infrastructure.329 Additional potential
liability sources cited by commenters
included false or inaccurate sensing
data,330 in-vehicle network hacking,331
and certificate revocation.332
It is clear that potential liability
stemming from V2V communications is
324 National
Motorists Association at 1.
at 21.
326 Alliance at 20–21.
327 Alliance at 31; FCA at 2.
328 Alliance at 20.
329 Alliance at 19; MI DOT at 3.
330 Rene Struik at 2.
331 Systems Research Associates at 9.
332 Alliance at 56.
325 Alliance
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
a policy issue of great concern to the
automotive industry and certain other
stakeholders. It also is true that V2V
safety warnings rely on cooperative
technology that is different than the
technologies deployed in existing onboard safety warnings systems, which
do not rely on data received from
devices and infrastructure outside of a
motor vehicle. The primary policy
issues in the OEM context are whether
liability related to the V2V System can
be addressed by the existing product
liability paradigm (i.e., statutory or
common law tort principles)—and, if
not, whether Congress is willing to
change the existing statutory scheme for
V2V-related claims in order to support
deployment of V2V technology.
The agency has researched, analyzed
and continues to grapple with this
difficult and potentially quite broad
question. We do not, as suggested by
some commenters, dismiss the critical
importance of potential legal liability to
V2V stakeholders. We recognize fully
that liability is a potential impediment
to deployment of V2V technology.
Nevertheless, from a policy perspective,
the agency continues to believe that
V2V safety warnings should not create
liability risks for automobile
manufacturers that differ in any
meaningful way from risks posed by
existing vehicle-based safety warnings
systems—and that it is premature to
propose or advocate the liabilitylimiting agendas sought by some
stakeholders.
We first address some primary V2V
liability risks to automotive
manufacturers raised by commenters.
We then discuss potential liability risks
to owners and operators of SCMS
entities, and the extent to which it is
appropriate for NHTSA to develop or
advocate liability-limiting mechanisms
applicable to such providers.
(a) Potential Liability Risks to
Automobile Manufacturers
Product liability law, which varies
from State-to-State, generally concerns
the liability of designers, manufacturers
and distributors for harm caused to
consumers and bystanders by
‘‘defective’’ or ‘‘unreasonably
dangerous’’ products.333 The purpose of
these laws is:
. . . to ensure that the costs of injuries
resulting from defective products are
borne by those who placed the defective
products in the market, rather than the
injured person. Thus, in an effort to
encourage the development of safer
products, the responsibility for the
injuries caused by defective products is
333 Dykema
PO 00000
at 9–10.
Frm 00115
Fmt 4701
Sfmt 4702
3967
placed on those who are in the best
position to guard against defects and
warn of their potential dangers.334
There is a broad range of product
liability theories and defenses that
could be applicable to liability litigation
involving the V2V System. For purposes
of this discussion, we focus on the
product liability theory of ‘‘failure to
warn,’’ which the Alliance, Mr. Dennis,
and Mercedes Benz raised in their
respective comments. A ‘‘failure to
warn’’ claim is based on the theory that
even a properly designed and
manufactured product may be defective
as a result of its manufacturer’s failure
to warn consumers of any dangerous
characteristics in its product about
which it knows or should know and
which the user of the product would not
ordinarily discover.335 There are four
basic elements of a ‘‘failure to warn’’
claim:
1. The manufacturer knew or should
have known of the risks inherent in the
product;
2. There was no warning, or the
warning provided was inadequate;
3. The absence of a warning made the
product unreasonably dangerous; and
4. The failure to warn was the causein-fact or proximate cause of the
plaintiff’s injury.336
To avoid liability for failure to warn,
a product’s instructions or warnings
must sufficiently alert the user to the
possibility of danger.337
The Alliance, Mr. Dennis, and
Mercedes-Benz all took the position that
the cooperative nature of V2V safety
warnings and the external data sources
on which V2V warnings are based
change the fundamental nature of
‘‘failure to warn’’ claims and make them
more complex.338 It is possible—
perhaps even likely—that the factual
inquiry underlying a failure to warn
claim will be more complex in the
context of a V2V System than it would
be in the context of a vehicle-based
warning system. Additionally, not just
message quality and timing (as noted by
Mercedes-Benz), but a vehicle’s
operating environment (roadway,
topographic and environmental factors)
may adversely affect the performance of
a consumer’s V2V System. For these
reasons, manufacturers’ consumer
warnings and instructions will be
particularly critical to the successful
defense of V2V failure claims. As they
have done in the context of new safety
technologies such as lane-departure
334 Dykema
at 9–10.
at 13.
336 Dykema at 13.
337 Dykema at 13.
338 Alliance at 18.
335 Dykema
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
3968
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
warning, backover-detection warnings
and forward vehicle detection systems,
manufacturers will need to carefully
describe the operation and limitations of
V2V and V2I Systems in the safety
context and in the foreseeable operating
environment.339 NHTSA expects that,
by appropriately warning consumers of
the uses and limitations of their V2V
System, automobile manufacturers can
sufficiently limit their liability for
failure to warn claims, despite
operational differences between onboard and V2V safety warning
technologies.
In the context of V2V OBE failure
claims, it also may be quite difficult for
consumers to prove that a vehicle’s V2V
equipment caused or contributed to an
accident. However, to the extent that the
V2V communications proposed in this
rule are used as a warning system, not
a control system, then, as with existing
vehicle-based warning systems, the V2V
System is an aid to help drivers safely
operate their vehicles. As discussed in
varying places in this NPRM and the
accompanying PRIA, at this time,
NHTSA does not assume that V2V
communications will be used as the sole
basis for any safety system that exercises
actual control of the vehicle. Thus, we
assume that any liability concerns
related to safety systems that do take
control of the vehicle will not be
affected by the presence of V2V.
In its comment, the Alliance stated
that ‘‘conclusions about the
applicability of the state of the law with
respect to traditional failure to warn
claims involving on-board warning
technologies grossly oversimplifies the
way such claims are likely to evolve in
the V2X litigation.’’ 340 We agree that it
is difficult for NHTSA (or anyone) to
know exactly how products liability
litigation will evolve in the context of
V2V, V2I and V2X communications.
However, NHTSA’s assessment of
potential V2V liability to date has been
based, in part, on risk analyses
conducted by Dykema PLLC. Dykema is
a Detroit-based law firm that specializes
in automotive-related legal issues and
provides legal services to many major
automobile manufacturers. It is also the
firm that the VIIC selected as its
subcontractor to analyze and report on,
among other legal policy topics,
potential V2V-related liability risks to
automobile manufacturers and public
sector entities under a cooperative
agreement with DOT. That said, the
agency welcomes and will carefully
consider the content of submissions of
other legally substantive risk analyses in
response to its proposal. NHTSA
received no such analyses in response to
the Readiness Report and ANPRM,
including from the Alliance or any
foreign or domestic automobile
manufacturers.
On a related note, the Alliance
commented that NHTSA’s reliance on
Dykema’s OEM Risk Assessment Report
is misplaced, as that report assumes that
a public or quasi-public entity will run
V2V infrastructure when NHTSA
assumes that the SCMS will be private.
NHTSA respectfully disagrees with the
Alliance on this point. Dykema’s OEM
Report contains no assumptions,
explicit or implied, that would limit the
utility or applicability of its analysis of
OEM risk for V2V-related product
liability claims. Additionally, with
respect to infrastructure-based liability
claims, the report specifically notes,
without limitation and without
referencing public ownership of such
infrastructure, that ‘‘[a]lthough the
structure of VII described herein focuses
on a hypothetical DSRC-enabled system,
the analysis and conclusions in this
deliverable generally will apply to any
VII network that communicates
information V2V or V2I.’’ 341
Dykema’s OEM Report also notes that
a lawsuit might allege that a crash was
caused, in whole or in part, by a failure
in the communications infrastructure
supporting V2V (e.g., an RSE). However,
as evidenced by the numerous lawsuits
claiming that failure of a traffic light
contributed to an accident, such cases
typically are brought against public or
quasi-public entities and not against
vehicle manufacturers.342 For this
reason, Dykema concluded (and NHTSA
agrees) that ‘‘we would not expect
alleged failures in V2V infrastructure to
impact OEM liability in a significant
way.’’ 343
(b) Potential Liability Risks to SCMS
Owners and Operators
From NHTSA’s perspective, the
critical policy issues in the SCMS
context are whether concerns about
liability will be a stumbling block to
creation and operation of a private
SCMS—and, if so, whether a need exists
for DOT to work with stakeholders to
develop Federal liability-limiting
options that would incentivize private
participation in a National SCMS.
In the Readiness Report (as in
Proposal A in this document), NHTSA
focused on a private model of SCMS
governance that did not involve Federal
funds or liability protections —but
341 Dykema
339 Dykema
340 Alliance
at 4.
342 Dykema at 33.
343 Dykema at 33.
at 35.
at 8.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00116
Fmt 4701
instead functioned through industry
self-governance by an SCMS Manager
that would work with SCMS entities to
determine the appropriate distribution
of liability for harm and establish
minimum insurance requirements. In
response, commenters such as the
Alliance took the position that private
insurance would not necessarily be
available to cover entities involved in
the SCMS since no claims data existed
yet on which to base underwriting
estimates, citing cybersecurity insurance
as an example of another area where the
insurance industry has been unwilling
or hesitant to provide insurance.
The agency acknowledges that SCMS
entities may not be able to obtain
adequate liability insurance without
Federal intervention of some sort—but it
is simply too early to tell. As we noted
in the Readiness Report, the extent to
which the primary and secondary
insurance markets will make insurance
coverage available to SCMS entities will
be a factor in whether DOT supports
development of liability-limiting
mechanism to incentivize private SCMS
participants. To this end, the agency
expects that the issue of liability as a
potential impediment to the
establishment of a National SCMS will
be among the issues that NHTSA and
V2V stakeholders continue to grapple
with going forward—and one that DOT’s
planned PKI and organizational policy
research will explore fully (including
through consultations with the
insurance and reinsurance industries).
However, due to the lack of substantive
evidence that the private insurance
market is unwilling to underwrite SCMS
risks, NHTSA continues to believe that
it is premature to take a position on the
need to develop and advocate for
Federal liability-limiting mechanisms
for a National SCMS.
The agency also is of the view that
potential liability based on failures in
the SCMS may be limited substantially
by lack of causation due to drivers’ roles
in failing to avoid crashes. However,
NHTSA wishes to clarify a comment in
the Readiness Report relating to
limitations on consumer liability—
specifically, the statement that:
It also is not clear to the agency why an
SCMS Manager could not require that
individuals and entities participating in an
SCMS to agree to terms of use that would
limit the liability of the SCMS and its
component entities, either explicitly or via
the same type of instructions and
explanations of system limitations that the
OEMs would use to limit liability.344
In its comment, the Alliance noted
that NHTSA appeared to be promoting
344 Readiness
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
Report at 214.
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
the use of liability limitations in terms
of use agreements with consumers,
which can be legally problematic and,
generally, are disfavored by courts.345
To clarify, NHTSA does not sanction the
use coercive liability limitation
provisions in agreements between
SCMS entities and consumers. As the
Alliance noted ‘‘such clauses can be
effective in allocating risk among
businesses’’ and the application of such
clauses should be limited to entities
doing business with SCMS components,
not consumers.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
VII. Estimated Costs and Benefits
A. General Approach to Costs and
Benefits Estimates
In this NPRM, the agency proposes
that all light vehicles be equipped with
technology that allows for V2V
communications. The agency believes
that this technology will facilitate the
‘‘free-market’’ development of various
applications; both safety and non-safety
related that would not be possible
without a network of devices ‘‘talking’’
to each other.
However, at this time, the agency has
decided to mandate V2V technology,
but not mandate any specific
applications. The agency believes this is
the appropriate course for several
reasons. First and foremost being that
the agency believes V2V
communication’s cooperative nature
needs a government mandate as the
‘‘spark’’ to establish a shared ‘‘open’’
platform that can be utilized to move
this technology into the mainstream
while not stifling potential, unforeseen
innovations. In addition, the agency
does not currently possess sufficient
information to mandate particular safety
applications, although, throughout this
NPRM, we request additional
information that could inform a
potential decision to mandate certain
applications.
This free-market approach to app
development and deployment, though,
makes estimating the potential benefits
of V2V quite difficult. In a traditional
NHTSA analysis of a safety technology,
the agency would determine benefits by
looking to the target population for the
type of crash it is trying to avoid or
mitigate and the effectiveness of the
mandated performance requirement or
safety technology in addressing those
crashes. However, here, the technology
being mandated by the agency, V2V
communication, would only indirectly
create safety benefits. Widespread
adoption of V2V would facilitate the
development of new safety applications
345 Alliance,
VerDate Sep<11>2014
Attachment B at 3.
23:49 Jan 11, 2017
Jkt 241001
that would not be possible otherwise, as
well as help improve the performance of
safety applications that already exist
based on cameras or sensors. Further,
V2V technology is expected to speed-up
the deployment of various V2I
technologies, which could have
significant safety and congestion-relief
applications.
The agency is confident that these
technologies will be developed and
deployed once V2V communications are
mandated. The difficulty, though, is that
the agency does not currently have
sufficient information to definitively
predict how or when this will occur.
Thus, the agency has projected an
adoption period based upon research
conducted on the deployment of other
advanced technologies as well as other
information obtained during the
development of this proposed rule. In
addition, the agency demonstrates the
potential safety benefits by analyzing
two safety applications, IMA and LTA,
both of which the agency believes are
likely to lead to significant safety
benefits that are likely only possible
using V2V technology. The agency has
therefore not quantified any benefits
attributable to the range of other
potential uses of V2V, although we
acknowledge that such uses are likely to
exist. The agency believes that, by
focusing on only two of the many
potential uses of V2V technology and
given our experience with other
technologies, we have taken a
reasonable approach in estimating the
potential benefits of the proposed rule
and have likely understated the. The
agency, though, requests comments on
these assumptions to better inform the
analysis that would support a final rule.
Is there more detailed information
concerning manufacturer’s plans to
reduce safety impacts associated with
widespread adoption of V2V technology
applications? If so, what applications
and on what timeline?
B. Quantified Costs
The agency was able to use
information obtained from the V2V
Readiness Report in developing the cost
estimates in this proposal. Where
appropriate, the V2V Readiness Report
cost estimates were adjusted to align
with any new information obtained by
the agency such as: That provided
through comments to the V2V ANPRM,
experience from the SCMS RFI activity,
and by developing the proposed
performance requirements.
The costs and benefits are presented
in two measures: Annual and by model
year (MY) vehicles (MY costs). The
annual costs represent the yearly
financial commitment while the MY
PO 00000
Frm 00117
Fmt 4701
Sfmt 4702
3969
costs represent the total investment born
by the indicated MY vehicle, plus the
lifetime fuel economy impact from those
vehicles. In either accounting measure,
the vehicle equipment, communication,
and SCMS costs are assumed to be paid
by new vehicle owners when their
vehicles were purchased. The only
difference between the two cost
measures is the calculation of any
potential fuel economy impact. The
annual fuel economy impact measures
the collective fuel impact from all V2Vequipped vehicles for a specific
calendar year. In contrast, the lifetime
fuel economy impact measures the fuel
impact specifically for a MY vehicle
through its operational life. All cost
estimates are adjusted for 2014 dollars.
For this analysis, the agency is
considering two potential technology
implementation approaches that could
meet the safety, security, and privacy
specifications of the proposed rule.
These two approaches are (1) utilizing
one DSRC radio dedicated to V2V safety
communications paired with secondary
cellular, Wi-Fi, or Satellite
communications (‘‘one-radio’’ approach)
and (2) utilizing two DSRC radios, one
dedicated to V2V safety
communications and one used for
secondary communications such as
SCMS or other ‘‘back office’’ type
communications (two-radio approach).
As a result, both the annual and MY
costs are presented as a range which
covers the costs from these two
approaches.
The following sections describe the
four parts of quantified costs, followed
by the summary of the total quantified
costs and non-quantified costs, and
estimated cost per vehicle. This
normalized per vehicle cost allows a
straightforward comparison between
various technology approaches and
regulatory alternatives. All costs were
estimated under the DSRC and app sales
scenario specified in the Estimated
Benefits portion of this chapter—
Section VII.D.
1. Component Costs
(a) Unit Costs to OEMS
As shown in Table VII–1, the total
direct component costs to OEMs were
estimated to be $162.77 for one DSRC
radio and $229.91 for two radios. The
total weight of one DSRC radio is
approximately 2.91 lbs. whereas the
weight of two radios is slightly heavier,
about 3.23 lbs. For the two-radio
approach, as previously discussed, two
DSRC antennas are necessary: The first
DSRC radio sends and receives the
BSM, and the second radio handles
security aspects of receiving certificates,
E:\FR\FM\12JAP2.SGM
12JAP2
3970
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
the certificate revocation list, etc. We
estimated that the second radio will be
$10.33 346 cheaper than the first radio
since these two radios would most
likely be packaged together, thereby
resulting in lower labor costs in
assembling the combined package at the
supplier, as well as lower hardware
costs in packaging them together rather
than individually. Therefore, the cost
for two radios would be $134.29 (=
$72.31 * 2 ¥ $10.33) instead of $144.64
(= $72.32 * 2), as shown in Table VII–
1. No such assumption was made for the
antenna, since the antennas have to
remain physically separate in order to
avoid interfering with each other.
TABLE VII–1—ESTIMATED COMPONENT UNIT WEIGHT AND COSTS TO OEMS
Costs
One radio
Component
Two radios
Weight
(lbs)
DSRC Transmitter/Receiver ................................................
DSRC Antenna ....................................................................
Electronic Control Unit .........................................................
GPS ......................................................................................
GPS Antenna .......................................................................
Wiring ...................................................................................
Displays ................................................................................
HSM .....................................................................................
For 2 Apps ...........................................................................
70
5
45
14
4
9
4.79
........................
........................
0.55
0.22
0.55
........................
0.22
1.20
0.17
0.00
0.00
72.31
5.17
46.49
14.46
4.13
9.30
4.95
4.65
1.32
0.65
0.44
0.55
........................
0.22
1.20
0.17
0.00
0.00
134.29
10.33
46.49
14.46
4.13
9.30
4.95
4.65
1.32
Total ..............................................................................
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(2012 $)
151.79
2.91
162.77
3.23
229.91
Overall, for this analysis the vehicle
equipment costs are based on an OEM
integrated device built into vehicles
during their manufacture. This example
device includes the costs of DSRC
radios, DSRC antenna, GPS, HSM, and
installation of relevant equipment
(DSRC radios in short) and loaded with
two safety applications. With specific
regard to the safety applications, the app
costs include software engineering and
development costs since the agency is
not assuming any additional interface
beyond the DVI or equipment costs for
the apps. The software engineering and
development costs will be shared by
millions vehicles, and thus is expected
to be minimal across the fleet. The OEM
integrated device is used as a basis for
cost estimation as this device type
provides a more accurate cost
expectation associated with finalizing
this proposal.
The agency also estimated potential
costs for aftermarket devices that could
enter the marketplace as a result of
finalizing this proposal and enabling
more consumers to benefit from V2V
technology. As described elsewhere,
aftermarket devices could be available
in three distinct varieties: Retrofit,
standalone, and a simple awareness
device. The agency estimates that the
three aftermarket device types would
cost $400.28 for a retrofit device;
$278.33 for a standalone device, and
$101.74 for a simple awareness device.
(b) Consumer Costs
The costs in Table VII–2 reflect the
costs that OEMs pay to a component
(Tier 1) supplier to purchase these
components for the vehicles they
manufacture, not the projected cost of
these systems to consumers. To obtain
the consumer costs, each variable cost is
multiplied by 1.51 (i.e., 51 percent
makeup) to estimate a retail price
equivalent (RPE; i.e., consumer cost).
The 51 percent markup represents fixed
costs (research and development, selling
and administrative costs, etc.), as well
as OEM profits, transportation costs,
and dealer costs and profits. Table
VII–2 presents the component consumer
costs. As shown, the total component
costs to consumers were estimated to be
$245.79 for one radio and $347.18 for
two radios.
Costs
(2014 $)
23:49 Jan 11, 2017
Jkt 241001
Costs
(2014 $)
TABLE VII–2—ESTIMATED COMPONENT
CONSUMER UNIT COSTS—Continued
[2014 $]
Component
One
radio
Two
radios
HSM ..............................
Two Safety Applications
7.02
2.00
7.02
2.00
Total ..........................
245.79
347.18
(c) Installation Costs
Component installation costs are
primarily attributable to the labor
needed to perform the installation, but
the agency also accounts for potential,
additional costs associated with
materials used in the installation such
as minor attachments brackets, or
plastic tie downs to secure wires, etc. In
Table VII–3, the installation costs are
TABLE VII–2—ESTIMATED COMPONENT separated into ‘‘Material Costs’’ (for the
minor attachments), ‘‘Labor Costs,’’ and
CONSUMER UNIT COSTS
‘‘Variable Burden’’ (i.e., other costs that
[2014 $]
are not direct labor or direct material
used in the part, but are costs that vary
One
Two
Component
radio
radios
with the level of production, such as
set-up costs, in-bound freight,
DSRC Transmitter/Reperishable production tools, and
ceiver ......................... $109.19 $202.78 electricity). Overall, the agency
DSRC Antenna .............
7.80
15.60
estimates the variable cost to OEMs to
Electronic Control Unit ..
70.19
70.19
GPS ..............................
21.84
21.84 install the V2V equipment is $11.79 per
GPS Antenna ................
6.24
6.24 vehicle and the cost to consumers will
Wiring ............................
14.04
14.04 be $17.80 using a 1.51 retail price
Displays ........................
7.47
7.47 equivalent factor (e.g. markup).
346 Adjusted from the $10 in 2011 dollars that was
estimated in the ANPRM.
VerDate Sep<11>2014
Weight
(lbs)
PO 00000
Frm 00118
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
3971
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–3—CONSUMER INSTALLATION COST ESTIMATES
[2014 dollars]
Part
Material
Labor
Variable
Total
consumer
Total
DSRC Transmitter/Receiver ................................................
DSRC Antenna ....................................................................
Electronic Control Unit .........................................................
GPS ......................................................................................
GPS Antenna .......................................................................
Wiring ...................................................................................
LEDs (5) Displays + Malfunction Disp. ................................
Light Bar ...............................................................................
HSM .....................................................................................
0.04
0.04
0.02
0.04
0.04
0.19
0.00
0.04
0.00
1.61
0.10
1.84
0.10
0.10
0.93
0.63
1.61
0.00
1.04
0.07
1.19
0.07
0.07
0.60
0.40
1.04
0.00
2.69
0.21
3.05
0.21
0.21
1.72
1.03
2.69
0.00
4.06
0.31
4.60
0.31
0.31
2.59
1.56
4.06
0.00
Total ..............................................................................
0.38
6.92
4.48
11.79
17.80
(d) Adjustment for GPS Installation
When researching installation costs,
the agency identified the need to make
adjustments for GPS installation. Today,
many vehicles are already equipped
with GPS receivers and the percentage
equipped as standard installation is
likely to increase going forward. The
agency estimates approximately 43
percent of MY 2013 light vehicles were
equipped with GPS receivers.347 This
percentage increases to approximately
50 percent when combined with the
number of vehicles equipped with
automatic collision notification (ACN).
Current information available to the
agency indicates that navigation-grade
GPS units are sufficient for the V2V
safety applications. In these cases, the
GPS component is not a cost that is
directly attributable to V2V. Overall, 50
percent of applicable vehicles would
not incur costs to add GPS for V2V
technology. Thus, the total cost
associated with vehicles equipped with
GPS (i.e., 50%) was subtracted from the
total costs of equipping all applicable
vehicles with V2V safety applications.
(e) Summary of Component Costs
Table VII–4 summarizes consumer
costs for original equipment
manufacturers (OEMs) for the first year
of equipping a vehicle with V2V
components. The consumer unit cost is
estimated to be $249.19 for one radio
and $350.57 for two radios in 2014
dollars.
TABLE VII–4—SUMMARY OF V2V COMPONENT CONSUMER COSTS PER AFFECTED VEHICLE
Cost
One radio
Weight
(lb.)
Items
Two-radios
Consumer
costs
Weight
(lb.)
Consumer
costs
Parts * ...............................................................................................................
Installation ........................................................................................................
2.91
0.26
$245.79
17.74
3.23
0.26
$347.18
17.74
Subtotal .....................................................................................................
Minus Current GPS Installation** ....................................................................
3.17
0.11
263.53
14.35
3.49
0.11
364.92
14.35
Total ..........................................................................................................
3.06
249.18
3.38
350.57
* including app software costs.
** taking into account the 50 percent GPS installation rate.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(f) Learning Curve Effect
As manufacturers gain experience
through production of the same product,
they refine production techniques,
better manage raw material and
component sources, and assembly
methods to maximize efficiency and
thus reduce production unit costs.
Learning curves reflect the impact of
experience and volume on the cost of
production and are especially evident
when a completely new product is
introduced to the marketplace. V2V
systems are expected to be installed on
a growing portion of the vehicle fleet as
manufacturers ramp up to the meet the
proposed rule which would require
100% new vehicle installation by 2023,
which is projected to be over 16 million
units annually. This large scale
production provides manufacturers with
opportunities to reduce system costs
through the learning process. Additional
information on the agency’s learning
curve development and the derivation
for learning curves related to V2V are
detailed in Chapter 7 of the PRIA that
accompanies this proposed rule.
NHTSA routinely performs
evaluations of the costs and benefits of
safety standards that were previously
issued in an effort to estimate learning
curve impacts, among other economic
impacts, and provide the most accurate
possible information at the time a rule
is proposed and finalized. To estimate
costs, the agency conducts a teardown
study of the technologies used to meet
the standards. In some cases, the agency
has performed multiple evaluations over
a span of years. For example, a
teardown study may be performed to
support the agency’s initial estimates of
costs that will result from the
regulation, and again five years later to
evaluate the impacts of the regulation
after it has been in effect. These data,
together with actual production data,
347 Ward’s Automotive Yearbook 2014, based on
vehicles with factory-installed navigation systems
or concierge systems.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00119
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
3972
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
supply the necessary information
required to develop a learning curve for
the technology.
For V2V, the agency estimates that
learning would reduce the unit cost for
two radio implementations, including
two safety applications, from
approximately $350.57 in 2021 to
$218.85 in 2060, which is about 62.5
percent. Applying the same learning
pattern, the unit cost for a one radio
system would decrease it from $249.18
in 2021 to $155.47 in 2060. Details of
how learning would affect unit costs for
both one to two radio implementations
can be found in Table VII–5.
TABLE VII–5—ANNUAL PROGRESS RATES AND COMPONENT UNIT COSTS AFTER LEARNING
Year
1 .......................................
2 .......................................
3 .......................................
4 .......................................
5 .......................................
6 .......................................
7 .......................................
8 .......................................
9 .......................................
10 .....................................
11 .....................................
12 .....................................
13 .....................................
14 .....................................
15 .....................................
16 .....................................
17 .....................................
18 .....................................
19 .....................................
20 .....................................
21 .....................................
22 .....................................
23 .....................................
24 .....................................
25 .....................................
26 .....................................
27 .....................................
28 .....................................
29 .....................................
30 .....................................
31 .....................................
32 .....................................
33 .....................................
34 .....................................
35 .....................................
36 .....................................
37 .....................................
38 .....................................
39 .....................................
40 .....................................
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Progress rates
Calendar
year
Radio
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
Apps
1.000
0.908
0.853
0.821
0.798
0.780
0.766
0.754
0.743
0.734
0.726
0.719
0.712
0.706
0.700
0.695
0.690
0.685
0.681
0.677
0.673
0.669
0.666
0.663
0.660
0.657
0.654
0.651
0.649
0.646
0.644
0.641
0.639
0.637
0.635
0.633
0.631
0.629
0.627
0.625
Table VII–6 summarizes the total
annual vehicle component costs. As
shown, total annual vehicle component
costs would range from $2.0 billion to
$4.9 billion. The cost per vehicle would
range from $123.59 to $297.65. The
lower bound is for one radio at year
2021 and the higher bound is the cost
for two radios in 2023. In 2023, 100
percent of vehicles would be required to
be equipped with the DSRC radios and
Unit costs
1.000
1.000
0.872
0.782
0.726
0.681
0.647
0.623
0.606
0.593
0.582
0.573
0.565
0.558
0.552
0.546
0.541
0.537
0.532
0.528
0.525
0.521
0.518
0.515
0.512
0.509
0.507
0.504
0.502
0.500
0.498
0.496
0.494
0.492
0.490
0.488
0.486
0.485
0.483
0.482
1 Radio
2 Radio
$247.18
224.44
210.95
202.91
197.21
192.83
189.27
186.28
183.71
181.45
179.44
177.62
175.98
174.47
173.07
171.77
170.56
169.42
168.35
167.33
166.37
165.48
164.64
163.84
163.07
162.33
161.63
160.95
160.30
159.67
159.07
158.48
157.93
157.39
156.87
156.36
155.88
155.41
154.95
154.51
(g) Annual Component Costs
Table VII–6 presented below the cost
per vehicle is the average cost spread
PO 00000
Frm 00120
Fmt 4701
Sfmt 4702
Apps
$348.57
316.50
297.47
286.14
278.10
271.93
266.91
262.69
259.07
255.88
253.04
250.48
248.16
246.03
244.06
242.23
240.52
238.92
237.40
235.97
234.61
233.36
232.17
231.04
229.96
228.92
227.93
226.97
226.05
225.16
224.31
223.49
222.70
221.94
221.21
220.50
219.82
219.15
218.51
217.89
more vehicles would be expected to
have apps. Although the projected
number of new vehicles that would
have DSRC radios and safety
applications continues to increase after
2023, the additional costs are offset by
the falling component costs.
Total unit costs
$2.00
2.00
1.74
1.56
1.45
1.36
1.29
1.25
1.21
1.19
1.16
1.15
1.13
1.12
1.10
1.09
1.08
1.07
1.06
1.06
1.05
1.04
1.04
1.03
1.02
1.02
1.01
1.01
1.00
1.00
1.00
0.99
0.99
0.98
0.98
0.98
0.97
0.97
0.97
0.96
1 Radio
$249.18
226.44
212.69
204.47
198.66
194.19
190.57
187.53
184.92
182.63
180.60
178.77
177.11
175.58
174.17
172.87
171.64
170.49
169.41
168.39
167.42
166.52
165.68
164.87
164.09
163.35
162.64
161.96
161.30
160.67
160.06
159.48
158.91
158.37
157.85
157.34
156.85
156.38
155.92
155.47
2 Radios
$350.57
318.50
299.22
287.70
279.56
273.29
268.21
263.94
260.28
257.06
254.20
251.63
249.29
247.15
245.17
243.32
241.60
239.99
238.47
237.03
235.66
234.40
233.21
232.07
230.98
229.94
228.94
227.98
227.05
226.16
225.31
224.48
223.69
222.93
222.19
221.48
220.79
220.12
219.48
218.85
across all new vehicles, not just affected
vehicles. Due to the proposed phase-in
schedule, the cost per vehicle in 2021
and 2022 is significantly lower than the
unit cost shown in Table VII–5.
Furthermore, the agency predicts
complete safety application deployment
would not be achieved until 2028,
resulting in a slightly lower cost per
vehicle for 2023 to 2027 than that
shown in Table VII–2.
E:\FR\FM\12JAP2.SGM
12JAP2
3973
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–6—TOTAL ANNUAL VEHICLE COMPONENT COSTS
[2014 $ and vehicles in millions]
Year
Vehicles
with
Calendar year
Radios
1 ...................................
2 ...................................
3 ...................................
4 ...................................
5 ...................................
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
12 .................................
13 .................................
14 .................................
15 .................................
16 .................................
17 .................................
18 .................................
19 .................................
20 .................................
21 .................................
22 .................................
23 .................................
24 .................................
25 .................................
26 .................................
27 .................................
28 .................................
29 .................................
30 .................................
31 .................................
32 .................................
33 .................................
34 .................................
35 .................................
36 .................................
37 .................................
38 .................................
39 .................................
40 .................................
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(a) Methodology
The communication cost estimates are
based on the same model created by
Booz Allen Hamilton under the contract
with the DOT’s Intelligent
Transportation Systems Joint Program
and used for the V2V Readiness Report.
The model, Cost Model for
Communications Data Delivery System
(CDDS), is a Microsoft Excel-based
model.348
The communication cost estimates
include the cost of in-vehicle
communication components and any
service fee that would be required with
a specific communication network. For
system design, four communication
network technologies were evaluated for
the CDDS: cellular, Wi-Fi, Satellite, and
348 Docket
No. NHTSA–2014–0022.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
Apps
8.10
12.26
16.44
16.53
16.67
16.75
16.88
17.03
17.13
17.30
17.44
17.56
17.67
17.84
18.00
18.16
18.34
18.49
18.66
18.87
19.14
18.56
18.66
18.76
18.87
18.97
19.08
19.18
19.28
19.39
19.39
19.39
19.39
19.39
19.39
19.39
19.39
19.39
19.39
19.39
2. Communication Costs
Total costs
(Radios + Apps)
1 Radio
0.00
0.61
1.64
4.13
6.67
10.89
15.19
17.03
17.13
17.30
17.44
17.56
17.67
17.84
18.00
18.16
18.34
18.49
18.66
18.87
19.14
18.56
18.66
18.76
18.87
18.97
19.08
19.18
19.28
19.39
19.39
19.39
19.39
19.39
19.39
19.39
19.39
19.39
19.39
19.39
$2,000.92
2,751.72
3,470.84
3,360.54
3,297.19
3,244.74
3,214.60
3,193.60
3,167.72
3,159.58
3,149.66
3,139.20
3,129.51
3,132.41
3,135.14
3,139.24
3,147.91
3,152.45
3,161.27
3,177.54
3,204.34
3,090.70
3,091.52
3,092.91
3,096.45
3,098.81
3,103.22
3,106.39
3,109.91
3,115.37
3,103.57
3,092.23
3,081.32
3,070.79
3,060.63
3,050.82
3,041.33
3,032.14
3,023.24
3,014.60
DSRC. The four technologies can be
combined in various ways to form the
communication system to support the
vehicle to SCMS communication
activities. The CDDS report and various
cost estimates were published in the
V2V Readiness Report and referenced
specifically in the ANPRM in an effort
to gather feedback on the estimated
costs.
In response to the V2V ANPRM, and
the Request for Interest (RFI) regarding
the SCMS, the agency received
information and feedback on cellular
and satellite and how these technologies
can support national V2V
deployment.349 These new findings led
the agency to conclude that two systems
can meet the proposed security
requirements:
349 Docket
PO 00000
No. NHTSA–2014–0023.
Frm 00121
Fmt 4701
Sfmt 4702
Cost per
vehicle
2 Radios
$2,821.67
3,879.94
4,893.35
4,736.34
4,645.68
4,569.60
4,525.12
4,494.87
4,458.56
4,447.19
4,433.29
4,418.61
4,405.01
4,409.12
4,412.99
4,418.78
4,431.00
4,437.40
4,449.84
4,472.75
4,510.49
4,350.52
4,351.69
4,353.66
4,358.65
4,361.98
4,368.19
4,372.65
4,377.61
4,385.30
4,368.70
4,352.74
4,337.38
4,322.57
4,308.27
4,294.46
4,281.11
4,268.17
4,255.64
4,243.49
1 Radio
$123.59
168.40
211.12
203.30
197.79
193.72
190.44
187.53
184.92
182.63
180.60
178.77
177.11
175.58
174.17
172.87
171.64
170.49
169.41
168.39
167.42
166.52
165.68
164.87
164.09
163.35
162.64
161.96
161.30
160.67
160.06
159.48
158.91
158.37
157.85
157.34
156.85
156.38
155.92
155.47
2 Radios
$174.29
237.45
297.65
286.53
278.68
272.81
268.08
263.94
260.28
257.06
254.20
251.63
249.29
247.15
245.17
243.32
241.60
239.99
238.47
237.03
235.66
234.40
233.21
232.07
230.98
229.94
228.94
227.98
227.05
226.16
225.31
224.48
223.69
222.93
222.19
221.48
220.79
220.12
219.48
218.85
• Hybrid—This system would use
cellular, Wi-Fi, and satellite for vehicles
to SCMS communication.
• DSRC—This protocol would use
DSRC exclusively for V2V
communications and for vehicles to
SCMS communications through
Roadside Equipment (RSE).
The hybrid system allows for the
potential use of the three
communication mediums cellular, WiFi, and satellite. Each serves as a
complement system to the other. In an
effort to address potential security
concerns, the agency added the cost of
an in-vehicle hardware security module
(HSM). The HSM, based on agency
conversations with security experts, can
potentially address the over-the -air
communication security issues.
Furthermore, the agency also recognized
that satellite communication will not be
E:\FR\FM\12JAP2.SGM
12JAP2
3974
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
strategic highways, major network
connectors, and intermodal connectors.
BAH then used spatial optimization
and information from the 2009 National
Household Transportation Survey
(NHTS) to estimate the required number
of RSE to achieve the desired amount of
coverage. The usage of NHS roads (with
19,749 sites) was deemed the most
logical because it achieves greater
coverage than the interstate option (with
8,880 sites) while also requiring fewer
RSE than secondary roads (with 149,434
sites) to achieve the same coverage, as
shown below in Figure VII–1. As
shown, NHS roads are the most realistic
scenario, though secondary roads could
achieve more coverage given more
resources. Ultimately, the NHS road
deployment method was deemed to be
the most realistic.
of a certificate revocation list. The cost
model also considered the costs that
relate to the three communication
technologies used in the Hybrid
approach: Cellular data rate, cellular
component cost in the vehicles, Wi-Fi
component costs, satellite data rate, and
satellite radio cost. It is also necessary
to consider the cost of road side units
for the DSRC-exclusive approach
system. The agency notes that while not
included in these estimates, there is
potential for road side unit costs to not
be borne solely by a V2V system. Road
side units may also be deployed in
accordance with guidance from the
Federal Highway Administration
(FHWA) as signaling and related traffic
control equipment undergoes normal
upgrades. Overall, unless otherwise
The agency applied the assumptions
used in the CDDS model to estimate
communication costs. These
comprehensive assumptions included
the length of initial new certificate
deployment period, the certificate
download size and frequency at the full
system deployment, the potential device
misbehavior rate, and the potential size
350 BAH CDDS Final Report, at 27. See Docket No.
NHTSA–2014–0022.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00122
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.017
two DSRC radios would be required for
this DSRC-exclusive communication
system.
BAH estimated the potential number
of RSUs needed to support a national
deployment. First, RSU deployment was
considered on three different road types:
secondary roads, interstate highways,
and National Highway System roads
(NHS). Each type is defined by BAH as
the following: 350
• Secondary roads refer to collector
roads, State highways, and county
highways that connect smaller towns,
subdivisions, and neighborhoods.
• Interstate highways are the network
of freeways that make up Dwight D.
Eisenhower National System of
Interstate and Defense Highways.
• The NHS roads are the collection of
interstate highways, principal arteries,
(b) Assumptions
srobinson on DSK5SPTVN1PROD with PROPOSALS2
as expensive as detailed in the BAH
estimates since 70 percent of light
vehicles are currently equipped satellite
radio receivers. Since only 30 percent of
vehicles will need satellite radio
receivers reduces the overall component
cost for satellite communication in
reduced increasing its viability.
A DSRC-exclusive system would
communicate with SCMS through RSUs,
small ‘‘base stations’’ that allow vehicles
to ‘‘phone home’’ using DSRC. A
separate DSRC antenna will be used
exclusively for communicating updates
ensuring continual ‘‘listening’’ for safety
component update related
communications,. This dedicated DSRC
communication channel would exist in
addition to the dedicated V2V safety
communications channel used for V2V
safety communications, and, therefore,
3975
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
stated, all cost calculations have been
made with the assumptions found in
Table VII–7 and are estimated for over
a 40-year timeframe. Additional details
on the communication cost assumptions
can be found the Chapter VII of the
PRIA. The agency requests comment on
these assumptions.
TABLE VII–7—COST ASSUMPTIONS BY COMMUNICATION OPTIONS
Cost factors
Component
Hybrid
DSRC
Certificate
Certificate Option
Certificate Phase-In Period
Certificate Download Frequency at Full Deployment
3,000 per bundle ...........
3 years ..........................
Every 3 years ................
3,000 per bundle.
3 years.
Every 3 years.
0.10% ............................
Satellite/Incremental ......
0.10%.
Incremental.
Misbehavior
Misbehavior Rate
CRL Type
Communication Technology
Cellular .................................
Wi-Fi .....................................
Satellite .................................
Three Above Combined .......
RSE ......................................
Cellular Data Price .....................................................
Cellular Component Cost Per Vehicle
Fraction of Data Shifted from Cellular
Wi-Fi Component Cost per Vehicle ...........................
Satellite Data Price .....................................................
Satellite Component Cost per Vehicle
Annual Technology Component Replacement Rate ..
RSE Component per Vehicle .....................................
# Nationwide RSEs
RSE Structure Supporting Cost
RSE Replacement Cost
RSE Installation Phase-in
RSE Life
(c) Hybrid Option Costs
The agency estimates the annual
overall costs for the Hybrid
communication option would range
from approximately $148 million in
Year 1 to approximately $490 million at
Year 40. On a per vehicle basis, this
equates to $9.18 in Year 1 to $25.47 after
40 years. The detailed estimated annual
communication costs are shown in
$4.00/GB .......................
$10.00 ...........................
67% ...............................
$2.00 .............................
$1.60/GB .......................
$6.00 .............................
2% .................................
NA .................................
NA .................................
NA .................................
NA .................................
16 years ........................
NA .................................
Table VII–8. The cost increase over time
represents the increases in certificate
distributions and SCMS
communications as fleet penetration
increases.
It is important to note the table
reflects zero satellite and cellular data
costs for the first three years. This zero
cost results from the assumption that
vehicles will be pre-loaded with three
years of security certificates, reflecting
NA.
NA.
NA.
NA.
NA.
NA.
NA.
Included in the DSRC radios.
19,750.
$8,839.
$22,719.
NA.
15 years.
that communication between vehicles
and SCMS will be very limited during
this time period. In addition, the
acknowledged certificate revocations
lists would be transmitted to vehicles
during this time but, overall, the
estimated misbehavior rate of 0.1
percent, combined with an anticipated,
small revocation list size, would not
have a substantive impact on
communication costs.
TABLE VII–8—ESTIMATED ANNUAL COMMUNICATION COSTS AND PER VEHICLE COSTS—HYBRID
Data cost
Year
Calendar year
RSE
OBE
Total
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Satellite
1 ...................................
2 ...................................
3 ...................................
4 ...................................
5 ...................................
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
12 .................................
13 .................................
14 .................................
15 .................................
16 .................................
17 .................................
18 .................................
19 .................................
20 .................................
VerDate Sep<11>2014
23:49 Jan 11, 2017
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
Jkt 241001
$0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
PO 00000
$148,624,200
213,159,926
309,000,919
316,361,705
324,585,446
331,663,749
339,583,781
347,798,557
355,008,739
363,357,905
370,982,194
378,019,671
384,620,645
392,045,404
399,021,900
405,714,525
412,479,551
418,390,535
424,344,445
430,726,546
Frm 00123
Fmt 4701
Sfmt 4702
$0
0
0
14,502
20,225
26,516
33,316
41,044
49,204
57,691
66,319
74,932
83,389
91,615
99,529
107,044
114,107
120,627
126,553
131,916
Cellular
$0
0
0
5,964,604
7,771,778
9,558,220
11,326,199
13,073,502
14,787,665
16,463,486
18,080,731
19,626,112
21,090,223
22,473,154
23,771,089
24,979,082
26,095,952
27,113,321
28,030,229
28,854,679
E:\FR\FM\12JAP2.SGM
12JAP2
$148,624,200
213,159,926
309,000,919
322,340,811
332,377,450
341,248,485
350,943,297
360,913,103
369,845,609
379,879,082
389,129,243
397,720,714
405,794,257
414,610,174
422,892,517
430,800,651
438,689,610
445,624,483
452,501,226
459,713,141
Cost per
vehicle
$9.18
13.05
18.80
19.50
19.94
20.37
20.79
21.19
21.59
21.96
22.31
22.65
22.97
23.24
23.49
23.72
23.92
24.10
24.25
24.36
3976
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–8—ESTIMATED ANNUAL COMMUNICATION COSTS AND PER VEHICLE COSTS—HYBRID—Continued
Data cost
Year
Calendar year
RSE
OBE
Total
Satellite
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
(d) DSRC Option Costs
Table VII–9 summarizes the estimated
annual communication costs for the
DSRC exclusive approach. Estimates for
this option show a range of $0 at Year
437,935,982
429,324,211
432,732,888
435,960,956
439,237,664
442,230,479
445,334,157
448,190,015
450,983,531
453,904,155
454,730,556
455,469,747
456,124,543
456,712,926
457,234,600
457,690,833
458,084,204
458,395,516
458,655,327
458,874,218
Cellular
136,760
140,688
144,189
147,346
150,263
153,002
155,668
158,253
160,763
163,206
165,503
167,722
169,851
171,880
173,792
175,587
177,260
178,752
180,143
181,461
1 increasing to an approximate $177
million annual average by Year 40.
When viewed from a per vehicle basis,
the costs range from $0 in the first year
to approximately $9 annual average in
the out years. An important note with
29,599,075
30,178,332
30,688,025
31,140,495
31,551,344
31,929,276
32,285,302
32,619,841
32,934,626
33,232,654
33,494,491
33,728,697
33,936,162
34,122,586
34,287,873
34,432,426
34,557,062
34,655,698
34,738,017
34,807,370
467,671,817
459,643,231
463,565,102
467,248,797
470,939,271
474,312,757
477,775,127
480,968,109
484,078,920
487,300,015
488,390,550
489,366,166
490,230,556
491,007,391
491,696,266
492,298,846
492,818,527
493,229,966
493,573,487
493,863,049
Cost per
vehicle
24.43
24.77
24.84
24.91
24.96
25.00
25.04
25.08
25.11
25.13
25.19
25.24
25.28
25.32
25.36
25.39
25.42
25.44
25.46
25.47
this communication option is the need
to include road side unit replacement
based on the assumed 15-year life of
span of this equipment, Years 19 and 34
reflect the annual cost of replacing this
equipment.
TABLE VII–9—ESTIMATED ANNUAL COMMUNICATION COSTS AND PER VEHICLE COSTS—DSRC
Data cost
Year
Calendar year
RSE
OBE
Total
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Satellite
1 ...................................
2 ...................................
3 ...................................
4 ...................................
5 ...................................
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
12 .................................
13 .................................
14 .................................
15 .................................
16 .................................
17 .................................
18 .................................
19 .................................
20 .................................
21 .................................
22 .................................
23 .................................
24 .................................
25 .................................
26 .................................
27 .................................
28 .................................
29 .................................
30 .................................
31 .................................
32 .................................
33 .................................
34 .................................
VerDate Sep<11>2014
23:49 Jan 11, 2017
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
Jkt 241001
$0
0
0
186,090,367
85,882,056
95,733,225
105,584,395
115,435,565
125,286,734
135,137,904
144,989,074
154,840,243
164,691,413
174,542,583
184,393,752
168,543,441
147,767,545
147,767,545
252,465,284
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
162,724,365
147,767,545
147,767,545
252,465,284
PO 00000
Frm 00124
$0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
Fmt 4701
Sfmt 4702
Cellular
$0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
E:\FR\FM\12JAP2.SGM
$0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
12JAP2
$0
0
0
186,090,367
85,882,056
95,733,225
105,584,395
115,435,565
125,286,734
135,137,904
144,989,074
154,840,243
164,691,413
174,542,583
184,393,752
168,543,441
147,767,545
147,767,545
252,465,284
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
162,724,365
147,767,545
147,767,545
252,465,284
Cost per
vehicle
$0.00
0.00
0.00
11.26
5.15
5.72
6.25
6.78
7.31
7.81
8.31
8.82
9.32
9.78
10.24
9.28
8.06
7.99
13.53
9.42
9.28
9.57
9.52
9.47
9.42
9.37
9.31
9.26
9.22
9.16
8.39
7.62
7.62
13.02
3977
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–9—ESTIMATED ANNUAL COMMUNICATION COSTS AND PER VEHICLE COSTS—DSRC—Continued
Data cost
Year
Calendar year
RSE
OBE
Total
Satellite
35
36
37
38
39
40
.................................
.................................
.................................
.................................
.................................
.................................
2055
2056
2057
2058
2059
2060
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
(e) Communication Cost Summary
Comparing the two communication
options evaluated in this proposal
yields a sharp cost difference between
the Hybrid and DSRC option, a
difference of approximately $325
million annually at full deployment.
Exploiting the ‘‘free’’ usage of the
allocated DSRC spectrum appears to
provide clear advantages to consumers
and the overall system sustainability.
Challenges deploying the approach,
however, are in the physical placement
of the road side units across the nation
in a timely manner. Leveraging the
existing cellular and satellite network
poses a clear advantage to accelerating
deployment in the fleet.
(f) Included SCMS Costs
The agency developed cost estimates
for a potential SCMS based on
additional research and modeling
conducted by BAH, like the CDDS
model used for communication cost
estimation. The agency determined that
it was appropriate to make some minor
adjustments to the cost model based on
updated information obtained between
development of the original model and
in preparation for this proposal. More
specifically, the agency updated the
model with changes to project salaries,
compensation costs, and by including
costs needed for establishing the SCMS
(Year 0).
0
0
0
0
0
0
Cellular
0
0
0
0
0
0
Salaries were revised using the most
current data from Occupational
Employment Statistics (OES) 351
published by the Bureau of Labor
Statistics (BLS) May 2014. In addition,
the agency mapped new/revised BLS job
categories to those originally used by
BAH. Compensation costs in the BAH
model were revised to align with newer
information indicating that the average
hourly wages for all workers in private
industry is $21.94 and the average total
benefit is $9.71, where the total benefits
are 44.3 percent of the wages.352 The
44.3 percentage is significantly higher
than the 25 percent used in the SCMS
cost model and the agency believed it
was appropriate to revised these values
to accurate reflect compensation values.
Finally, including Year 0 costs for the
SCMS added $20.8 million as a onetime cost. The Year 0 costs include the
design of the SCMS facilities, land
preparation, power source redundancy,
power line installation, and other
facility characteristics that are
necessary, and in some cases unique, for
a successful SCMS operation. This new,
added cost was amortized over 20 years
which the agency believes is reasonable
considering the long term commitment
associated with SCMS development and
operation.
To estimate the annual total costs for
the entire SCMS, the agency first
examined the costs for each of the 10
0
0
0
0
0
0
Cost per
vehicle
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
177,681,184
9.16
9.16
9.16
9.16
9.16
9.16
component functions of the SCMS. For
each function, the costs comprised five
expenditure categories: Hardware
Purchase, Software Purchase, Software
Operation and Maintenance (Q&M),
Initial Facility Costs, Annual Facility
Costs, and Full Time Equivalent (FTE)
Costs. The SCMS model identified
several locations that could be used to
establish an SCMS as a way to develop
facility cost averages. The averages are
based on six geographically and
demographically varying areas: Metro
DC, Richland, WA, Denver, CO,
Chicago, IL, San Antonio, TX, and
Gastonia, NC. The key cost components
evaluated are labor costs, energy costs,
land cost, and monthly rent.
Table VII–10 and Table VII–11 show
the estimated SCMS costs by specific
SCMS function, the total costs, and the
per vehicle cost. Any equipment related
costs are adjusted for learning. As
shown, the total estimated SCMS costs
range from $39.1 million in the first year
to $160.1 million in year 40 with per
vehicle cost ranging from $2.42 to $8.29.
The agency requests comment on its
assumptions concerning potential SCMS
costs. In particular, how would different
approaches to the design of the SCMS
affect the costs of operating the system?
In addition, how would the costs of the
SCMS be passed along to consumers?
TABLE VII–10—SCMS COSTS BY FUNCTION
Calendar
year
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Year
1 ...................................
2 ...................................
3 ...................................
4 ...................................
5 ...................................
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
351 MSA_M2014
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
23:49 Jan 11, 2017
Jkt 241001
RA
$4,708,025
4,672,050
4,677,281
4,687,633
6,728,645
4,724,254
4,744,931
4,765,448
4,785,584
10,510,180
9,308,218
File as May 2014, www.bls.gov/
oes.
VerDate Sep<11>2014
PCA
LA
$10,358,634
10,270,907
10,274,580
10,281,935
13,103,893
10,308,046
10,322,789
10,337,418
10,351,775
16,401,748
14,856,461
$987,277
988,020
990,346
995,076
1,740,502
1,011,781
1,021,213
1,030,571
1,039,756
4,799,128
9,073,569
352 Based on the News Release on, EMPLOYER
COSTS FOR EMPLOYEE COMPENSATION, March
2015 (2015 USDL–15–1132) Table 5 (page 10),
PO 00000
Frm 00125
Fmt 4701
Sfmt 4702
MA
LOP
$3,679,694
3,658,706
3,658,847
3,659,125
3,889,204
3,660,108
3,660,663
3,661,213
3,661,753
4,179,494
5,441,652
$2,332,410
2,311,587
2,312,044
2,312,536
2,771,798
2,313,639
2,314,203
2,314,761
2,315,308
3,682,299
4,543,859
ECA
$4,381,260
4,343,622
4,343,622
4,343,622
4,781,464
4,343,622
4,343,622
4,343,622
4,343,622
4,781,464
4,343,622
released June 10, 2015, https://www.bls.gov/
news.release/pdf/ecec.pdf.
E:\FR\FM\12JAP2.SGM
12JAP2
3978
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–10—SCMS COSTS BY FUNCTION—Continued
Calendar
year
Year
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
PCA
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
RA
9,327,079
9,345,391
9,363,032
14,419,003
9,395,586
9,410,421
9,424,185
9,436,904
18,633,720
13,918,676
13,927,310
13,935,979
13,943,871
22,174,444
13,955,521
13,960,466
13,964,937
13,969,051
26,815,885
18,425,034
18,428,332
18,431,447
18,434,213
28,781,702
18,438,804
18,440,716
18,442,316
18,443,789
31,518,164
LA
14,869,909
14,882,966
14,895,544
20,996,845
14,918,755
14,929,333
14,939,146
14,948,215
24,737,954
19,420,803
19,426,959
19,433,140
19,438,767
29,152,824
19,447,074
19,450,599
19,453,788
19,456,721
33,350,158
23,909,622
23,911,973
23,914,194
23,916,166
35,756,214
23,919,440
23,920,803
23,921,944
23,922,994
38,029,601
9,082,173
9,090,526
9,098,573
12,930,027
9,113,422
9,120,189
9,126,467
9,132,269
15,746,265
13,587,376
13,591,314
13,595,268
13,598,868
20,355,009
13,604,182
13,606,438
13,608,477
13,610,354
23,655,970
18,057,646
18,059,151
18,060,572
18,061,833
26,844,673
18,063,928
18,064,800
18,065,529
18,066,201
28,307,710
MA
LOP
5,442,159
5,442,650
5,443,123
5,772,704
5,443,997
5,444,395
5,444,764
5,445,106
6,126,542
7,223,691
7,223,922
7,224,155
7,224,367
7,633,697
7,224,679
7,224,812
7,224,932
7,225,042
8,045,813
9,002,835
9,002,923
9,003,007
9,003,081
9,423,600
9,003,204
9,003,256
9,003,299
9,003,338
9,825,764
4,544,359
4,544,835
4,545,288
5,912,422
4,546,114
4,546,484
4,546,824
4,547,132
7,214,409
6,773,241
6,773,441
6,773,625
6,773,790
9,489,116
6,774,061
6,774,181
6,774,292
6,774,396
11,171,981
8,999,434
8,999,513
8,999,585
8,999,649
12,687,495
8,999,755
8,999,799
8,999,834
8,999,864
13,480,752
ECA
4,343,622
4,343,622
4,343,622
4,781,464
4,343,622
4,343,622
4,343,622
4,343,622
4,781,464
4,343,622
4,343,622
4,343,622
4,343,622
4,781,464
4,343,622
4,343,622
4,343,622
4,343,622
4,781,464
4,343,622
4,343,622
4,343,622
4,343,622
4,781,464
4,343,622
4,343,622
4,343,622
4,343,622
4,781,464
TABLE VII–11 CONTINUED SCMS COSTS BY FUNCTION
Calendar
year
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Year
1 ...................................
2 ...................................
3 ...................................
4 ...................................
5 ...................................
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
12 .................................
13 .................................
14 .................................
15 .................................
16 .................................
17 .................................
18 .................................
19 .................................
20 .................................
21 .................................
22 .................................
23 .................................
24 .................................
25 .................................
26 .................................
27 .................................
28 .................................
29 .................................
30 .................................
31 .................................
32 .................................
33 .................................
34 .................................
35 .................................
VerDate Sep<11>2014
23:49 Jan 11, 2017
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
Jkt 241001
Intermediate
CA
$4,317,570
4,279,932
4,279,932
4,279,932
4,718,684
4,279,932
4,279,932
4,279,932
4,279,932
5,968,049
8,455,524
8,455,524
8,455,524
8,455,524
10,890,222
8,455,524
8,455,524
8,455,524
8,455,524
12,177,224
12,631,117
12,631,117
12,631,117
12,631,117
17,513,413
12,631,117
12,631,117
12,631,117
12,631,117
19,214,431
16,806,710
16,806,710
16,806,710
16,806,710
23,459,123
PO 00000
Frm 00126
Root
CA
DCM
$1,723,817
1,717,795
1,717,795
1,717,795
1,808,090
1,717,795
1,717,795
1,717,795
1,717,795
1,808,090
1,717,795
1,717,795
1,717,795
1,717,795
1,808,090
1,717,795
1,717,795
1,717,795
1,717,795
1,808,090
1,717,795
1,717,795
1,717,795
1,717,795
1,808,090
1,717,795
1,717,795
1,717,795
1,717,795
1,808,090
1,717,795
1,717,795
1,717,795
1,717,795
1,808,090
Fmt 4701
$4,378,553
4,340,915
4,340,915
4,340,915
4,760,710
4,340,915
4,340,915
4,340,915
4,340,915
4,760,710
4,340,915
4,340,915
4,340,915
4,340,915
4,760,710
4,340,915
4,340,915
4,340,915
4,340,915
4,760,710
4,340,915
4,340,915
4,340,915
4,340,915
4,760,710
4,340,915
4,340,915
4,340,915
4,340,915
4,760,710
4,340,915
4,340,915
4,340,915
4,340,915
4,760,710
Sfmt 4702
Manager
$2,233,628
2,231,119
2,231,119
2,231,119
2,292,279
2,231,119
2,231,119
2,231,119
2,231,119
2,557,780
3,382,829
3,382,829
3,382,829
3,382,829
3,511,964
3,382,829
3,382,829
3,382,829
3,382,829
3,774,067
4,517,339
4,517,339
4,517,339
4,517,339
4,691,868
4,517,339
4,517,339
4,517,339
4,517,339
4,691,868
4,517,339
4,517,339
4,517,339
4,517,339
4,692,002
E:\FR\FM\12JAP2.SGM
12JAP2
Total costs
$39,100,867
38,814,652
38,826,479
38,849,687
46,595,268
38,931,210
38,977,180
39,022,793
39,067,558
59,448,941
65,464,444
65,506,362
65,547,052
65,586,244
85,783,450
65,658,556
65,691,506
65,722,070
65,750,310
99,760,445
88,474,574
88,493,733
88,512,955
88,530,450
122,360,635
88,556,305
88,567,283
88,577,214
88,586,351
138,296,371
110,120,950
110,128,271
110,135,185
110,141,322
152,995,074
Total per
vehicle
$2.42
2.38
2.36
2.35
2.80
2.32
2.31
2.29
2.28
3.44
3.75
3.73
3.71
3.68
4.77
3.62
3.58
3.55
3.52
5.29
4.62
4.77
4.74
4.72
6.48
4.67
4.64
4.62
4.59
7.13
5.68
5.68
5.68
5.68
7.89
3979
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–11 CONTINUED SCMS COSTS BY FUNCTION—Continued
Calendar
year
Year
36
37
38
39
40
.................................
.................................
.................................
.................................
.................................
Intermediate
CA
2056
2057
2058
2059
2060
16,806,710
16,806,710
16,806,710
16,806,710
23,459,123
3. Fuel Economy Impact
In addition to the cost of V2V
equipment itself, other potential costs
include the potential for new equipment
on vehicles to increase vehicle weight.
The agency expects increased weight of
V2V equipment will have a small
impact on the fuel economy of the
individual vehicles. Over the lifetime of
these vehicles, this impact on fuel
economy will create a cost for society.
Potential fuel economy impacts can
be evaluated in terms of annual impacts
and the lifetime fuel economy impacts
for a specified MY vehicle (MY fuel
impact). The annual fuel impact
represents the additional fuel costs from
all V2V-equipped vehicles for that year.
The MY fuel impact represents the
additional fuel costs for a life of a MY
vehicle and should be discounted.
As described in previous sections,
V2V components include DSRC radios
and relevant parts/materials (e.g.,
antenna, installation material, HSM etc.)
Root
CA
DCM
1,717,795
1,717,795
1,717,795
1,717,795
1,808,090
4,340,915
4,340,915
4,340,915
4,340,915
4,760,710
and OBE for cellular, Wi-Fi and
satellite. A variance depending on the
potential implementation is related to
the one or two DSRC radio
communication approach. Therefore, for
the Hybrid option, the total additional
total weight would be 3.21 pounds
which came from one-radio and relevant
parts/materials (3.06 pounds) and
satellite radios (0.15 pounds). Weight
from cellular and Wi-Fi are negligible.
For the DSRC option, the total
additional weight would be 3.38 pounds
based the used of two DSRC radios and
relevant parts/materials.
The impact of added weight on both
annual and MY fuel economic is a
function of vehicle volumes, vehicle
miles traveled, survival probability (i.e.,
the percentage of the vehicle fleet that
will not be scrapped due to an
accident), the price of gasoline, and the
change in vehicle fuel economy (i.e.,
change in miles per gallon) due to the
added weight. Details on the estimating
vehicle volumes, miles traveled, and
Manager
4,517,339
4,517,339
4,517,339
4,517,339
4,692,026
Total costs
Total per
vehicle
110,151,511
110,155,754
110,159,302
110,162,566
160,663,404
5.68
5.68
5.68
5.68
8.29
survivability can be found in Chapter
VII of the PRIA.
(a) Annual Fuel Economy Impact
Table VII–12 shows the annual fuel
economy impact for both one-radio with
the Hybrid option and two radios with
the DSRC option. Note that the weight
difference between the two-radio system
and the one-radio system is 0.17 pound.
This small weight difference resulted in
no discernable difference between these
two technology approaches. To be
consistent with the measure used for
other cost items, the ‘‘per vehicle’’ cost
was estimated to be the cost per a new
vehicle. As shown, the proposed rule
would increase the current total annual
fuel consumption by 1.10 million
gallons in 2021 to 30.51 million gallons
in 2060. The corresponding annual cost
for these additional fuels was estimated
to be $3.08 to $135.16 million, annually.
These amounts were translated into
$0.19 to $6.97 per new vehicle sold.
TABLE VII–12—ANNUAL FUEL ECONOMY IMPACT *
Calendar
year
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Year
1 ...........................................................................................
2 ...........................................................................................
3 ...........................................................................................
4 ...........................................................................................
5 ...........................................................................................
6 ...........................................................................................
7 ...........................................................................................
8 ...........................................................................................
9 ...........................................................................................
10 .........................................................................................
11 .........................................................................................
12 .........................................................................................
13 .........................................................................................
14 .........................................................................................
15 .........................................................................................
16 .........................................................................................
17 .........................................................................................
18 .........................................................................................
19 .........................................................................................
20 .........................................................................................
21 .........................................................................................
22 .........................................................................................
23 .........................................................................................
24 .........................................................................................
25 .........................................................................................
26 .........................................................................................
27 .........................................................................................
28 .........................................................................................
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00127
Fuel price
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
Fmt 4701
Sfmt 4702
Additional
gallons
(million)
$2.80
2.86
2.91
2.95
2.99
3.02
3.06
3.08
3.11
3.14
3.18
3.22
3.26
3.35
3.38
3.43
3.47
3.51
3.58
3.66
3.64
3.68
3.72
3.76
3.80
3.84
3.88
3.93
E:\FR\FM\12JAP2.SGM
1.10
2.69
4.70
6.58
8.34
10.02
11.66
13.19
14.62
16.01
17.32
18.52
19.69
20.73
21.76
22.68
23.50
24.28
24.99
25.64
26.27
26.70
27.11
27.46
27.83
28.11
28.44
28.71
12JAP2
Total fuel
economy
(million $)
$3.08
7.69
13.68
19.41
24.94
30.26
35.68
40.63
45.47
50.27
55.08
59.63
64.19
69.45
73.55
77.79
81.55
85.22
89.46
93.84
95.62
98.26
100.85
103.25
105.75
107.94
110.35
112.83
Per vehicle
cost
($)
$0.19
0.47
0.83
1.17
1.50
1.81
2.11
2.39
2.65
2.91
3.16
3.40
3.63
3.89
4.09
4.28
4.45
4.61
4.79
4.97
5.00
5.29
5.40
5.50
5.60
5.69
5.78
5.88
3980
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–12—ANNUAL FUEL ECONOMY IMPACT *—Continued
Calendar
year
Year
29
30
31
32
33
34
35
36
37
38
39
40
.........................................................................................
.........................................................................................
.........................................................................................
.........................................................................................
.........................................................................................
.........................................................................................
.........................................................................................
.........................................................................................
.........................................................................................
.........................................................................................
.........................................................................................
.........................................................................................
Fuel price
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
Additional
gallons
(million)
3.97
4.01
4.06
4.10
4.14
4.18
4.22
4.27
4.31
4.35
4.39
4.43
28.91
29.21
29.43
29.65
29.82
29.97
30.10
30.20
30.33
30.41
30.47
30.51
Total fuel
economy
(million $)
Per vehicle
cost
($)
114.77
117.13
119.49
121.57
123.45
125.27
127.02
128.95
130.72
132.28
133.76
135.16
5.95
6.04
6.16
6.27
6.37
6.46
6.55
6.65
6.74
6.82
6.90
6.97
* For both one-radio and two-radios approaches.
(b) MY Fuel Economy Impact
MY fuel cost (i.e., lifetime fuel
economy cost) is the cost of additional
gasoline used over the vehicle’s life and
is estimated on a per vehicle basis. The
fuel economy cost for a specific MY
vehicle is derived by applying the
specific MY fuel economy cost per
vehicle to every vehicle. The cost is
accrued throughout the vehicle’s life
and is discounted to reflect its present
value (in 2014 dollars) using 3% and
7% discount rates. The MY fuel
economy impact also is a function of
mileage, survival probability (i.e., the
percentage of the vehicle fleet that will
not be scrapped due to an accident), the
price of gasoline, the change in vehicle
fuel economy due to the added weight,
and the discount rate chosen to express
lifetime impacts in their present value.
Additional details on the deriving the
MY fuel economy impact can be found
in Chapter 7 of the PRIA.
Table VII–13 shows the MY fuel
economy impacts at both 3 and 7
percent discount rates. As shown, at a
3 percent discount rate, the MY fuel
economy impact of V2V related
equipment is estimated to be $32.75
million at MY 2021 and gradually
increasing to $104.73 million for MY
2050 vehicles. The cost per vehicle is
estimated to be $2.02 for MY 2021 and
$5.40 for MY 2050 vehicles. The
increase in fuel cost in the future,
especially after the third year when the
full adoption of DSRC radios starts, is
primarily due to projected higher fuel
prices and vehicle sales, both of which
can vary. The cost per vehicle for a
particular MY vehicle is calculated by
dividing the total fuel cost for that MY
by the total vehicle sales of that MY
vehicle. For the first two years, due to
the proposed phased in implementation,
the cost per vehicle is smaller than the
cost per affected vehicle since cost per
vehicle as defined is the average cost
over all new vehicles.
At a 7 percent discount rate, the MY
fuel economy impact is estimated to be
$25.03 for million MY 2021 and $80.52
million for MY 2050 vehicles. The cost
per vehicle for these two MY vehicles
would be $1.55 and $4.15 for MY 202
and MY 2050 vehicles, respectively.
TABLE VII–13—MY FUEL ECONOMY IMPACT * BY DISCOUNT RATE
Model
year
Year
Gallons per
vehicle
Total gallons
(million)
MY fuel economy impact
(million $)
srobinson on DSK5SPTVN1PROD with PROPOSALS2
@3%
1 ...................................
2 ...................................
3 ...................................
4 ...................................
5 ...................................
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
12 .................................
13 .................................
14 .................................
15 .................................
16 .................................
17 .................................
18 .................................
19 .................................
20 .................................
21 .................................
22 .................................
23 .................................
24 .................................
25 .................................
VerDate Sep<11>2014
23:49 Jan 11, 2017
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
Jkt 241001
0.83
1.22
1.58
1.54
1.49
1.50
1.50
1.51
1.52
1.53
1.53
1.54
1.55
1.55
1.56
1.56
1.57
1.57
1.58
1.58
1.58
1.59
1.59
1.59
1.59
PO 00000
Frm 00128
13.38
19.88
26.01
25.52
24.80
25.07
25.39
25.74
26.03
26.42
26.77
27.06
27.34
27.71
28.07
28.40
28.77
29.09
29.45
29.87
30.30
29.53
29.69
29.85
30.03
Fmt 4701
Sfmt 4702
@7%
$32.75
49.33
65.34
64.90
63.85
65.31
66.95
68.69
70.32
72.30
74.21
76.00
77.77
79.86
81.82
83.76
85.80
87.73
89.80
92.00
94.14
92.69
94.15
95.63
97.17
E:\FR\FM\12JAP2.SGM
$25.03
37.71
49.96
49.62
48.81
49.92
51.17
52.50
53.74
55.27
56.74
58.14
59.52
61.15
62.67
64.18
65.76
67.25
68.86
70.56
72.18
71.07
72.20
73.36
74.56
12JAP2
Per vehicle
cost
@3%
$2.02
3.02
3.97
3.93
3.83
3.90
3.97
4.03
4.11
4.18
4.26
4.33
4.40
4.48
4.55
4.61
4.68
4.74
4.81
4.88
4.92
4.99
5.05
5.10
5.15
@7%
$1.55
2.31
3.04
3.00
2.93
2.98
3.03
3.08
3.14
3.19
3.25
3.31
3.37
3.43
3.48
3.53
3.59
3.64
3.69
3.74
3.77
3.83
3.87
3.91
3.95
3981
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–13—MY FUEL ECONOMY IMPACT * BY DISCOUNT RATE—Continued
Model
year
Year
Gallons per
vehicle
Total gallons
(million)
MY fuel economy impact
(million $)
@3%
26
27
28
29
30
.................................
.................................
.................................
.................................
.................................
2046
2047
2048
2049
2050
1.59
1.59
1.59
1.59
1.59
4. Overall Annual Costs
(a) Total Annual Costs
The annual costs represent the total
annual capital investment and fuel
economy impact from all V2V-equipped
vehicles per year. The costs comprise
four major categories: (1) Vehicle
technology (i.e., DSRC radios and app),
(2) SCMS, (3) equipment and
30.19
30.37
30.53
30.69
30.87
@7%
98.66
100.21
101.73
103.20
104.73
communication network in support of
vehicles-to-SCMS communication (i.e.,
Communication), and (4) fuel economy
impact due to the increased weight from
the in-vehicle equipment in (1) and (3).
Table VII–14 presents the total annual
costs and cost per vehicle. The total
annual costs would range from $2.2 (the
lower bound for 2021) to $5.0 billion
(not shown, upper bound for 2024). The
Per vehicle
cost
@3%
75.72
76.94
78.14
79.30
80.52
@7%
5.20
5.25
5.30
5.35
5.40
3.99
4.03
4.07
4.11
4.15
cost per new vehicle would range from
$135 to $301 (lower bound for 2021 and
upper bound for 2024). The lower and
upper bounds represent the two
technology implementation approaches
(one-radio and two-radios) that the
agency believes can meet the proposed
rule and the security and privacy
specifications.
TABLE VII–14—TOTAL ANNUAL COSTS AND COST PER VEHICLE
[2014 $]
Annual cost
(million $)
Calendar
year
Year
Low
1 ...........................................................................................
5 ...........................................................................................
10 .........................................................................................
15 .........................................................................................
20 .........................................................................................
25 .........................................................................................
30 .........................................................................................
35 .........................................................................................
40 .........................................................................................
(b) Total Annual Costs by Cost Category
Table VII–15 to Table VII–18 lists the
total annual costs separately for the four
cost categories. As shown, the majority
of costs came from vehicle technology
costs. The annual vehicle technology
costs ranged from $2.0 to $4.9 billion (in
2023, not shown) and the per vehicle
cost ranged from $124 to $298.
The SCMS costs included the costs for
the establishment, operation, and
maintenance of the system that covered
the expenditure on human resources,
equipment, facilities, energy, etc. The
2021
2025
2030
2035
2040
2045
2050
2055
2060
Annual cost per
vehicle
High
$2,192
3,701
3,649
3,717
3,831
3,796
3,858
3,832
3,804
total annual SCMS costs would range
from $39 to $161 million. This is
equivalent to $2 to $8 per vehicle.
The communication costs included
the costs for equipment and
communication network that are needed
in support of the vehicle-to-SCMS
communication. The annual
communication costs would range up to
$494 million. The communication cost
per vehicle would be up to $26 per
vehicle.
The fuel economy impact was based
on the added weight of 3.38 pounds for
$2,864
4,803
4,692
4,757
4,844
4,764
4,818
4,766
4,717
Low
High
$135.38
222.02
210.94
206.52
203.01
201.14
198.97
197.65
196.20
$176.89
288.13
271.22
264.26
256.71
252.49
248.50
245.80
243.27
the two-radio technology approach and
3.21 pounds for the one-radio approach.
Due to the insignificant weight
difference between these two
approaches, the estimated fuel economy
impacts are identical for these
approaches when factoring rounding
errors. Therefore, the fuel economy
impact as shown applies to both
approaches. The annual fuel economy
impact would range from $3 to 135
million. This equates to up to $7 per
vehicle.
TABLE VII–15—TOTAL ANNUAL VEHICLE TECHNOLOGY COSTS
srobinson on DSK5SPTVN1PROD with PROPOSALS2
[2014 $ and vehicles in millions]
Year
Total costs
(million $)
Calendar year
Low
1 ...........................................................................................
5 ...........................................................................................
10 .........................................................................................
15 .........................................................................................
20 .........................................................................................
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00129
2021
2025
2030
2035
2040
Fmt 4701
Sfmt 4702
Cost per
vehicle
High
$2,001
3,297
3,160
3,135
3,178
E:\FR\FM\12JAP2.SGM
$2,822
4,646
4,447
4,413
4,473
12JAP2
Low
$123.59
197.79
182.63
174.17
168.39
High
$174.29
278.68
257.06
245.17
237.03
3982
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–15—TOTAL ANNUAL VEHICLE TECHNOLOGY COSTS—Continued
[2014 $ and vehicles in millions]
Year
Total costs
(million $)
Calendar year
Low
25
30
35
40
.........................................................................................
.........................................................................................
.........................................................................................
.........................................................................................
2045
2050
2055
2060
Cost per
vehicle
High
3,096
3,115
3,061
3,015
Low
4,359
4,385
4,308
4,243
High
164.09
160.67
157.85
155.47
230.98
226.16
222.19
218.85
TABLE VII–16—TOTAL ANNUAL SCMS COSTS *
[2014 $ and vehicles in millions]
Year
Calendar year
1 ...................................................................................................................................................
5 ...................................................................................................................................................
10 .................................................................................................................................................
15 .................................................................................................................................................
20 .................................................................................................................................................
25 .................................................................................................................................................
30 .................................................................................................................................................
35 .................................................................................................................................................
40 .................................................................................................................................................
Total costs
(million $)
2021
2025
2030
2035
2040
2045
2050
2055
2060
$39
47
59
86
100
122
138
153
161
Cost per
vehicle
$2.42
2.80
3.44
4.77
5.29
6.48
7.13
7.89
8.29
* Not impacted by technology approach.
TABLE VII–17—TOTAL ANNUAL COMMUNICATION COSTS
[2014 $ and vehicles in millions]
Year
Total costs
(million $)
Calendar year
Low
1 ...........................................................................................
5 ...........................................................................................
10 .........................................................................................
15 .........................................................................................
20 .........................................................................................
25 .........................................................................................
30 .........................................................................................
35 .........................................................................................
40 .........................................................................................
Cost per
vehicle
High
2021
2025
2030
2035
2040
2045
2050
2055
2060
$0
85
135
185
178
178
178
178
178
$1,486
3,324
3,799
4,229
4,597
4,709
4,873
4,917
4,939
Low
$0.00
5.15
7.81
10.24
9.42
9.42
9.16
9.16
9.16
High
$9.18
19.94
21.96
23.49
24.36
24.96
25.13
25.36
25.47
TABLE VII–18—TOTAL ANNUAL FUEL ECONOMY IMPACT * COSTS
[2014 $ and vehicles in millions]
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Year
Calendar year
1 .......................................................................................................................
5 .......................................................................................................................
10 .....................................................................................................................
15 .....................................................................................................................
20 .....................................................................................................................
25 .....................................................................................................................
30 .....................................................................................................................
35 .....................................................................................................................
40 .....................................................................................................................
Fuel
consumption
(million
gallons)
2021
2025
2030
2035
2040
2045
2050
2055
2060
1.10
8.34
16.01
21.76
25.64
27.83
29.21
30.10
30.51
Fuel costs
(million $)
$3.08
24.94
50.27
73.55
93.84
105.75
117.13
127.02
135.16
Cost per
vehicle
$0.19
1.50
2.91
4.09
4.97
5.60
6.04
6.55
6.97
* Cost equal for both two technology implementation approaches due to insignificant weight difference.
5. Overall Model Year (MY) Costs
The primary difference between the
annual and MY costs is the fuel
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
economy impact. The PRIA assumes
that vehicle technology, SCMS, and
communication costs would be paid by
PO 00000
Frm 00130
Fmt 4701
Sfmt 4702
vehicle owners when their vehicles
were purchased. Thus, these three costs
are identical between the annual and
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
MY costs. In annual costs, the fuel
economy impact measures the
additional fuel costs for all V2Vequipped MY vehicles in a specific
calendar year. For estimating the MY
costs, the fuel economy impact
measures the incremental lifetime fuel
impact for a specific MY vehicles and
were discounted at a 3 and 7 percent
rate to reflect their present value.
Table VII–19 and Table VII–20 shows
the MY costs at a 3 percent and 7
percent discount rate, respectively. At a
3 percent discount rate, the MY costs
would range from $2.22 (lower bound at
Year 1) to $5.03 billion (upper bound at
Year 4, not shown). The cost per vehicle
would range from $137.21 to $304.06.
The lower bound of the costs represents
the MY costs for the one-radio approach
3983
and the higher bound represents the
cost for the two-radio approach.
At a 7 percent discount rate, the MY
costs would range from $2.21 (lower
bound at Year 1) to $5.01 billion (upper
bound at Year 4, not shown). The MY
cost per vehicle would range from
$136.73 to $303.14.
TABLE VII–19—TOTAL MY COSTS AND COST PER VEHICLE AT 3 PERCENT
Total MY costs
(million $)
Model
year
Year
Low
1 ...........................................................................................
5 ...........................................................................................
10 .........................................................................................
15 .........................................................................................
20 .........................................................................................
25 .........................................................................................
30 .........................................................................................
2021
2025
2030
2035
2040
2045
2050
MY cost per
vehicle
High
$2,221
3,740
3,671
3,726
3,829
3,787
3,846
$2,894
4,842
4,714
4,765
4,842
4,756
4,806
Low
$137.21
224.36
212.21
206.98
202.92
200.68
198.33
High
$178.72
290.46
272.49
264.72
256.61
252.03
247.86
TABLE VII–20—TOTAL MY COSTS AND COST PER VEHICLE AT 7 PERCENT
Total MY costs
(million $)
Calendar
year
Year
Low
1 ...........................................................................................
5 ...........................................................................................
10 .........................................................................................
15 .........................................................................................
20 .........................................................................................
25 .........................................................................................
30 .........................................................................................
srobinson on DSK5SPTVN1PROD with PROPOSALS2
The agency seeks comment on all
aspects of the cost estimates developed
for this proposal. This includes all cost
assumptions, estimated component
costs, communication costs including
other potential options the agency did
not evaluate, and views on potential
SCMS costs. Please provide any
supporting data for the comments. If
necessary, the agency has processes and
procedures for submitting confidential
business information.
C. Non-Quantified Costs
The agency identified four major nonquantified costs that could be related to
the deployment of V2V devices. These
include the potential health costs due to
a potential increase in electromagnetic
hypersensitivity (EHS, i.e., human
radiation exposure to wireless
communications discussed in Section
IV.E) potential loss of perceived privacy,
the opportunity costs of alternative uses
for the spectrum, and possibly increased
litigation costs. The agency requests
comment on these costs, particularly
whether there exist ways to quantify any
of these costs.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
2021
2025
2030
2035
2040
2045
2050
Many commenters (mostly individual
citizens) commented on the potential
relationship of DSRC radio technology
and electromagnetic field exposure
hypersensitivity, raising concerns
regarding the potential for a V2V
mandate to increase electromagnetic
beyond today’s levels. The agency takes
these concerns very seriously. The
agency since has conducted a literature
review and other research (on-going) to
better understand electromagnetic
radiation and its relationship to the
symptoms of EHS. As we understand
that the expertise of our sister agencies
such as the Federal Communications
Commission (FCC) and the Food and
Drug Administration (FDA), among
others, have been involved with
electromagnetic fields, in parallel with
the pervasiveness of cellular phone
deployment in the United States and
globally.
The FDA found that most studies
conducted to date show no connection
between certain health problems and
PO 00000
Frm 00131
Fmt 4701
Sfmt 4702
High
$2,214
3,725
3,654
3,706
3,808
3,764
3,821
1. Health Insurance Costs Relating to
EHS
MY cost per
vehicle
$2,886
4,827
4,697
4,746
4,821
4,733
4,782
Low
$136.73
223.45
211.22
205.92
201.78
199.49
197.09
High
$178.25
289.56
271.51
263.66
255.47
250.83
246.61
exposure to radiofrequency fields via
cell phone use and that attempts to
replicate and confirm the few studies
that did show a connection have
failed.353 Furthermore, V2V devices
would operate at distances significantly
further than the distance between a
portable cellular phone to its operator,
where the device is generally carried on
a person or pressed directly to the ear.
Therefore, the EHS effects are expected
to be lower for V2V than cell phones;
the agency does not quantify the health
costs relating to EHS. Nevertheless, the
agency acknowledges that research is
still ongoing and, as technology evolves;
wireless communications will most
likely continue to increase. We will
continue to monitor the progress of this
issue and closely follow the efforts of
the Radiofrequency Interagency Work
Group (RFIAWG) which may yield any
353 Radiation-Emitting Products, ‘‘Current
Research Results,’’ https://www.fda.gov/RadiationEmittingProducts/RadiationEmittingProducts
andProcedures/HomeBusinessandEntertainment/
CellPhones/ucm116335.htm, last accessed: June 3,
2015.
E:\FR\FM\12JAP2.SGM
12JAP2
3984
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
potential future guidance for wireless
device deployment and usage.
2. Perceived Privacy Loss
srobinson on DSK5SPTVN1PROD with PROPOSALS2
One intangible outcome of the
proposed rule is a perceived potential
for loss of privacy. Individuals may
perceive the V2V system as eroding
their personal privacy and view this as
a considerable negative consequence.
Also, several surveys showed that
individual attitudes towards
information security seems inconsistent
with their behavior on protection of
their information.354 355 Acquisti, et al.
stated that identifying the consequence
of a privacy incident is difficult enough,
and quantifying these consequences is
remarkably complex.356 Furthermore,
there are few studies on the economic
costs for privacy and even less for
quantifying the economic costs for
perceived privacy loss. Given the great
uncertainties for valuing the perceived
loss of privacy, this analysis does not
quantify this cost.
To ease the privacy concerns and
mitigate possible privacy loss, 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 build privacy protections
into the design and deployment of V2V
communications that help guard against
risks to individual privacy.
The agency has conducted a thorough
privacy impact assessment as required
by the Consolidated Appropriations Act,
2005, Public Law 108–447. This Act
requires that Federal agencies conduct
privacy impact assessments (PIAs) of
proposed regulatory activities involving
collections or systems of information in
electronic form 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
354 Acquisti, Alessandro (2004), Privacy Attitudes
and Privacy Behavior, Losses, Gains, and
Hyperbolic Discounting (Preliminary draft).
355 Acquisti, Alessandro (2002). Protecting
privacy with economics: Economic incentives for
preventing technologies in ubiquitous computing
environments. In workshop on Socially-informed
Design of Privacy-enhancing Solutions, 4th
International Conference on Ubiquitous
Computing—UBICOMP’02.
356 Acquisti, A., Friedman, A., Telang, R., ‘‘Is
there a Cost to Privacy Breaches? An Event Study’’,
Twenty Seventh International Conference on
Information System, Milwaukee 2006 (preproceeding draft version).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
regarding privacy; (ii) determine the
risks and effects of the proposed data
transactions; and (iii) examine and
evaluate protections and alternative
processes for handling data to mitigate
potential privacy risks.
3. Opportunity Costs of Spectrum for
Other Uses
(a) Overview
Our analysis shows that this rule will
generate significant net benefits due to
improved safety, decreased loss of life,
reduced property damage, and other
impacts. While requiring this
technology has costs, the analysis here
shows that the benefits of this rule well
justify those costs.
As discussed in greater detail
elsewhere in this notice, the FCC
designated the 5.9 GHz band (i.e., 5850–
5925 MHz) for ITS radio services and
adopted open license to both public
safety and non-public safety use of this
band with the priority for public safety
communications in 2003. Within the 5.9
GHz band, the FCC has designated
Channel 172 (i.e., 5.855–5.865 GHz, a 10
MHz band) exclusively for ‘‘vehicle-tovehicle communication for crash
avoidance and mitigation, and safety of
life and property applications.’’
Given the FCC’s decision about how
to allocate Channel 172, this rule results
in the use of that particular radio
spectrum for vehicle-to-vehicle
communication even though that
resource could potentially have
alternative uses for society, including
alternative safety applications. The FCC,
not NHTSA or DOT, has the authority
to determine the commercial use of
spectrum. However, NHTSA
understands the scarcity of spectrum
and in the interests of providing a
complete analysis of the costs and
benefits of this rule seeks comment on
the potential costs associated with the
lost opportunity to exploit the spectrum
at issue for other uses.
The FCC, as part of its own ongoing
rulemaking proceeding, is considering
whether to allow ‘‘Unlicensed National
Information Infrastructure’’ (UNII)
devices (that provide short-range, highspeed, unlicensed wireless connections
for, among other applications, Wi-Fienabled radio local area networks,
cordless telephones, and fixed outdoor
broadband transceivers used by wireless
Internet service providers) to operate in
the same frequencies of the spectrum as
V2V.
Opening any spectrum band to
sharing could result in many more
devices transmitting and receiving
information on the same or similar
frequencies. Depending on the
PO 00000
Frm 00132
Fmt 4701
Sfmt 4702
technology, band, and uses at issue,
such sharing can work well or can lead
to harmful interference among those
devices. Recognizing the scarcity of
spectrum, 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, stating a shared
‘‘commitment to finding the best
method to develop, successfully test,
and deploy advanced automotive safety
systems while working to meet existing
and future spectrum demands,’’ and
announcing an interagency, multiphased testing regime that will be used
to ‘‘provide reliable, real-world data on
the performance of unlicensed devices
that are designed to avoid interfering
with DSRC operation in the 5.9 GHz
band.’’ 357 The results of this test will
inform FCC on potential sharing
solutions, if any, between proposed
Unlicensed National Information
Infrastructure (U–NII) devices and DSRC
operations in the 5.850–5.925 GHz (U–
NII–4) band.
The results of the interagency tests
will also be utilized to inform NHTSA’s
proceeding as it progresses towards
aproceeding prior to any final
rulemaking on V2V. As noted in the
joint DOT-FCC-Commerce letter that
responds to a Congressional letter dated
September 9, 2015, it is ‘‘imperative—to
ensure the future automotive safety and
efficiency of the traveling public—that
all three phases of the FCC test plan be
completed before reaching any
conclusions as to whether [non-DSRC]
unlicensed devices can safely operate in
the 5.9 GHz band.’’ without interfering
with DSRC operation.
DOT believes that any estimate of the
opportunity cost of this NPRM should
be made in the context of the FCC’s
existing policies and authorities. Put
another way, in identifying and valuing
other opportunities that might be
precluded or degraded by this NPRM,
DOT is considering those opportunities
consistent with the FCC’s designation of
spectrum. However, in assessing the
benefits in the context of the current
FCC designation on which this rule
focuses, we invite and will consider
comments on opportunity costs
associated with broader uses of
spectrum beyond the current FCC
designation.
In addition, we provide a further
discussion of other potential benefits of
DSRC beyond the two safety
applications quantified in the economic
analysis for this NPRM. Those
357 See letter in NHTSA Docket No. NHTSA–
2016–0126.
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
additional benefits include potential
safety, congestion, environmental, UAS
and Smart City benefits.
(b) Benefits of DSRC
We first provide a further explanation
of the potential additional safety
benefits of DSRC beyond the two
intersection safety applications
quantified in the economic analysis for
this NPRM.
The primary benefit of the proposed
rule is improved automobile safety.
Section VII.D discusses this benefit at
length. DOT also wishes to present a
broader discussion of the benefits not
measured in the Primary Regulatory
Impact Analysis and seek comment on
the resulting estimate. To arrive at this
estimate, we have taken existing
research that quantified motor vehicle
crashes as costing society over $242
billion in economic impacts in 2010 and
caused societal harm of over $836
billion through fatalities, injuries and
3985
property damage. Adjusting the societal
harm estimate to reflect the increase in
traffic fatalities and CPI in 2015, we
arrive at a value of $966 billion.
Recognizing previous research has
indicated that V2V could potentially
avoid or mitigate 80% of unimpaired
crashes, we have conservatively
calculated scenarios where V2V is
phased in linearly, reaching maximum
crash reduction benefits of 5, 10, and
15% by 2035.
TABLE VII–21—SUMMARY OF ESTIMATED PRESENT VALUE OF BENEFITS OF V2V COMMUNICATION FOR THIS NPRM
Percentage of
crashes
prevented
Societal Harm
($M)
$966,000 ..............................................................................................................................
$966,000 ..............................................................................................................................
$966,000 ..............................................................................................................................
A more conservative approach to
calculating total benefit of the rule
could be considering a function of the
number of lives that would be saved by
2018 PV at 3%
discount rate
($M)
5.0
10.0
15.0
V2V communication, multiplied by the
economic value of a life. A number of
values have been used for the economic
value of a life; we compute our
$603,620
1,207,230
1,810,850
2018 PV at 7%
discount rate
($M)
$288,480
576,950
865,430
sensitivity analysis using values of $5–
$13.4M. Table VII–22 below presents
different estimates for the 2018 value of
the benefit of the rule through 2050.
TABLE VII—22 SUMMARY OF ESTIMATED PRESENT VALUE OF BENEFITS OF V2V COMMUNICATION FOR THIS NPRM
Percentage of
fatalities
prevented
Value of a life
($M)
$5.4 ..........................................................................................................
$13.4 ........................................................................................................
$5.4 ..........................................................................................................
$13.4 ........................................................................................................
$5.4 ..........................................................................................................
$13.4 ........................................................................................................
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(c) Other Benefits of DSRC
Communication
The benefits shown above offset the
costs, including opportunity costs, of
this proposed rule. Moreover, the
beneficial uses of spectrum for vehicleto-vehicle communications could well
increase in the future. Over the last five
years, the USDOT has sponsored the
Connected Vehicle Program under
Intelligent Transportation Systems
Research. This program has identified
more than fifty potential connected
vehicle applications concepts, many of
which have already been prototyped
and demonstrated. As a part of this
process, the component application
development programs have also
conducted assessments to measure
safety, mobility, and environmental
impacts. Field demonstrations have
been supplemented by estimation of
difficult-to-observe impacts and
potential future impacts from broader
application deployment using a range of
analytical methods. The USDOT has
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
1.0
1.0
5.0
5.0
10.0
10.0
published documentation from the more
advanced application development
efforts, including concepts of
operations, system requirements, design
documents, algorithms, functional
descriptions, characterization test
results, field test evaluation results and
estimation of benefits associated with
these prototypes. In total, the USDOT
has identified fifty-three connected
vehicle applications that will depend on
effective vehicle communication. These
fifty-three applications include thirteen
safety applications that address vehicle
occupant and pedestrian safety through
communication with other vehicles as
well as roadside infrastructure. They
also include fifteen applications that
address environmental quality and
resource consumption, and many more
that address congestion, mobility, and
data gathering.
(d) Opportunity Costs of Precluding
Alternative Uses
Decisions regarding whether to allow
additional uses of spectrum than those
PO 00000
Frm 00133
Fmt 4701
Sfmt 4702
2018 PV at 3%
discount rate
($M)
Fatalities
prevented
350.92
350.92
1754.6
1754.6
3509.2
3509.2
$38,636
95,874
193,181
479,373
386,360
958,747
2018 PV at 7%
discount rate
($M)
$23,965
59,468
119,824
297,341
239,648
594,683
currently authorized by the FCC for the
ITS band are not within the scope of
DOT’s or NHTSA’s authority. Comments
on the value of these uses will, however,
be accepted. Such comments should
consider that the interagency spectrum
sharing tests are not yet complete, and
it will be impossible to fully measure
such benefits until the feasibility of
sharing is determined. If such sharing is
possible, those benefits will likely
decrease opportunity costs associated
with mandating V2V communications.
Nothing in this rulemaking would
preclude the FCC, in conjunction with
DOT and NTIA, from authorizing
appropriate sharing at some future date.
The chart below is a generic
calculation of the spectrum opportunity
cost, based on preclusion of alternative
uses for the spectrum. This estimate
might overstate the value of opportunity
cost if sharing is determined to be
possible. We use estimated Wi-Fi values
from 2013 and earlier reports to estimate
the economic value of one MHz of
E:\FR\FM\12JAP2.SGM
12JAP2
3986
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
spectrum. To do this, we begin by
extracting data from the largest and
most recent study of spectrum values
from TAS, making several adjustments
based on our analysis.358 To calculate a
net present value as of 2016, we treat
the annual economic value of the
spectrum beginning in 2018 and until
2050, meaning that it will generate the
between $1.9B and $3.4B based on
whether a 7 or a 3 percent discount rate
is used, respectively.360
We seek comment on whether these
per-MHz figures are reasonable,
including comment on the detailed
analysis in footnote 3, as well as any
alternative methodologies.
same value for each year in the future.
There are two assumptions implicit in
this approach: (1) The spectrum
continues to generate value into the
future and (2) the value of the spectrum
does not change from year to year (i.e.,
the growth rate is zero).359
The estimated present value of each
additional MHz up to 2050 ranges
TABLE VII–23—SUMMARY OF ESTIMATED PRESENT VALUE OF SPECTRUM
Value
(billions of $)
Approach
Estimated Value of Wi-Fi .....................................
110
PV to 2050, 2018
implementation,
3% discount
rate
(billions of
$/MHz)
Billions of
$/MHz
MHz
638
0.2
PV to 2050, 2018
implementation,
7% discount
rate
(billions of $/MHz)
3.4
1.9
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Other ways to estimate the
opportunity cost of spectrum may be
feasible, including using auction values
for spectrum licenses. A method like
this would require estimates of the ratio
between auction value and annual
consumer surplus. A method like that
would generate far higher values than
the table above because it uses licensed
rather than unlicensed spectrum as a
benchmark—making it yield an estimate
that cannot be directly used to assess
the value of unlicensed spectrum. Other
considerations when using the estimates
above to value the spectrum in question
include:
The value of spectrum is highly
situational and the historic spectrum
value might not be a valid indication of
the spectrum of the future. Spectrum
value differs with respect to variables
including, but not limited to,
frequencies, size of the block or
segment, international harmonization,
geographic location, the timing of the
release of new batches of spectrum, and
the extent to which use is shared or
exclusive. Frequencies might be the
most significant factor to determine the
value since different frequencies have
different characteristics that make
useful for different applications. The
most useful bands of frequencies may be
auctioned out and developed early. The
spectrum values for these frequencies
may have very different characteristics
from the 5.9 GHz band and their value
may exceed the value of the 5.9 GHz.
The cost of delivering information
over spectrum varies and is a function
of the range in which it operates. Higher
frequency spectrums like 5.9 GHz
broadcast over much shorter distances
than lower frequency spectrums and
thus require the interaction of
interoperable devices over these short
distances to transmit and receive
messages in order for applications to
activate.
Existing market values do not reflect
the progressive increase of the economic
value of spectrum over time (i.e., timedependent value).
The above estimates yield per-MHz
figures for the gross opportunity cost
that would result if spectrum in these
bands were monopolized. However, the
actual opportunity cost associated with
spectrum that would result from
mandating V2V in the way prescribed in
this NPRM is represented by foregone
alternative uses of that spectrum, which
would be more limited.
It is possible that all spectrum within
the relevant 75 MHz will ultimately be
used for vehicle-to-vehicle
communications given the substantial
safety benefits of that technology. It is,
however, likely that not all spectrum
within the relevant 75 MHz will be de
facto or de jure used exclusively for the
specific safety applications envisioned
by this rule, i.e., those based on
transmission of the Basic Safety
Message. In particular, we propose to
require BSM transmissions on a single
10 MHz channel. Multiplying this 10
MHz by the per-MHz values derived
above yields an opportunity cost of $19–
$34 billion. We seek comment on the
best framework to appropriately
consider the opportunity costs of this
proposed rule across the band, taking
into account varying assumptions about
spectrum usage. DOT expects to include
an estimate of the opportunity cost of
spectrum as part of its RIA in a final
rule.
358 Assessment of the Economic Value of
Unlicensed Spectrum in the United States, Final
Report, February 2014, Telecom Advisory Services,
LLC https://www.wififorward.org/wp-content/
uploads/2014/01/Value-of-Unlicensed-Spectrum-tothe-US-Economy-Full-Report.pdf (last accessed Dec
8, 2016). We first remove RFID retail because it is
a very different technology from Wi-Fi and it
operates at very low frequency bands (13.56, 4.33,
and 902–928 MHz (i.e., all operate at less than 1
GHz). Second, Table C includes $34.885B of
producer surplus associated with Wi-Fi only tablets
estimated as the difference between the retail price
and manufacturing costs for a weighted average of
tablet suppliers. In practice, consumers pay above
manufacturing costs for marketing, brand, and other
amenities, making this an overestimate. As a rough
adjustment, we cut this number in half to $17.44B.
Adding all spectrum values from Table C of the
TAS report except for RFID retail yields a total
value for unlicensed Wi-Fi spectrum of $110
billion. Based on the CEA report, there are a total
of 638 MHz of spectrum available for unlicensed
Wi-Fi use. This includes 83 MHz in the 2.4 GHz
band and 555 MHz in the 5.1–5.8 GHz band.
Dividing the TAS estimate of Wi-Fi value by the
total bandwidth gives an estimate of $172.4 million
per each MHz of spectrum.
359 Other researchers including Bazelon and
McHenry (2015) use a similar approach. Bazelon
and McHentry (2015) paper is available here: https://
www.brattle.com/system/publications/pdfs/000/
005/168/original/Mobile_Broadband_Spectrum_-_
A_Valuable_Resource_for_the_American_
Economy_Bazelon_McHenry_051115.pdf (last
accessed Dec 8, 2016).
360 We use 3 and 7 percent discount rates to be
consistent with OMB guidelines, available here
(Step 7, p. 11): https://www.whitehouse.gov/sites/
default/files/omb/inforeg/regpol/circular-a4_regulatory-impact-analysis-a-primer.pdf (last
accessed Dec 8, 2016).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00134
Fmt 4701
Sfmt 4702
4. Increased Litigation Costs
The agency recognizes the possibility
of higher litigation costs due to the
cooperative nature of the V2V
environment. However, the agency
reiterates that driving tasks are drivers’
responsibilities. The at-fault driver in a
crash will bear the economic burden
and this will not be altered in the V2V
environment. Furthermore, V2V
technology is expected to help avoid
crashes and thus reduce the overall
burden imposed on legal systems and
traffic courts.
E:\FR\FM\12JAP2.SGM
12JAP2
3987
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
D. Estimated Benefits
1. Assumptions and Overview
In order to estimate the benefits of
this rule, the agency made several key
assumptions. The agency applied the
same assumptions for adoption and
vehicle fleet penetration rates as for
estimating both the costs and benefits of
this proposed rule, as shown in Table
VII–24 and Table VII–25.
TABLE VII–24—V2V TECHNOLOGY ADOPTION RATES IN PERCENT
Model year
2021
DSRC % ...........................
Applications % * ...............
2022
50
0
2023
75
5
2024
100
10
2025
100
25
2026
100
40
2027
100
65
2028
100
90
100
100
* As percent of DSRC-equipped vehicles.
TABLE VII–25—V2V TECHNOLOGY FLEET PENETRATION
With DSRC radios
Year
Calendar year
srobinson on DSK5SPTVN1PROD with PROPOSALS2
1 ...........................................................................................
5 ...........................................................................................
10 .........................................................................................
15 .........................................................................................
20 .........................................................................................
25 .........................................................................................
30 .........................................................................................
35 .........................................................................................
40 .........................................................................................
The agency estimated the potential
benefits of the proposed rule based
upon a scenario where two safety
applications, IMA and LTA, are
voluntarily adopted by industry
following a DSRC-mandate. The agency
focused on these potential safety
applications 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. The agency notes that this
may not be the scenario that actually
occurs following a DSRC-mandate;
manufacturers may choose to offer other
safety applications that use V2V
technology beyond these two and may
offer those technologies or IMA and
LTA in a time frame different from what
is considered for purposes of analysis.
In addition, manufacturers may also
offer various other technologies that use
DSRC, such as V2I or V2P technologies.
These other technologies may offer
benefits of a different amount than those
calculated for IMA and LTA and they
may accrue over a different timeframe.
The agency requests comment on these
assumptions.
Overall, three major factors influence
the potential benefits of a V2V
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
Number of
vehicles
(million)
2021
2025
2030
2035
2040
2045
2050
2055
2060
Where,
Bi = Annual benefits (or MY benefits) of the
proposed rule at year i,
P = Target population (crashes, fatalities,
injuries, or PDOVs),
E = Effectiveness of apps (i.e., IMA or LTA),
and
Ci = communication rate at year i.
(a) Target Population (P)
The target population (P) includes
crashes, fatalities, injuries, and PDOVs.
As described in Section II.A, the Safety
Need, this proposed rule is estimated to
affect potentially 3.4 million lightvehicle-to-light-vehicle crashes. This
potential population excludes other
crashes scenarios. More specifically,
single-vehicle crashes were excluded
based on the V2V’s inherent cooperative
operation, with two vehicles
communicating with each to potentially
issue a warning before a crash. Crashes
with four or more vehicles were not
included because the agency does not
have data to estimate how effective the
safety warning applications would be as
PO 00000
Frm 00135
Fmt 4701
Sfmt 4702
Percent
8.1
68.13
144.3
208.4
253.0
276.6
291.3
300.6
305.2
implementation: The size of the crash
population, the safety application
effectiveness, and vehicle
communication rates. The undiscounted
annual benefits thus are the product of
these three factors and can be expressed
mathematically by the following generic
formula:
Bi = P * E * Ci
With apps
3.3
27.4
55.8
77.6
90.8
96.2
98.6
99.7
100.0
Number of
vehicles
(million)
0.0
6.3
87.2
163.7
226.1
265.3
286.9
298.1
304.6
Percent
0.0
5.2
33.7
61.0
81.2
92.3
96.8
98.9
99.8
these crashes might involve complex
interactions among vehicles. Crashes
involving pedestrians and pedal-cyclists
were also excluded since these crashes
might need the communication between
vehicles and persons. Crashes involving
motorcycles were excluded because the
agency has not conducted any V2V
research on motorcycles. Finally,
crashes involving at least one heavy
vehicle 361 are excluded since the
agency is only evaluating light vehicle
crashes at this time.
Figure VII–2 depicts how the agency
determined the potential target
population for both the IMA and LTA
safety warning applications. In addition,
the figure also includes the
corresponding monetized values at each
‘‘stage’’ of filtering for the potential
target population. As indicated, the end
result is an estimated 1.06 million
crashes that could be addressed by the
IMA and LTA safety warning
applications, making up approximately
19 percent of the total police-reported
crashes. These crashes resulted in 2,372
fatalities and 0.69 million MAIS 1–5
injuries and damaged 1.29 million
vehicles. Together, these crashes cost
society $121 billion, annually.
Separately, IMA crashes resulted in
1,824 fatalities and 0.47 million MAIS
361 Heavy vehicles include trucks and buses with
a GVWR greater than 10,000 pounds.
E:\FR\FM\12JAP2.SGM
12JAP2
3988
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
to IMA, LTA has a smaller number of
target crashes. LTA crashes resulted in
548 fatalities and 0.22 million injuries
(MAIS 1–5) and damaged 0.32 million
vehicles. The IMA crashes cost society
$36 billion, annually.
The target populations used for this
analysis were retrieved from the 2010–
2013 FARS and GES. FARS is a census
of fatalities that occurred in fatal crashes
on public roadways. FARS was used to
derive the incidence of fatal target
crashes and associated fatalities. GES is
a sampling system of all police-reported
crashes. GES was used to derive the
MAIS 1+ injuries in non-fatal target
crashes and PDOVs. The agency utilized
multiple years of crash data to limit
variations of crashes and provide the
best possible estimate for projecting
potential benefits.
The variables used to define the target
crashes include vehicle forms
submitted, vehicle body type, crash
type, the first harmful event, relation to
roadway, roadway alignment, roadway
condition, rollover type, jackknife
status, driver contributing factor, and
vehicle contributing factor. Of these
variables, the driver contributing and
vehicle contributing factors were used
to refine the target population. The
driver contribution factor specifies
whether driver’s alertness contributed to
the crashes. The vehicle contributing
factor identifies whether vehicle’s
component failure or defect contributed
to the crashes. Crashes where
incapacitated or drowsy drivers were
involved and where vehicle mechanical
failures such as brake systems, tires,
steering, and transmissions were cited
as contributing factors were excluded.
respond to. To be able to estimate the
effectiveness of advanced crash
avoidance technology such as V2V,
NHTSA developed a methodology that
uses available data and computer
simulation,362 extending current
estimation capabilities and enabling
V2V technology to be ‘‘exposed’’ to
more conflict situations to make up for
and potential lack of crashes in the realworld crash databases. The
methodology and simulation tool allows
the agency to better comprehend the
crash avoidance potential and the
performance criteria of the V2V
technology prior to the technology’s
actual deployment. Extensive details on
how the agency estimates effectiveness
of potential V2V safety applications can
be found in Chapter 4 of the PRIA and
Chapter XII.B.1 of the V2V Readiness
Report.
Table VII–26 shows the effectiveness
of IMA and LTA used for the benefit
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
(b) Effectiveness (E)
The agency applied effectiveness rates
for IMA and LTA. The effectiveness rate
estimates are derived using the Safety
Impact Methodology (SIM) tool
developed by the Department of
Transportation’s Volpe Center,
specifically for estimating the
effectiveness of V2V technology. In
order to obtain a crash warning using
V2V technology, two V2V-equipped
vehicles need to interact during a
potential crash situation—if a V2Vequipped vehicle interacts with a nonV2V-equipped vehicle in a potential
crash situation, no warning is to be
expected, because the non-equipped
vehicle would produce no BSM for the
equipped vehicle to recognize and
PO 00000
Frm 00136
Fmt 4701
Sfmt 4702
362 For an overview of this methodology, see
‘‘Implementation of the Safety Impact Methodology
Tool’’ DRAFT located in Docket NHTSA–2016–
0126.
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.018
srobinson on DSK5SPTVN1PROD with PROPOSALS2
1–5 injuries and damaged 0.97 million
vehicles. The IMA crashes cost society
$84 billion, annually. When compared
3989
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
LDW displayed in the NCAP data. Based
on broad collection of implementation
information such as, the ITS study,
NCAP data, agency meetings with
manufacturers, announcements on V2V
implementation from vehicle industry,
and the cost consideration; the agency
established the a safety application
adoption trend of 0% for the first MY
vehicles that have DSRC radios, 5%,
10%, 25%, 40%, 65%, 90%, and 100%
for each following MY vehicles,
respectively.
The agency believes that this adoption
rate is reasonable. We note that the
pattern is similar to those shown in the
NCAP data; with slow initial rate
spanning approximately two years and
then increasing year over year at a rate
that would reach full adoption in the
eighth year of the implementation of the
DSRC technology. Under this adoption
scenario, the benefits estimates assume
IMA and LTA would not be deployed in
the first year. In the second year, with
the required 75 percent DSRC
installation rate and the five percent
safety application adoption among the
DSRC-equipped vehicles, five percent of
the total new vehicles (= 0.05 * 0.75) are
expected to have the two safety
applications. In the third year, 10
percent of the new vehicles (= 0.1 *
1.00) would have the apps, and so on so
forth. Overall, the benefits (and costs) of
the proposed rule were estimated based
on this specific technology adoption
scenario, as shown in Table VII–27.
(c) Communication Rate (Ci)
The communication rate (Ci) used the
generic benefit formula above,
represents the potential probability of a
crash in which the vehicles involved are
both DSRC-equipped light vehicles
utilizing the safety applications IMA
TABLE VII–26—EFFECTIVENESS OF
and LTA. To derive this probability, the
IMA AND LTA SAFETY APPLICATIONS agency first developed a projection of
the number of vehicles that would be
Low
High
equipped by leveraging the technology
Apps
(%)
(%)
adoption rates used for estimating the
IMA ...........
43
56 proposed rule costs. As discussed in the
LTA ...........
37
63 estimated cost section, the proposed
rule would require that all applicable
These estimates are adjusted slightly
vehicles are equipped allowing for a
from the effectiveness estimates used in market-driven adoption for safety
the V2V Readiness Report to reflect the
applications. The proposed requirement
latest crash data available to the agency. for DSRC radio adoption schedule is a
There are no changes in methodology
three year phase-in: 50 percent of the
for developing the effectiveness estimate first MY vehicles, 75 percent of the
from that used in the V2V Readiness
second MY vehicles and 100 percent of
Report. In the Readiness Report, the
the third MY vehicles. For benefits
agency estimated values of 41–55
estimation, the agency applied these
percent for IMA and 36–62 percent for
proposed, required adoption rates to
LTA, differences of only one to two
estimated, future vehicle sales yielding
percent at either end of the ranges. The
the potential vehicles that could be
differences originate in the minor
equipped with DSRC devices in the
adjustment in the injury probability
overall vehicle fleet.
curves for IMA and overall the newer
The agency believes a similar, marketcrash data yielded a different crash
driven approach could take hold for
scenario distribution. In order to
V2V technology once the equipment
account for potential uncertainty in
becomes widely available and
these effectiveness rates, the agency
consumers recognize the potential
included lower effectiveness rates in the benefits.
uncertainty analysis for this rule. The
The agency believes that IMA and
agency requests additional information
LTA could be adopted as standard
concerning the potential effectiveness of equipment on a schedule similar to the
these two applications.
‘‘combined’’ schedules for the FCW and
estimates in this proposal. As shown,
IMA is estimated to prevent 43–56
percent of intersection related crashes
and LTA would prevent 37–63 percent
of crashes where a left turn is being
attempted across oncoming traffic.
TABLE VII–27—V2V TECHNOLOGY ADOPTION SCENARIO FOR COST AND BENEFIT ESTIMATES
Year
(MY)
DSRC ...............................
Apps* ................................
Apps Actual ** ..................
1
(2021)
(%)
2
(2022)
(%)
50
0
0
3
(2023)
(%)
75
5
4
4
(2024)
(%)
100
10
10
5
(2025)
(%)
100
25
25
6
(2026)
(%)
100
40
40
100
65
65
7
(2027)
(%)
100
90
90
8
(2028)
(%)
100
100
100
srobinson on DSK5SPTVN1PROD with PROPOSALS2
* IMA and LTA of DSRC-equipped new vehicles.
** of all new vehicles.
Table VII–28 shows the
communication rates from 2021 to 2060
by vehicle type (i.e., PCs, LTVs, and PCs
and LTVs combined) separately for IMA
and LTA. As expected, the
communication rates would be
relatively small in the first few years
and accelerate faster when time
progresses.
The overall communication with
vehicles that had the apps would be rare
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
in the first three years as measured by
those rates for IMA. The rate would
reach over 50 percent (51.41%) in 2034,
the 14th year of the implementation of
the proposed rule. In 2039, 5 years later,
the rate would reach 75 percent. In
2044, the communication rate would
reach over 90 percent.
For LTA, the communication rates
would be smaller than the general
communication rates. In 2022, for
PO 00000
Frm 00137
Fmt 4701
Sfmt 4702
example, the contributable rate for LTA
with vehicles equipped with the apps is
about 0.02 percent, 50 percent of the
overall communication rate. However,
the ratio would increase over time and
narrow the difference between these two
rates. In 2034, the rate for LTA would
be 41.36 percent, 80.5 percent of the
overall communicating rate.
E:\FR\FM\12JAP2.SGM
12JAP2
3990
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–28—LIGHT VEHICLE FLEET COMMUNICATION RATES
IMA
Calendar
year
Year
1 ...................................
2 ...................................
3 ...................................
4 ...................................
5 ...................................
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
12 .................................
13 .................................
14 .................................
15 .................................
16 .................................
17 .................................
18 .................................
19 .................................
20 .................................
21 .................................
22 .................................
23 .................................
24 .................................
25 .................................
26 .................................
27 .................................
28 .................................
29 .................................
30 .................................
31 .................................
32 .................................
33 .................................
34 .................................
35 .................................
36 .................................
37 .................................
38 .................................
39 .................................
40 .................................
PCs
(%)
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Since the agency is not mandating any
applications, we next made an
assumption concerning at what rate
IMA and LTA could be adopted
voluntarily by industry. We contracted
with the Intelligent Transportation
Society of America (ITS America, or
ITS) to conduct a study to better
understand the utilization of DSRC
among stakeholders and to investigate
potential safety application deployment
and product development.363 As part of
the effort, ITS identified an array of V2V
and vehicle-to-infrastructure (V2I) apps
and interviewed 42 stakeholders
363 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 https://ntl.bts.gov/lib/60000/
60500/60535/FHWA-JPO-17-487_Final_.pdf (last
accessed Dec 12, 2016).
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
LTVs
(%)
0.00
0.02
0.13
0.52
1.32
2.77
4.94
7.55
10.40
13.45
16.63
19.90
23.19
26.46
29.65
32.69
35.53
38.12
40.40
42.36
43.99
45.18
46.11
46.81
47.33
47.72
48.04
48.29
48.49
48.65
48.75
48.81
48.82
48.81
48.78
48.73
48.65
48.54
48.43
48.33
(d) Adoption Rate of IMA and LTA
LTA
Combined
(%)
0.00
0.02
0.13
0.50
1.26
2.64
4.71
7.19
9.88
12.76
15.77
18.84
21.92
24.95
27.87
30.62
33.16
35.46
37.47
39.21
40.69
42.03
43.17
44.17
45.04
45.83
46.56
47.25
47.90
48.50
49.02
49.50
49.93
50.31
50.65
50.96
51.22
51.41
51.56
51.67
0.00
0.04
0.26
1.02
2.58
5.41
9.65
14.74
20.28
26.21
32.40
38.74
45.11
51.41
57.52
63.31
68.69
73.58
77.87
81.57
84.68
87.21
89.28
90.98
92.37
93.55
94.60
95.54
96.39
97.15
97.77
98.31
98.75
99.12
99.43
99.69
99.87
99.95
99.99
100.00
specifically about these apps’
development and deployment. The
stakeholders interviewed included
chipset manufacturers, mobile device
manufacturers, infrastructure industrial
equipment makers, vehicle original
equipment manufacturers (OEMs), and
academia. Based on the interview
results, ITS America concluded that
about 91 apps (including both V2V and
V2I) would likely to be deployed within
5 years of a DSRC mandate. IMA and
LTA were rated among the highest
priority apps among all the
interviewees.
The ITS study confirmed many
aspects of the agency’s proposed
requirements and assumptions
regarding potential V2V deployment
including the proposed implementation
timing. However, the study was not able
to predict clearly a safety application
adoption trend after an initial
PO 00000
Frm 00138
Fmt 4701
Sfmt 4702
PCs
(%)
LTVs
(%)
0.00
0.01
0.07
0.28
0.73
1.61
3.06
4.96
7.17
9.63
12.33
15.20
18.20
21.29
24.41
27.50
30.48
33.31
35.92
38.29
40.38
42.06
43.46
44.59
45.47
46.16
46.71
47.14
47.49
47.77
47.97
48.14
48.25
48.33
48.37
48.39
48.37
48.33
48.29
48.25
0.00
0.01
0.07
0.27
0.70
1.54
2.92
4.72
6.81
9.14
11.69
14.39
17.20
20.07
22.95
25.75
28.45
30.98
33.32
35.45
37.36
39.12
40.69
42.07
43.27
44.33
45.28
46.13
46.91
47.61
48.24
48.82
49.34
49.81
50.23
50.60
50.93
51.19
51.41
51.57
Combined
(%)
0.00
0.02
0.14
0.55
1.43
3.15
5.98
9.68
13.98
18.77
24.02
29.59
35.40
41.36
47.36
53.25
58.93
64.29
69.24
73.74
77.74
81.18
84.15
86.66
88.74
90.49
91.99
93.27
94.40
95.38
96.21
96.96
97.59
98.14
98.60
98.99
99.30
99.52
99.70
99.82
deployment. To fill this gap and
establish a potential trend, the agency
examined the adoption patterns of the
three crash avoiding warning systems
reported as part of regular data
submissions associated with the
agency’s New Car Assessment Program
(NCAP). The crash avoiding warning
systems are blind spot detection (BSD),
forward collision warning (FCW), and
Lane Departure Warning (LDW). We
note that only FCW and LDW are
currently reported on NHTSA’s Safer
Car technologies as being
‘‘Recommended Technologies,’’ while
BSD is reported to NHTSA for research
purposes but not, at this time, presented
to the public.
Table VII–29 lists the adoption rates
for these systems that were offered as
standard equipment and the combined
adoption rates for the technologies
offered as standard or optional. As
E:\FR\FM\12JAP2.SGM
12JAP2
3991
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
shown, the rate of the standard
equipment is relatively low, although it
increases gradually. In contrast, the rate
for the optional equipment (based on
the combined rates) was much higher
and the pace of the offering these
features increased faster. These warning
technologies are projected to reach the
full combined deployment around 2021
based on a curve linear regression
model resulting in an estimated full
deployment spanning ten years. This
projected rate is absent any sort of
formal regulation beyond the inclusion
in the agency’s NCAP ratings program.
TABLE VII–29—REPORTED ADOPTION RATES BY VEHICLE MANUFACTURERS
[Percent]
BSD
FCW
LDW
Year
Standard
2011
2012
2013
2014
2015
.........................................................
.........................................................
.........................................................
.........................................................
.........................................................
0.3
1.0
1.3
0.1
0.6
Combined *
Standard
11.9
30.0
30.4
27.0
45.7
Combined *
0.0
0.0
0.8
2.6
5.6
Standard
11.4
11.4
21.0
22.1
57.3
0.0
0.0
0.0
0.2
2.5
Combined *
2.5
5.9
17.4
15.8
52.7
* standard equipment and optional equipment combined.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
The agency believes a similar, marketdriven approach could take hold for
V2V technology once the equipment
becomes widely available and
consumers recognize the potential
benefits. The agency believes that IMA
and LTA could be adopted as standard
equipment on a schedule similar to the
‘‘combined’’ schedules for the FCW and
LDW displayed in the NCAP data.
Based on broad collection of
implementation information such as,
the ITS study, NCAP data, agency
meetings with manufacturers,
announcements on V2V implementation
from vehicle industry, and the cost
consideration; the agency established
the a safety application adoption trend
of 0% for the first MY vehicles that have
DSRC radios, 5%, 10%, 25%, 40%,
65%, 90%, and 100% for each following
MY vehicles, respectively. The agency
notes that the pattern is similar to those
shown in the NCAP data; with slow
initial rate spanning approximately two
years and then increasing year over year
at a rate that would reach full adoption
in the eighth year of the implementation
of the DSRC technology. Under this
adoption scenario, IMA and LTA would
not be deployed in the first year. In the
second year, with the required 75
percent DSRC installation rate and the
five percent safety application adoption
among the DSRC-equipped vehicles,
five percent of the total new vehicles (=
0.05 * 0.75) are expected to have the
two safety applications. In the third
364 Would occur 43 years after the first
implementation.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
year, 10 percent of the new vehicles (=
0.1 * 1.00) would have the apps, and so
on so forth. Overall, the benefits (and
costs) of the proposed rule were
estimated based on this specific
technology adoption scenario, as shown
in Table VII–27. However, in order to
test the significant uncertainty in this
assumption, we included adoption rate
as one of the variables in our
uncertainty analysis.
The agency, though, requests
comment on these assumption. Do
commenters have more concrete data
concerning the potential or likely
adoption rate of these applications? Are
there any other technologies that have
been voluntarily introduced into the
fleet that the agency should consider
when projecting the potential adoption
rate of IMA and LTA?
• equivalent to 13 to 18 percent of
multiple light-vehicle crashes
• Save 987 to 1,366 lives
• Reduce 305,000 to 418,000 MAIS 1–
5 injuries,365 and
• Eliminate 537,000 to 746,000
property damage only vehicles (PDOVs)
(2) Annual Benefits
• Prevent 439,000 to 615,000 crashes
annually
The annual benefits are summarized
every five years from 2021 to 2060 in
Table VII–30. As shown, the proposed
rule would not yield benefits in Year 1
due to the zero percent safety
application adoption rates for new
vehicles in that year. However, the
agency estimates that five years after a
final rule is issued, Year 5 (2025),
10,094 to 13,763 annual vehicle crashes
would potentially be prevented, saving
23 to 31 lives and preventing 6,946 to
9,197 MAIS 1–5 injuries. Moreover, the
agency estimates this proposed rule has
the potential to prevent 12,496 to 16,949
damaged vehicles.
As the fleet penetration increases, the
proposed rule could prevent 107,120 to
147,615 crashes, save 244 to 332 lives,
and reduce 73,983 to 99,254 MAIS 1–5
injuries by Year 10, a more than ten-fold
increase from Year 5.
After 20 years, the agency estimates
about 80 percent of the maximum
benefits will be achievable. The yields
an estimated to 349,914 to 487,561
crashes prevented, 789 to 1,089 lives
save, and the reduction of 242,589 to
329,909 MAIS 1–5 injuries.
365 MAIS (Maximum Abbreviated Injury Scale)
represents the maximum injury severity of an
occupant at an Abbreviated Injury Scale (AIS) level.
AIS ranks individual injuries by body region on a
scale of 1 to 6: 1=minor, 2=moderate, 3=serious,
4=severe, 5=critical, and 6=maximum (untreatable).
2. Injury and Property Damage Benefits
(a) Annual Injury and Property Damage
Benefits
(1) Maximum Annual Benefits
The maximum annual benefits
represent the crashes, fatalities, injuries,
and property damage vehicles (PDOVs)
that can be reduced annually after the
full adoption of DSRC and safety related
applications.364 Once fully deployed,
the agency estimates the proposed rule
would:
PO 00000
Frm 00139
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
3992
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–30—SUMMARY OF ANNUAL BENEFITS OF THE PROPOSED RULE
[Undiscounted]
Calendar
year
Year
1 .................................
5 .................................
10 ...............................
15 ...............................
20 ...............................
25 ...............................
30 ...............................
35 ...............................
40 ...............................
2021
2025
2030
2035
2040
2045
2050
2055
2060
Crashes
Fatalities
Low
High
0
10,094
107,120
241,740
349,914
401,894
424,901
435,932
439,138
0
13,763
147,615
335,287
487,561
561,737
594,569
610,326
615,028
(b) Lifetime Injury and Property Damage
Benefits by Vehicle Model Year
The lifetime benefits for a MY vehicle
(also MY Benefits), as described earlier,
represent the total benefits that would
be accrued through the life of a vehicle.
The MY benefits represent the total
benefits that would be accrued though
the life of a vehicle. The lifetime
benefits can occur at any time during
the in-use life of a vehicle and are
required to be discounted to reflect their
present values (2014 dollars). The
discounting procedures for future
benefits and costs in regulatory analyses
are based on the guidelines published in
OMB Circular A–4 and OMB Circular
A–94 Revised.
The agency’s analysis for determining
lifetime benefits uses two approaches.
One approach is a so-called ‘‘free rider’’
approach and the other is the ‘‘no freerider’’ approach, where the primary
difference is the treatment on the
distribution of benefits from crashes
involving different MY vehicles.
Low
MAIS 1–5 injuries
High
0
23
244
547
789
904
955
980
987
0
31
332
751
1,087
1,249
1,321
1,355
1,365
The ‘‘free-rider approach’’ is based on
the notion that the lifetime benefits of
a specific MY vehicle should
correspond to the investment up to that
specific MY of vehicles and that benefits
should be credited to the later MY
vehicles. For example, if benefits are
from a crash that involved a MY 2021
vehicle and a MY 2030 vehicle, under
this approach, all benefits would be
credited to the MY 2030 vehicle. The
MY 2021 vehicle would not receive any
benefits because the benefits would not
be realized until the investment on the
MY 2030 vehicles is made. In contrast,
the ‘‘no free-rider’’ approach is based on
the notion that benefits should be
shared among all vehicles since the
future investment will continue because
of the proposed rule. With the same case
above, the no free-rider approach allows
both MY 2021 and MY 2030 vehicles to
share a portion of the benefits.
Additional details on the methodology
and derivation of benefits of these two
approaches can be found in Chapter V
of the PRIA prepared in support of this
proposal.
PDOVs
Low
High
Low
High
0
6,946
73,983
167,329
242,589
278,926
295,009
302,723
304,986
0
9,197
99,254
226,278
329,909
380,771
403,284
414,094
417,366
0
12,496
131,946
296,835
428,697
491,628
519,483
532,831
536,657
0
16,949
180,693
408,920
593,093
682,127
721,535
740,437
745,996
(1) Injury and Property Damage Benefits
by Model Year and Approach
Table VII–31 and Table VII–32 show
the MY specific injury and property
damage benefits (i.e., the lifetime
benefits for a specific MY vehicle) for
the ‘‘free rider approach’’ for the 3 and
7 percent discount, respectively. In
parallel, Table VII–33 and Table VII–34
show the benefits for the ‘‘no free-rider’’
approach also at a 3 and 7 percent
discount rate, respectively.
The analysis estimates the lifetime
benefits only for MYs 2021 to 2050
vehicles. For 2050 MY vehicles, its
lifetime benefits would be realized from
year 2040 to year 2086. As described in
the annual benefit section, the annual
benefits would be stabilized at the
maximum level around year 2062.
Furthermore, after MY 2050, vehicle
sales were assumed to at the MY 2050
level. Therefore, the lifetime benefits for
vehicles newer than MY 2050 would be
stabilized at the MY 2050 level.
TABLE VII–31—MY BENEFITS FOR LIGHT VEHICLES FREE-RIDER APPROACH AT 3 PERCENT DISCOUNT
Crash prevented
Year
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Low
1 .................................
2 .................................
3 .................................
4 .................................
5 .................................
6 .................................
7 .................................
8 .................................
9 .................................
10 ...............................
11 ...............................
12 ...............................
13 ...............................
14 ...............................
15 ...............................
16 ...............................
17 ...............................
18 ...............................
19 ...............................
VerDate Sep<11>2014
Fatalities eliminated
MAIS 1–5 injuries
PDOVs
Model year
23:49 Jan 11, 2017
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
Jkt 241001
High
0
271
1,821
8,138
20,094
45,766
86,774
125,283
151,801
175,685
196,823
215,458
231,828
247,041
260,349
271,907
282,112
290,458
297,903
0
369
2,484
11,116
27,510
62,828
119,428
172,790
209,713
243,053
272,641
298,792
321,830
343,282
362,101
378,496
393,009
404,930
415,591
PO 00000
Frm 00140
Low
High
0
1
4
19
46
104
198
285
345
398
446
488
524
558
588
614
636
655
671
Fmt 4701
Sfmt 4702
0
1
6
25
62
142
269
389
471
545
611
669
720
767
809
845
877
903
926
Low
High
Low
High
0
187
1,254
5,604
13,847
31,567
59,905
86,552
104,932
121,501
136,178
149,129
160,518
171,108
180,382
188,445
195,570
201,406
206,617
0
246
1,660
7,436
18,427
42,151
80,243
116,237
141,211
163,794
183,866
201,633
217,309
231,922
244,762
255,966
265,900
274,078
281,402
0
336
2,255
10,066
24,828
56,477
106,948
154,257
186,755
215,991
241,830
264,580
284,539
303,068
319,252
333,289
345,664
355,763
364,761
0
455
3,059
13,675
33,799
77,072
146,292
211,408
256,340
296,855
332,755
364,439
392,308
418,229
440,931
460,676
478,129
492,430
505,202
E:\FR\FM\12JAP2.SGM
12JAP2
3993
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–31—MY BENEFITS FOR LIGHT VEHICLES FREE-RIDER APPROACH AT 3 PERCENT DISCOUNT—Continued
Crash prevented
Year
Low
20
21
22
23
24
25
26
27
28
29
30
Fatalities eliminated
MAIS 1–5 injuries
PDOVs
Model year
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
High
305,087
312,804
305,604
308,426
310,949
313,325
315,443
317,611
319,665
321,616
323,726
Low
425,875
436,885
427,030
431,146
434,815
438,253
441,309
444,417
447,353
450,138
453,138
High
687
704
688
694
699
705
709
714
719
723
728
948
972
950
959
967
974
981
987
994
1,000
1,006
Low
High
Low
High
211,645
217,039
212,077
214,065
215,841
217,510
218,996
220,514
221,951
223,315
224,788
288,466
296,015
289,414
292,270
294,812
297,187
299,295
301,432
303,447
305,356
307,409
373,446
382,788
373,891
377,270
380,294
383,150
385,700
388,318
390,802
393,165
395,724
517,525
530,741
518,632
523,513
527,871
531,965
535,611
539,332
542,853
546,196
549,803
TABLE VII–32—MY BENEFITS FOR LIGHT VEHICLES FREE-RIDER APPROACH AT 7 PERCENT DISCOUNT
Crash prevented
Year
Fatalities eliminated
MAIS 1–5 injuries
PDOVs
Model year
Low
1 .................................
2 .................................
3 .................................
4 .................................
5 .................................
6 .................................
7 .................................
8 .................................
9 .................................
10 ...............................
11 ...............................
12 ...............................
13 ...............................
14 ...............................
15 ...............................
16 ...............................
17 ...............................
18 ...............................
19 ...............................
20 ...............................
21 ...............................
22 ...............................
23 ...............................
24 ...............................
25 ...............................
26 ...............................
27 ...............................
28 ...............................
29 ...............................
30 ...............................
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
High
0
256
1,703
7,517
18,321
41,157
77,149
110,525
133,399
154,035
172,397
188,544
202,920
216,257
227,911
238,068
247,120
254,424
260,956
267,247
273,843
267,553
270,054
272,178
274,288
276,078
278,074
279,772
281,380
283,192
Low
0
348
2,322
10,264
25,071
56,470
106,128
152,362
184,211
213,015
238,716
261,378
281,609
300,416
316,898
331,308
344,183
354,622
363,981
372,995
382,418
373,820
377,472
380,572
383,630
386,219
389,079
391,511
393,809
396,388
High
0
1
4
17
42
94
176
251
303
349
391
427
459
489
515
537
558
574
588
602
617
602
608
612
617
621
625
629
633
637
0
1
5
23
57
128
239
343
414
478
535
585
630
672
708
740
768
791
811
831
851
832
839
846
853
858
864
870
875
880
Low
High
Low
High
0
176
1,172
5,175
12,623
28,383
53,251
76,343
92,198
106,513
119,263
130,486
140,486
149,771
157,892
164,978
171,299
176,407
180,980
185,384
189,997
185,665
187,427
188,924
190,407
191,664
193,061
194,250
195,374
196,640
0
232
1,552
6,865
16,789
37,874
71,286
102,466
124,008
143,518
160,954
176,350
190,116
202,927
214,173
224,022
232,835
239,999
246,431
252,625
259,091
253,336
255,872
258,023
260,137
261,926
263,891
265,562
267,140
268,906
0
317
2,109
9,300
22,643
50,801
95,110
136,116
164,150
189,411
211,857
231,570
249,097
265,341
279,513
291,846
302,824
311,659
319,551
327,152
335,132
327,356
330,347
332,888
335,424
337,576
339,986
342,038
343,983
346,180
0
429
2,860
12,630
30,811
69,294
130,038
186,464
225,223
260,228
291,412
318,868
343,341
366,065
385,947
403,300
418,783
431,301
442,510
453,305
464,608
454,035
458,363
462,038
465,677
468,762
472,186
475,099
477,855
480,956
TABLE VII–33—MY BENEFITS FOR LIGHT VEHICLES NO FREE-RIDER APPROACH AT 3 PERCENT DISCOUNT
Crash prevented
Year
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Low
1 .................................
2 .................................
3 .................................
4 .................................
5 .................................
6 .................................
7 .................................
8 .................................
9 .................................
10 ...............................
11 ...............................
12 ...............................
13 ...............................
14 ...............................
VerDate Sep<11>2014
Fatalities eliminated
MAIS 1–5 injuries
PDOVs
Model year
23:49 Jan 11, 2017
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
Jkt 241001
High
0
4,006
12,297
34,161
59,813
104,216
153,676
180,917
190,032
199,389
207,808
215,391
222,098
228,851
0
5,506
16,917
47,041
82,461
143,863
212,415
250,375
263,281
276,526
288,476
299,268
308,843
318,485
PO 00000
Frm 00141
Low
High
0
9
28
78
136
237
349
410
430
451
470
487
502
517
Fmt 4701
Sfmt 4702
0
12
38
106
186
323
477
562
590
619
645
669
690
711
Low
High
Low
High
0
2,764
8,488
23,588
41,316
72,020
106,247
125,133
131,488
138,010
143,885
149,181
153,870
158,591
0
3,697
11,363
31,616
55,459
96,827
143,074
168,761
177,573
186,614
194,784
202,173
208,741
215,353
0
4,941
15,159
42,093
73,659
128,262
189,014
222,387
233,465
244,840
255,061
264,254
272,371
280,546
0
6,750
20,727
57,606
100,913
175,926
259,566
305,740
321,299
337,269
351,656
364,628
376,118
387,688
E:\FR\FM\12JAP2.SGM
12JAP2
3994
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–33—MY BENEFITS FOR LIGHT VEHICLES NO FREE-RIDER APPROACH AT 3 PERCENT DISCOUNT—Continued
Crash prevented
Year
Low
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Fatalities eliminated
MAIS 1–5 injuries
PDOVs
Model year
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
...............................
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
High
234,712
239,796
244,444
248,150
251,493
254,958
258,973
251,474
252,797
254,138
255,409
256,606
257,844
258,876
259,929
261,241
Low
326,883
334,194
340,890
346,265
351,122
356,134
361,900
351,552
353,515
355,482
357,336
359,072
360,856
362,342
363,853
365,723
High
530
541
551
559
566
574
583
566
569
572
574
577
580
582
584
587
729
745
760
771
782
792
805
782
786
790
794
798
802
805
808
812
Low
High
Low
High
162,695
166,258
169,518
172,124
174,475
176,909
179,722
174,540
175,478
176,425
177,320
178,162
179,030
179,754
180,492
181,408
221,125
226,159
230,774
234,492
237,855
241,317
245,284
238,321
239,695
241,064
242,350
243,551
244,781
245,805
246,844
248,125
287,627
293,758
299,356
303,807
307,817
311,982
316,828
307,596
309,167
310,767
312,289
313,725
315,217
316,460
317,732
319,322
397,746
406,483
414,478
420,872
426,644
432,615
439,511
426,854
429,160
431,486
433,684
435,749
437,879
439,653
441,462
443,708
TABLE VII–34—MY BENEFITS FOR LIGHT VEHICLES NO FREE-RIDER APPROACH AT 7 PERCENT DISCOUNT
Crash prevented
Year
Low
1 .................................
2 .................................
3 .................................
4 .................................
5 .................................
6 .................................
7 .................................
8 .................................
9 .................................
10 ...............................
11 ...............................
12 ...............................
13 ...............................
14 ...............................
15 ...............................
16 ...............................
17 ...............................
18 ...............................
19 ...............................
20 ...............................
21 ...............................
22 ...............................
23 ...............................
24 ...............................
25 ...............................
26 ...............................
27 ...............................
28 ...............................
29 ...............................
30 ...............................
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
High
0
3,026
9,423
26,555
46,855
82,119
121,940
144,104
152,069
160,196
167,621
174,185
180,128
186,049
191,219
195,680
199,807
202,975
205,888
208,845
212,188
205,999
207,175
208,251
209,421
210,280
211,429
212,258
213,224
214,216
0
4,154
12,946
36,520
64,517
113,231
168,381
199,249
210,514
222,006
232,533
241,865
250,340
258,785
266,186
272,596
278,538
283,135
287,369
291,652
296,460
287,930
289,675
291,263
292,967
294,224
295,876
297,073
298,458
299,875
srobinson on DSK5SPTVN1PROD with PROPOSALS2
(2) Summary of Injury and Property
Damage Benefits by Model Year
Under both approaches, the MY
benefits were derived by dividing the
annual benefits among all involved MY
vehicles according to their survived
volume and vehicle miles traveled.
Afterwards, the annual benefits for that
specific MY vehicles were discounted
by multiplying them with an
appropriate discounting factor. Finally,
VerDate Sep<11>2014
Fatalities eliminated
MAIS 1–5 injuries
PDOVs
Model year
23:49 Jan 11, 2017
Jkt 241001
Low
High
0
7
21
60
107
187
277
327
345
363
379
394
407
420
432
441
450
457
464
470
478
464
466
468
471
473
475
477
479
481
0
9
29
82
145
255
378
447
472
497
521
541
559
578
594
608
621
631
640
649
660
640
644
647
651
654
657
660
663
666
we summed the annual discounted
benefits of that MY vehicles over their
operational lifespan to derive the MY
benefits. These benefits were discounted
at a 3 percent and 7 percent discount
rate to represent their present value.
Table VII–35 and Table VII–36 presents
the discounted MY benefits from MY
2021 to MY 2050 vehicles for every five
MYs. As shown, the first MY vehicles
(i.e., MY 2021) would not accrue
benefits due to the adoption scenario
PO 00000
Frm 00142
Fmt 4701
Sfmt 4702
Low
High
Low
High
0
2,087
6,501
18,328
32,352
56,727
84,277
99,640
105,191
110,854
116,033
120,615
124,769
128,907
132,525
135,651
138,545
140,773
142,823
144,901
147,244
142,969
143,803
144,564
145,388
145,994
146,799
147,381
148,057
148,751
0
2,787
8,689
24,527
43,361
76,161
113,350
134,231
141,918
149,758
156,950
163,337
169,145
174,934
180,018
184,430
188,523
191,705
194,636
197,597
200,908
195,173
196,394
197,502
198,684
199,557
200,694
201,521
202,472
203,445
0
3,735
11,624
32,742
57,736
101,122
150,052
177,213
186,899
196,784
205,804
213,764
220,962
228,133
234,382
239,763
244,737
248,540
252,034
255,587
259,617
251,993
253,389
254,669
256,071
257,098
258,483
259,481
260,648
261,848
0
5,096
15,874
44,755
79,010
138,557
205,873
243,433
257,022
270,886
283,568
294,792
304,969
315,108
323,976
331,640
338,737
344,204
349,234
354,333
360,079
349,638
351,688
353,558
355,582
357,069
359,043
360,471
362,129
363,829
used in the PRIA. At a three percent
discount rate, the 5th applicable MY
vehicles (MY 2025) would prevent
20,094 to 82,481 crashes, save 46 to 186
lives, and reduce 13,847 to 55459 MAIS
1–5 injuries. At this discount, the MY
2025 would also eliminate 24,828 to
100,913 PDOVs. The 30th MY vehicles
(MY 2050) would prevent 261,241 to
453,138 crashes, save 587 to 1,006 lives,
reduce 181,408 to 307,409 injuries, and
eliminate up to 549,803 PDOVs.
E:\FR\FM\12JAP2.SGM
12JAP2
3995
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
At a seven percent discount rate, MY
2025 vehicles would prevent 18,321 to
65,517 crashes, save 42 to 145 lives,
reduce 12,623 to 43,361 MAIS 1–5
injuries and eliminate 22,643 to 79,010
PDOVs. The MY 2050 vehicles would
prevent 214,216 to 396,388 crashes, save
481 to 880 lives, reduce 148,741 to
268,906 MAIS 1–5 injuries, and
eliminate up to 480,956 PDOVs.
TABLE VII–35—SUMMARY OF MY INJURY AND PROPERTY DAMAGE BENEFITS (AT 3% DISCOUNT)
Crashes
Year
Fatalities
MAIS 1–5 Injuries
PDOVs
Model year
Low
1 .................................
5 .................................
10 ...............................
15 ...............................
20 ...............................
25 ...............................
30 ...............................
2021
2025
2030
2035
2040
2045
2050
High
0
20,094
175,685
234,712
254,958
255,409
261,241
Low
0
82,461
276,526
362,101
425,875
438,253
453,138
High
0
46
398
530
574
574
587
0
186
619
809
948
974
1,006
Low
High
Low
High
0
13,847
121,501
162,695
176,909
177,320
181,408
0
55,459
186,614
244,762
288,466
297,187
307,409
0
24,828
215,991
287,627
311,982
312,289
319,322
0
100,913
337,269
440,931
517,525
531,965
549,803
TABLE VII–36—SUMMARY OF MY INJURY AND PROPERTY DAMAGE BENEFITS (AT 7% DISCOUNT)
Crashes
Year
Fatalities
MAIS 1–5 Injuries
PDOVs
Model year
Low
1 .................................
5 .................................
10 ...............................
15 ...............................
20 ...............................
25 ...............................
30 ...............................
2021
2025
2030
2035
2040
2045
2050
High
0
18,321
154,035
191,219
208,845
209,421
214,216
0
64,517
222,006
316,898
372,995
383,630
396,388
Note that the range of benefits is due
to the use of a range of effectiveness
rates and the two MY benefit estimating
approaches. The two benefit
approaches, labeled as ‘‘free-rider’’ and
‘‘no free-rider’’ approaches, deployed a
different treatment on the distribution of
benefits from crashes involving different
MY vehicles.
3. Monetized Benefits
The agency developed the monetized
benefits by applying the comprehensive
cost for a fatality to the total equivalent
lives saved (i.e., fatal equivalents) in
accordance with Department of
Transportation 2015 guidance.366. The
guidance requires the identified
nonfatal MAIS injuries and PDOVs to be
expressed in terms of fatalities. This is
Low
High
0
42
349
432
470
471
481
0
145
497
708
831
853
880
done by comparing the comprehensive
cost of preventing nonfatal injuries to
that of preventing a fatality.
Comprehensive costs include economic
costs and the value of quality life
(QALYs). Economic costs reflect the
tangible costs of reducing fatalities and
injuries which includes savings from
medical care, emergency services,
insurance administration, workplace
costs, legal costs, congestion and
property damage, as well as lost
productivity. The QALY captures the
intangible value of lost quality-of-life
that results from potential fatalities and
injuries.
Table VII–37 shows the
comprehensive values and the relative
fatality ratios for MAIS injuries and
PDOVs that were used to derived the
Low
High
Low
High
0
12,623
106,513
132,525
144,901
145,388
148,751
0
43,361
149,758
214,173
252,625
260,137
268,906
0
22,643
189,411
234,382
255,587
256,071
261,848
0
79,010
270,886
385,947
453,305
465,677
480,956
fatal equivalents.367 As shown, the
comprehensive cost of preventing a
fatality is currently valued at $9.7
million. A MAIS 5 injury, for example,
is 0.6136 fatal equivalents. Thus,
monetized benefits can be derived by
multiplying $9.7 million by the derived
fatal equivalents.
Table VII–37 also shows the unit costs
for congestion and property damage.
These two costs are considered to be
part of the comprehensive costs. The
congestion and property damage costs
are provided now for later use when
calculating the net costs of the proposed
rule. The net costs are defined as the
total vehicle costs minus the savings
from reducing property damage and
crash related congestion.
TABLE VII–37—UNIT CONGESTION, PROPERTY DAMAGE, AND COMPREHENSIVE COST
[2014 $]
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Injury category
PDOVs
MAIS 0
MAIS 1
MAIS 2
MAIS 3
Congestion
.........................................................................................................
.........................................................................................................
.........................................................................................................
.........................................................................................................
.........................................................................................................
366 ‘‘Guidance on the Treatment of the Economic
Value of a Statistical Life (VSL) in U.S. Department
of Transportation Analyses’’ February 28, 2013,
https://www.transportation.gov/sites/dot.dev/files/
docs/
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
$2,280
1,535
1,545
1,572
1,615
DOT%202013%20Signed%20VSL%20Memo.pdf
(last accessed Dec 8, 2016).
367 Revise to 2014 $ from the unit costs published
in this report, Blincoe, L. J., Miller, T. R., Zaloshnja,
PO 00000
Frm 00143
Fmt 4701
Sfmt 4702
Property
damage
Comprehensive
cost
$3,908
2,923
8,641
9,239
17,400
$6,591
4,753
47,144
449,239
1,065,032
Relative
fatality ratio
$0.0007
0.0005
0.0049
0.0463
0.1097
E., & Lawrence, B. A. (2015, May). The economic
and societal impact of motor vehicle crashes, 2010.
(Revised) (Report No. DOT HS 812 013).
Washington, DC: National Highway Traffic Safety
Administration.
E:\FR\FM\12JAP2.SGM
12JAP2
3996
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–37—UNIT CONGESTION, PROPERTY DAMAGE, AND COMPREHENSIVE COST—Continued
[2014 $]
Injury category
Congestion
MAIS 4 .........................................................................................................
MAIS 5 .........................................................................................................
Fatality .........................................................................................................
(a) Monetized Annual Benefits
Table VII–38 provides the
undiscounted annual fatal equivalents,
monetized benefits, and property
damage and congestion savings of the
proposed rule from the year 2021 to
2060. As shown, by Year 5 the proposed
rule is estimated to save 129 to 169 fatal
equivalents totaling approximately $1.3
to $1.6 billion annually. Approximately
12 percent of the monetized savings,
Property
damage
1,638
1,657
6,200
$176 to $237 million, are from the
estimated reduction of property damage
and congestion. By the year 2060, with
V2V fully deployed, the proposed rule
is estimated to save approximately 5,631
to 7,613 fatal equivalents annually.
Finally, the total associated monetized
annual savings would range from $54.7
to $73.9 billion. Of these savings, $7.7
to $10.6 billion is estimated to be
property damage and congestion
savings.
Comprehensive
cost
17,727
16,385
12,172
2,612,382
5,958,375
9,710,659
Relative
fatality ratio
0.2690
0.6136
1.0000
(b) Maximum Monetized Annual Benefit
The proposed rule would save a
maximum of $54.7 to $74.0 billion
annually after the full adoption of DSRC
radios and the two safety apps. Of these
amounts, $7.7 to $10.6 billion are the
potential savings from reducing crash
related congestion and vehicle property
damage.
TABLE VII–38—ANNUAL MONETIZED BENEFITS
[Undiscounted, 2014 $ in millions]
Fatal
equivalents
Calendar
year
Year
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Low
1 ...................................
2 ...................................
3 ...................................
4 ...................................
5 ...................................
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
12 .................................
13 .................................
14 .................................
15 .................................
16 .................................
17 .................................
18 .................................
19 .................................
20 .................................
21 .................................
22 .................................
23 .................................
24 .................................
25 .................................
26 .................................
27 .................................
28 .................................
29 .................................
30 .................................
31 .................................
32 .................................
33 .................................
34 .................................
35 .................................
36 .................................
37 .................................
38 .................................
39 .................................
40 .................................
VerDate Sep<11>2014
23:49 Jan 11, 2017
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
Jkt 241001
High
0.00
1.98
12.98
50.94
129.38
273.40
492.69
760.14
1,055.03
1,373.29
1,708.97
2,055.46
2,406.57
2,756.78
3,099.49
3,427.08
3,734.36
4,016.39
4,267.25
4,486.82
4,674.40
4,829.59
4,958.71
5,065.75
5,153.64
5,228.04
5,293.45
5,351.13
5,402.91
5,448.79
5,486.64
5,519.98
5,547.41
5,570.75
5,590.30
5,606.76
5,618.70
5,625.16
5,629.36
5,631.45
PO 00000
Total monetized
benefits
Frm 00144
Low
0.00
2.57
16.97
66.58
169.32
358.63
648.24
1,003.08
1,395.74
1,820.47
2,269.74
2,734.45
3,206.42
3,678.26
4,141.07
4,584.47
5,001.37
5,384.96
5,727.35
6,028.11
6,286.06
6,500.30
6,679.27
6,827.92
6,950.12
7,053.49
7,144.11
7,223.76
7,295.12
7,358.22
7,410.41
7,456.51
7,494.52
7,526.96
7,554.13
7,577.01
7,593.79
7,603.20
7,609.56
7,612.92
Fmt 4701
Property damage and
congestion
Sfmt 4702
High
$0.00
19.18
126.05
494.62
1,256.34
2,654.86
4,784.30
7,381.47
10,245.07
13,335.53
16,595.21
19,959.89
23,369.32
26,770.14
30,098.04
33,279.20
36,263.04
39,001.73
41,437.81
43,569.99
45,391.52
46,898.45
48,152.35
49,191.70
50,045.25
50,767.72
51,402.88
51,963.02
52,465.83
52,911.30
53,278.83
53,602.60
53,868.95
54,095.66
54,285.50
54,445.28
54,561.30
54,623.95
54,664.73
54,685.04
$0.00
24.99
164.75
646.51
1,644.21
3,482.52
6,294.87
9,740.54
13,553.52
17,677.94
22,040.63
26,553.31
31,136.42
35,718.29
40,212.46
44,518.16
48,566.54
52,291.53
55,616.35
58,536.92
61,041.76
63,122.18
64,860.05
66,303.56
67,490.21
68,493.96
69,373.99
70,147.39
70,840.43
71,453.12
71,959.96
72,407.63
72,776.73
73,091.76
73,355.51
73,577.69
73,740.69
73,832.03
73,893.77
73,926.44
E:\FR\FM\12JAP2.SGM
12JAP2
Low
$0.00
2.69
17.67
69.35
176.14
372.24
670.88
1,035.15
1,436.84
1,870.39
2,327.71
2,799.80
3,278.19
3,755.42
4,222.44
4,668.90
5,087.70
5,472.13
5,814.11
6,113.46
6,369.24
6,580.86
6,756.97
6,902.96
7,022.85
7,124.33
7,213.54
7,292.20
7,362.81
7,425.36
7,476.97
7,522.44
7,559.85
7,591.69
7,618.36
7,640.80
7,657.10
7,665.92
7,671.66
7,674.53
High
$0.00
3.60
23.75
93.20
237.00
501.88
906.96
1,403.08
1,951.93
2,545.51
3,173.24
3,822.44
4,481.66
5,140.59
5,786.78
6,405.77
6,987.66
7,522.96
8,000.63
8,420.10
8,779.76
9,078.39
9,327.77
9,534.88
9,705.13
9,849.14
9,975.43
10,086.44
10,185.94
10,273.91
10,346.67
10,410.92
10,463.88
10,509.08
10,546.93
10,578.80
10,602.17
10,615.22
10,624.03
10,628.67
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
(c) Monetized Benefits by Vehicle
Model Year
The range of the monetized benefits
by vehicle model year (i.e., the lifetime
benefits of a MY vehicles) represents the
estimates from both the ‘‘free-rider’’ and
‘‘no free-rider’’ approaches. The lower
bound of the range represents the low
estimate from the ‘‘free-rider’’ approach
and upper bound represents the high
estimate of ‘‘no free-rider’’ approach.
For each approach, the low and high
estimates correspond to the low and
high app effectiveness, respectively.
Table VII–39 and Table VII–40 show the
monetized MY benefits at a 3 percent
and 7 percent discount rate,
respectively.
As shown, at a three percent discount
rate, MY 2022 vehicles would save 3 to
68 fatal equivalent and $33.8 to $659.0
million over their lifespan. MY 2050
vehicles would save a total 3,350 to
5,608 fatal equivalents and $32.5 to
$54.5 billion. The property damage and
congestion savings would range from
$4.7 to $94.9 million for MY 2022
3997
vehicles and $4.6 to $7.8 billion for
2050 MY vehicles.
At a seven percent discount rate, the
MY 2022 vehicles would save 3 to 51
fatal equivalents and $31.8 to $497.0
million over their lifespan. MY 2050
vehicles would save a total 2,747 to
4,906 fatal equivalents and $26.7 to
$47.6 billion. Of these monetized
savings, the property damage and
congestion savings are estimated to be
$4.5 to $71.6 million for MY 2022
vehicles and $3.7 to $6.8 billion for
2050 MY vehicles.
TABLE VII–39—MONETIZED MY BENEFITS AT 3 PERCENT DISCOUNT
[2014 $ in millions]
Year
Fatal
equivalents
Model year
Low
1 ...................................
2 ...................................
3 ...................................
4 ...................................
5 ...................................
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
12 .................................
13 .................................
14 .................................
15 .................................
16 .................................
17 .................................
18 .................................
19 .................................
20 .................................
21 .................................
22 .................................
23 .................................
24 .................................
25 .................................
26 .................................
27 .................................
28 .................................
29 .................................
30 .................................
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
Total monetized
benefits
High
0.00
3.48
23.35
104.31
257.57
586.69
1,112.42
1,606.16
1,946.18
2,252.45
2,523.52
2,761.74
2,847.78
2,934.41
3,009.61
3,074.84
3,134.46
3,182.03
3,224.93
3,269.38
3,320.90
3,224.76
3,241.75
3,258.96
3,275.27
3,290.63
3,306.52
3,319.75
3,333.27
3,350.10
Property damage and
congestion
Low
0.00
67.86
208.55
580.04
1,017.05
1,774.90
2,621.45
3,090.78
3,250.93
3,415.26
3,563.63
3,697.69
3,975.69
4,241.63
4,475.08
4,678.59
4,858.86
5,007.07
5,139.68
5,267.60
5,404.46
5,283.11
5,334.51
5,380.31
5,423.17
5,461.25
5,499.93
5,536.44
5,571.05
5,608.31
High
$0.00
33.79
226.72
1,012.92
2,501.20
5,697.12
10,802.30
15,596.91
18,898.69
21,872.79
24,505.02
26,818.31
27,653.77
28,495.06
29,225.26
29,858.67
30,437.71
30,899.56
31,316.16
31,747.87
32,248.10
31,314.49
31,479.52
31,646.62
31,805.05
31,954.16
32,108.44
32,236.99
32,368.22
32,531.65
$0.00
658.99
2,025.12
5,632.53
9,876.22
17,235.41
25,455.98
30,013.55
31,568.66
33,164.45
34,605.22
35,906.98
38,606.57
41,189.00
43,456.01
45,432.21
47,182.69
48,621.96
49,909.68
51,151.88
52,480.81
51,302.48
51,801.61
52,246.36
52,662.57
53,032.36
53,407.94
53,762.45
54,098.58
54,460.39
Low
$0.00
4.74
31.79
142.02
350.72
798.94
1,515.02
2,187.63
2,650.90
3,068.24
3,437.64
3,762.58
3,879.91
3,998.06
4,100.63
4,189.61
4,270.96
4,335.86
4,394.41
4,455.07
4,525.34
4,394.39
4,417.60
4,441.10
4,463.36
4,484.32
4,505.99
4,524.05
4,542.49
4,565.44
High
$0.00
94.91
291.65
811.11
1,422.05
2,481.38
3,664.44
4,320.00
4,543.36
4,772.57
4,979.46
5,166.34
5,555.21
5,926.26
6,251.90
6,535.69
6,787.01
6,993.56
7,178.33
7,356.56
7,547.30
7,377.52
7,449.02
7,512.74
7,572.40
7,625.42
7,679.31
7,730.18
7,778.42
7,830.37
TABLE VII–40—MONETIZED MY BENEFITS AT 7 PERCENT DISCOUNT
[2014 $ in millions]
Fatal equivalents
Year
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Low
1 ...................................
2 ...................................
3 ...................................
4 ...................................
5 ...................................
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
12 .................................
VerDate Sep<11>2014
Total monetized benefits
Model year
23:49 Jan 11, 2017
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
Jkt 241001
High
0.00
3.28
21.83
96.35
234.85
527.59
989.03
1,416.94
1,710.25
1,974.86
2,149.18
2,233.37
PO 00000
Frm 00145
Low
0.00
51.18
159.55
450.18
795.52
1,396.62
2,077.54
2,459.15
2,598.90
2,741.45
2,947.24
3,227.88
Fmt 4701
Sfmt 4702
High
$0.00
31.80
212.00
935.65
2,280.53
5,123.26
9,604.09
13,759.41
16,607.61
19,177.23
20,869.91
21,687.48
$0.00
497.03
1,549.29
4,371.50
7,725.00
13,562.13
20,174.30
23,879.93
25,236.98
26,621.24
28,619.59
31,344.84
E:\FR\FM\12JAP2.SGM
12JAP2
Property damage and
congestion
Low
$0.00
4.46
29.72
131.19
319.78
718.45
1,346.94
1,929.87
2,329.50
2,690.07
2,927.85
3,042.66
High
$0.00
71.59
223.15
629.59
1,112.43
1,952.75
2,904.40
3,437.45
3,632.38
3,831.23
4,119.15
4,510.89
3998
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–40—MONETIZED MY BENEFITS AT 7 PERCENT DISCOUNT—Continued
[2014 $ in millions]
Fatal equivalents
Year
Low
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
.................................
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
srobinson on DSK5SPTVN1PROD with PROPOSALS2
4. Non-Quantified Benefits
As discussed above, the agency has
only quantified potential benefits of this
rule derived from the assumed adoption
of IMA and LTA. Although this
assumption allows the agency to
provide a reasonable quantification of
the potential benefits of this rulemaking,
it does not account for many other
potential benefits of V2V. The nonquantified benefits of the proposed rule
can come from several sources: (1) The
effects of enhancing vehicle-resident
safety systems, (2) the incremental
benefits over the current vehicleresident safety systems, (3) the potential
impact of the next generation V2V apps
that would actively assist drivers to
avoid crashes rather than simply issuing
warnings, (4) the impact of enabling
wide range deployment of V2P and V2I
apps, and (5) the effects of adding V2V
sensor input to other sensors utilized for
automation. The agency does not
quantify the potential impacts of these
sources primarily due to lack of data
(e.g., effectiveness of the apps,
incremental effective rate of the V2V
apps over the vehicle-resident systems,
etc.) that can be used to discern these
benefits.
23:49 Jan 11, 2017
Jkt 241001
High
2,309.61
2,385.57
2,451.89
2,509.12
2,562.08
2,602.73
2,640.12
2,678.06
2,720.95
2,641.60
2,656.70
2,670.51
2,685.53
2,696.56
2,711.29
2,721.94
2,734.33
2,747.06
The agency seeks comment on all
aspects of the monetized benefits
developed for this proposal. More
specifically, the assumptions used for
the benefits calculations which are the
basis the estimates. Please provide any
supporting data for the comments. If
necessary, the agency has processes and
procedures for submitting confidential
business information.
VerDate Sep<11>2014
Total monetized benefits
Model year
Low
3,478.57
3,711.72
3,916.19
4,095.07
4,254.99
4,384.79
4,501.23
4,613.37
4,730.53
4,624.69
4,670.32
4,709.04
4,747.17
4,779.45
4,815.03
4,845.29
4,873.87
4,905.91
High
22,427.83
23,165.40
23,809.50
24,365.23
24,879.46
25,274.25
25,637.28
26,005.75
26,422.20
25,651.68
25,798.30
25,932.43
26,078.29
26,185.33
26,328.44
26,431.78
26,552.13
26,675.71
33,779.21
36,043.23
38,028.75
39,765.77
41,318.79
42,579.22
43,709.92
44,798.85
45,936.55
44,908.74
45,351.86
45,727.85
46,098.16
46,411.61
46,757.14
47,050.95
47,328.48
47,639.58
(a) The Effect for Enhancing VehicleResident Safety Systems
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 use a
V2V signal to 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.
The vehicle-resident FCW, LCM/BSW
systems can be improved by BSMs.
However, the agency could not quantify
the benefit due to lack of the
measurement of how BSM can improve
the vehicle-resident systems.
(b) Incremental Benefits of the V2V
Apps
Due to the sensing advantage of the
V2V apps, the agency believes that these
apps also have some incremental
benefits over the vehicle-resident
version of the systems. For example,
V2V-based FCW and LCM might
perform better than the vehicle-resident
systems. However, benefits from these
apps could accrue if they add a marginal
PO 00000
Frm 00146
Fmt 4701
Sfmt 4702
Property damage and
congestion
Low
3,146.63
3,250.21
3,340.68
3,418.75
3,490.99
3,546.47
3,597.49
3,649.27
3,707.77
3,599.70
3,620.32
3,639.18
3,659.68
3,674.73
3,694.84
3,709.36
3,726.26
3,743.62
High
4,860.73
5,186.03
5,471.24
5,720.68
5,943.64
6,124.52
6,286.75
6,442.98
6,606.25
6,458.14
6,521.61
6,575.46
6,628.54
6,673.47
6,723.04
6,765.20
6,805.02
6,849.69
effectiveness to the existing in-vehicle
systems, or if they enable the
installation of these apps in vehicles
that do not voluntarily have these
systems. This later effect would occur
due to the significant marginal cost
reduction for these apps that would
result from V2V. However, we do not
have sufficient data to determine the
marginal effectiveness of V2V for these
apps and the added installation rates.
Therefore, we did not quantify this type
of benefits.
(c) Potential Impact of Next Generation
V2V Apps
The agency believes that the V2V
apps will be evolved as did the vehicleresident systems. The next generation
V2V apps, we envision, can also
actively assist drivers to avoid crashes
as did the vehicle-resident crash
avoidance systems (such as advance
brake assist). Furthermore, the new apps
might be applicable to motorcycle
crashes. V2V could increase the
adoption of these apps to lower
incremental cost.
(d) The Impact of Enabling V2P and V2I
Apps
The V2V also is the foundation for the
deployment V2P and V2I apps. For V2P,
pedestrians can carry devices (such as
mobile phones) with a V2V chip that
can send out a safety signal to V2V
devices in the vehicles and vice versa.
Both the driver and the pedestrian could
be warned if a possible conflict arises.
Specifically, V2P can protect
pedestrians in crosswalk and improve
mobility. However, there are many
issues to be resolved concerning V2P
E:\FR\FM\12JAP2.SGM
12JAP2
3999
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
apps. The agency is developing a
research plan that will investigate issues
relating to V2P communication, safety
applications, and human factors, and
among other things.
The same communications technology
that supports V2V apps could also
enable a broader set of safety and
mobility applications when combined
with compatible roadway infrastructure.
The potential V2I apps have been
identified included: Red Light Violation
Warning, Curve Speed Warning, Stop
Sign Gap Assist, Reduced Speed Zone
Warning, Spot Weather Information
Warning, Stop Sign Violation Warning,
Railroad Crossing Violation Warning,
and Oversize Vehicle Warning.368 These
V2I apps can mitigate congestion and
facilitate green transportation choices,
thus reducing the energy consumptions
and environmental impacts.
(e) The Effects of Paving the Way for
Automation
We believe that V2X technology may
be necessary to realize the full potential
of vehicle automation (e.g., self-driving
vehicles), as such communication
would provide a vehicle with the
highest level of awareness of its
surroundings, which is likely necessary
in situations where the driver cedes all
control of safety-critical functions and
relies on the vehicle to monitor roadway
and driving conditions.
E. Breakeven Analysis
The agency conducted a breakeven
analysis of the proposed rule’s
estimated costs and benefits. The
analysis is used to determine when the
cumulative estimated benefits will
recoup the investment made up to that
year. In essence, this analysis
determines the year that the total
investment of the proposed rule will be
paid back through the total realized
benefits of the proposed rule. The total
investment of the proposed rule for a
year is the cumulative annual costs from
the first year of implementation up to
that year. Similarly, the total realized
benefits would be the cumulative
monetized annual benefits from the first
year of implementation up to that year.
All annual costs and monetized benefits
used in this analysis are discounted
back to 2021, the projected first year of
implementation of the proposed rule. In
determining the potential breakeven
point, the agency needed to develop the
undiscounted annual net benefits
yielding the values shown in Table VII–
41. As shown, undiscounted, the
proposed rule would accrue a positive
annual benefit around 2026 and 2027.
TABLE VII–41—ANNUAL NET BENEFITS
[Undiscounted, 2014$ in millions]
Total monetized benefits
Year
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Low
1 ...................................
2 ...................................
3 ...................................
4 ...................................
5 ...................................
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
12 .................................
13 .................................
14 .................................
15 .................................
16 .................................
17 .................................
18 .................................
19 .................................
20 .................................
21 .................................
22 .................................
23 .................................
24 .................................
25 .................................
26 .................................
27 .................................
28 .................................
29 .................................
30 .................................
31 .................................
32 .................................
33 .................................
34 .................................
35 .................................
36 .................................
37 .................................
38 .................................
39 .................................
40 .................................
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
368 The Connected Vehicle Core System
Architecture, See www.its.dot.gov/research/
VerDate Sep<11>2014
Annual costs
Annual net benefits
Calendar year
23:49 Jan 11, 2017
Jkt 241001
High
$0
19
126
495
1,256
2,655
4,784
7,381
10,245
13,336
16,595
19,960
23,369
26,770
30,098
33,279
36,263
39,002
41,438
43,570
45,392
46,898
48,152
49,192
50,045
50,768
51,403
51,963
52,466
52,911
53,279
53,603
53,869
54,096
54,285
54,445
54,561
54,624
54,665
54,685
Low
$0
25
165
647
1,644
3,483
6,295
9,741
13,554
17,678
22,041
26,553
31,136
35,718
40,212
44,518
48,567
52,292
55,616
58,537
61,042
63,122
64,860
66,304
67,490
68,494
69,374
70,147
70,840
71,453
71,960
72,408
72,777
73,092
73,356
73,578
73,741
73,832
73,894
73,926
High
$2,192
3,011
3,832
3,741
3,701
3,655
3,640
3,634
3,622
3,649
3,659
3,662
3,665
3,682
3,717
3,713
3,734
3,749
3,769
3,831
3,856
3,737
3,744
3,752
3,796
3,770
3,780
3,789
3,797
3,858
3,822
3,813
3,805
3,797
3,832
3,782
3,775
3,768
3,761
3,804
$2,864
3,926
4,946
4,981
4,803
4,735
4,705
4,690
4,668
4,692
4,699
4,699
4,699
4,719
4,757
4,731
4,726
4,736
4,858
4,844
4,872
4,715
4,719
4,723
4,764
4,736
4,745
4,752
4,759
4,818
4,761
4,732
4,719
4,810
4,766
4,711
4,700
4,688
4,677
4,717
systems_engineering.htm (last accessed Jan. 9,
2014).
PO 00000
Frm 00147
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
Low
¥$2,864
¥3,907
¥4,820
¥4,486
¥3,547
¥2,080
79
2,692
5,577
8,643
11,896
15,261
18,670
22,051
25,341
28,548
31,537
34,266
36,580
38,726
40,519
42,183
43,434
44,469
45,281
46,032
46,658
47,211
47,707
48,093
48,518
48,870
49,150
49,285
49,520
49,734
49,862
49,936
49,987
49,968
High
¥$2,192
¥2,986
¥3,668
¥3,095
¥2,057
¥173
2,655
6,106
9,931
14,029
18,381
22,891
27,471
32,036
36,495
40,805
44,833
48,543
51,847
54,706
57,186
59,385
61,116
62,552
63,695
64,724
65,594
66,359
67,043
67,595
68,138
68,594
68,972
69,295
69,523
69,795
69,966
70,064
70,133
70,122
4000
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
Table VII–42 and Table VII–43 show
the discounted cumulative annual
benefits, cumulative annual costs,
cumulative annual net benefits, and
breakeven year at a 3 and 7 percent rate,
respectively. As shown, the proposed
rule would be expected to break even
between 2029 and 2031 for a 3 percent
discount rate and 2030 to 2032 for a 7
percent discount rate.
TABLE VII–42—BREAKEVEN ANALYSIS
[at 3 Percent, 2014 $ in millions]
Year
Calendar
year
Cumulative
monetized benefits
Total cumulative
annual costs
Low
1 ...............
2 ...............
3 ...............
4 ...............
5 ...............
6 ...............
7 ...............
8 ...............
9 ...............
10 .............
11 .............
12 .............
13 .............
14 .............
15 .............
16 .............
17 .............
18 .............
19 .............
20 .............
21 .............
22 .............
23 .............
24 .............
25 .............
26 .............
27 .............
28 .............
29 .............
30 .............
31 .............
32 .............
33 .............
34 .............
35 .............
36 .............
37 .............
38 .............
39 .............
40 .............
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
High
Low
$0
18
135
581
1,681
3,938
7,886
13,800
21,769
31,840
44,007
58,215
74,365
92,328
111,934
132,980
155,245
178,494
202,478
226,960
251,726
276,568
301,328
325,889
350,146
374,038
397,524
420,574
443,171
465,294
486,919
508,044
528,654
548,751
568,332
587,399
605,949
623,981
641,501
658,513
$0
24
177
760
2,199
5,160
10,354
18,158
28,700
42,050
58,211
77,111
98,630
122,597
148,791
176,944
206,764
237,935
270,126
303,018
336,322
369,758
403,109
436,214
468,927
501,160
532,857
563,975
594,486
624,360
653,569
682,104
709,949
737,102
763,562
789,329
814,401
838,772
862,455
885,454
$2,160
5,040
8,600
11,973
15,213
18,320
21,324
24,236
27,053
29,809
32,492
35,099
37,632
40,102
42,524
44,872
47,165
49,400
51,581
53,734
55,837
57,817
59,742
61,616
63,455
65,229
66,956
68,637
70,273
71,886
73,437
74,940
76,396
77,806
79,189
80,513
81,797
83,040
84,246
85,429
Cumulative
net benefits
High
Low
$2,822
6,578
11,172
15,663
19,868
23,892
27,775
31,533
35,164
38,707
42,152
45,497
48,744
51,911
55,009
58,001
60,903
63,726
66,537
69,259
71,918
74,415
76,841
79,200
81,509
83,738
85,906
88,014
90,063
92,078
94,010
95,875
97,681
99,468
101,187
102,837
104,435
105,982
107,481
108,949
¥$2,822
¥6,559
¥11,036
¥15,081
¥18,186
¥19,954
¥19,889
¥17,732
¥13,395
¥6,867
1,855
12,718
25,621
40,417
56,925
74,979
94,342
114,768
135,941
157,701
179,808
202,153
224,486
246,690
268,637
290,300
311,618
332,561
353,108
373,216
392,909
412,169
430,974
449,283
467,145
484,562
501,515
517,999
534,020
549,565
High
¥$2,160
¥5,016
¥8,423
¥11,213
¥13,014
¥13,161
¥10,970
¥6,078
1,647
12,241
25,719
42,013
60,998
82,494
106,267
132,072
159,599
188,536
218,545
249,284
280,485
311,941
343,367
374,599
405,472
435,931
465,901
495,337
524,213
552,474
580,132
607,165
633,553
659,296
684,373
708,816
732,604
755,732
778,210
800,025
Breakeven
year
Low
(*)
(*)
(*)
(*)
(*)
(*)
(*)
(*)
(*)
(*)
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
High
(*)
(*)
(*)
(*)
(*)
(*)
(*)
(*)
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
* Not breakeven.
TABLE VII–43—BREAKEVEN ANALYSIS
[at 7 Percent, 2014 $ in Millions]
Year
Calendar
year
Cumulative monetized
benefits
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Low
1 ...............
2 ...............
3 ...............
4 ...............
5 ...............
6 ...............
7 ...............
8 ...............
9 ...............
10 .............
11 .............
12 .............
VerDate Sep<11>2014
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
23:49 Jan 11, 2017
$0
17
124
514
1,441
3,271
6,353
10,796
16,560
23,572
31,727
40,894
Jkt 241001
Total cumulative annual
costs
High
Low
$0
23
162
672
1,884
4,285
8,340
14,204
21,829
31,124
41,955
54,151
PO 00000
Frm 00148
$2,119
4,840
8,076
11,028
13,757
16,277
18,622
20,810
22,847
24,766
26,564
28,246
Fmt 4701
Cumulative net
benefits
High
Low
$2,768
6,316
10,492
14,423
17,965
21,228
24,260
27,083
29,709
32,176
34,485
36,643
Sfmt 4702
¥$2,768
¥6,299
¥10,369
¥13,909
¥16,524
¥17,958
¥17,907
¥16,287
¥13,149
¥8,604
¥2,759
4,251
E:\FR\FM\12JAP2.SGM
High
¥$2,119
¥4,817
¥7,914
¥10,356
¥11,873
¥11,992
¥10,282
¥6,606
¥1,018
6,358
15,391
25,905
12JAP2
Breakeven
year
Low
(*)
(*)
(*)
(*)
(*)
(*)
(*)
(*)
(*)
(*)
(*)
2032
High
(*)
(*)
(*)
(*)
(*)
(*)
(*)
(*)
(*)
2030
2031
2032
4001
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–43—BREAKEVEN ANALYSIS—Continued
[at 7 Percent, 2014 $ in Millions]
Calendar
year
Year
Cumulative monetized
benefits
Total cumulative annual
costs
Low
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
.............
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
High
Low
50,925
61,665
72,949
84,610
96,486
108,420
120,271
131,918
143,257
154,207
164,714
174,744
184,283
193,325
201,883
209,969
217,597
224,788
231,554
237,917
243,891
249,501
254,761
259,688
264,304
268,625
272,665
276,443
67,515
81,845
96,920
112,520
128,425
144,426
160,333
175,980
191,228
205,967
220,119
233,639
246,502
258,701
270,252
281,167
291,467
301,177
310,316
318,911
326,982
334,562
341,670
348,329
354,567
360,407
365,868
370,976
29,819
31,297
32,690
33,991
35,214
36,361
37,439
38,463
39,427
40,299
41,116
41,881
42,605
43,276
43,905
44,495
45,047
45,571
46,057
46,509
46,931
47,325
47,697
48,039
48,358
48,656
48,934
49,197
Cumulative net
benefits
High
Low
38,660
40,554
42,337
43,995
45,542
46,992
48,381
49,676
50,893
51,994
53,023
53,986
54,894
55,738
56,528
57,267
57,959
58,614
59,219
59,780
60,304
60,803
61,264
61,691
62,088
62,459
62,805
63,131
High
12,264
21,111
30,612
40,615
50,943
61,429
71,891
82,242
92,364
102,214
111,691
120,758
129,388
137,587
145,355
152,701
159,638
166,174
172,336
178,136
183,587
188,698
193,497
197,997
202,216
206,166
209,860
213,313
37,695
50,548
64,230
78,528
93,211
108,065
122,893
137,516
151,801
165,668
179,003
191,757
203,898
215,425
226,346
236,672
246,420
255,606
264,260
272,402
280,051
287,236
293,973
300,290
306,209
311,751
316,934
321,779
Breakeven
year
Low
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
High
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
* Not breakeven.
TABLE VII–44—SUMMARY OF THE
BREAKEVEN YEAR OF THE PROPOSED RULE
Discount rate
Year
At 3 Percent ...........................
At 7 Percent ...........................
2029 to 2031.
2030 to 2032.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
F. Cost Effectiveness and Positive Net
Benefits Analysis
1. Cost Effectiveness
The cost-effectiveness analysis
identifies the model year the agency
estimates the net cost per fatal
equivalent is no greater than the $9.7
million comprehensive cost of a fatality,
indicating the point at which cost of the
propose rule is lower than a fatal
369 The one-DSRC radio consists of one DSRC
radio in vehicle paring with a hybrid (WiFi/
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
equivalent. For this analysis, the agency
defines the net cost as the difference
between a given MY cost and the
congestion benefits and PDO savings
(i.e., the lifetime savings of these two
categories for a given vehicle MY).
For each discount rate, the range of
fatal equivalents covers those from the
two benefits estimating approaches
discussed previously Section VII.D:
Free-rider and no free-rider. The low
fatal equivalent numbers represent the
low benefit estimates from the free-rider
approach and the high estimates
represent the higher benefit estimates
from the no free-rider approach.
Additionally, the cost-related low and
high values represent the two potential
cost estimates that result from utilizing
a one-radio or two-radio approach to
DSRC implementation approach.369
The agency utilizes the net cost per
equivalent life saved to determine the
cost-effectiveness for a given vehicle
MY. The net cost defined in this
analysis is the difference between the
MY costs and the savings from reducing
property damage and congestion. As
described in Section VII.D.3, fatal
equivalents are derived by translating
the MAIS 1–5 injuries saved and the
PDOVs prevented into fatalities using
the calculated relative fatality ratios
found in Table VII–37.
Table VII–45 and Table VII–46
present the factors used when determine
cost-effectiveness, the net cost per fatal
equivalent discounted at 3 percent and
7 percent, respectively, and when the
agency estimates the proposed rule
would become cost-effective. As shown
in the tables, the agency estimates the
proposed rule would become cost
effective in MY 2024 to MY 2026
regardless of the discount rate. Note that
the negative MY net cost shown in the
tables means that the MY benefits
outweigh its costs.
Cellular/Satellite) vehicle-to-SCMS communication.
Table VII–44 summarizes the
breakeven year for the proposed rule
based on the estimated costs and
monetized benefits.
The two DSRC radios in vehicle are paring with
DSRC vehicle-to-SCMS communication.
PO 00000
Frm 00149
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
4002
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–45—COST-EFFECTIVENESS ANALYSIS
[at 3 Percent, 2014 $ in millions]
Year
Model
Fatal
equivalents
MY net
costs
Low
1 ...............
2 ...............
3 ...............
4 ...............
5 ...............
6 ...............
7 ...............
8 ...............
9 ...............
10 .............
11 .............
12 .............
13 .............
14 .............
15 .............
16 .............
17 .............
18 .............
19 .............
20 .............
21 .............
22 .............
23 .............
24 .............
25 .............
26 .............
27 .............
28 .............
29 .............
30 .............
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
High
Low
0.00
3.48
23.35
104.31
257.57
586.69
1,112.42
1,606.16
1,946.18
2,252.45
2,523.52
2,761.74
2,847.78
2,934.41
3,009.61
3,074.84
3,134.46
3,182.03
3,224.93
3,269.38
3,320.90
3,224.76
3,241.75
3,258.96
3,275.27
3,290.63
3,306.52
3,319.75
3,333.27
3,350.10
0.00
67.86
208.55
580.04
1,017.05
1,774.90
2,621.45
3,090.78
3,250.93
3,415.26
3,563.63
3,697.69
3,975.69
4,241.63
4,475.08
4,678.59
4,858.86
5,007.07
5,139.68
5,267.60
5,404.46
5,283.11
5,334.51
5,380.31
5,423.17
5,461.25
5,499.93
5,536.44
5,571.05
5,608.31
Net cost per fatal
equivalent
High
$2,221.39
2,958.11
3,592.36
2,975.53
2,317.96
1,208.85
7.03
¥657.77
¥896.40
¥1,101.36
¥1,301.00
¥1,487.91
¥1,876.58
¥2,233.79
¥2,526.26
¥2,816.23
¥3,048.91
¥3,242.04
¥3,409.01
¥3,527.55
¥3,692.67
¥3,646.00
¥3,711.27
¥3,768.41
¥3,785.48
¥3,865.08
¥3,909.53
¥3,952.52
¥3,992.64
¥3,984.67
Low
$2,893.52
3,963.34
4,965.74
4,884.16
4,491.28
3,970.64
3,221.61
2,530.40
2,042.34
1,645.84
1,280.31
952.38
833.11
731.05
664.36
547.13
459.30
402.76
463.44
387.12
345.44
315.00
294.44
274.41
292.50
242.56
228.66
216.58
204.60
240.58
$2,221.39
43.59
17.23
5.13
2.28
0.68
0.00
¥0.21
¥0.28
¥0.32
¥0.37
¥0.40
¥0.47
¥0.53
¥0.56
¥0.60
¥0.63
¥0.65
¥0.66
¥0.67
¥0.68
¥0.69
¥0.70
¥0.70
¥0.70
¥0.71
¥0.71
¥0.71
¥0.72
¥0.71
High
$2,893.52
1,138.99
212.68
46.82
17.44
6.77
2.90
1.58
1.05
0.73
0.51
0.34
0.29
0.25
0.22
0.18
0.15
0.13
0.14
0.12
0.10
0.10
0.09
0.08
0.09
0.07
0.07
0.07
0.06
0.07
Costeffective
Low
High
*
*
*
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
*
*
*
*
*
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
* The proposed rule would not be cost effective for the MY vehicles since the net cost per fatal equivalent is greater than $9.7M in 2014
dollars.
TABLE VII–46—COST-EFFECTIVENESS ANALYSIS
[at 7 Percent, 2014 $ in millions]
Year
Model year
Fatal
equivalents
MY net
costs
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Low
1 ...............
2 ...............
3 ...............
4 ...............
5 ...............
6 ...............
7 ...............
8 ...............
9 ...............
10 .............
11 .............
12 .............
13 .............
14 .............
15 .............
16 .............
17 .............
18 .............
19 .............
20 .............
21 .............
22 .............
23 .............
24 .............
25 .............
26 .............
VerDate Sep<11>2014
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
23:49 Jan 11, 2017
High
0.00
3.28
21.83
96.35
234.85
527.59
989.03
1,416.94
1,710.25
1,974.86
2,149.18
2,233.37
2,309.61
2,385.57
2,451.89
2,509.12
2,562.08
2,602.73
2,640.12
2,678.06
2,720.95
2,641.60
2,656.70
2,670.51
2,685.53
2,696.56
0.00
51.18
159.55
450.18
795.52
1,396.62
2,077.54
2,459.15
2,598.90
2,741.45
2,947.24
3,227.88
3,478.57
3,711.72
3,916.19
4,095.07
4,254.99
4,384.79
4,501.23
4,613.37
4,730.53
4,624.69
4,670.32
4,709.04
4,747.17
4,779.45
Jkt 241001
PO 00000
Low
$2,213.68
2,969.81
3,645.47
3,141.76
2,612.54
1,722.09
751.28
208.58
¥2.00
¥177.05
¥458.15
¥850.33
¥1,200.35
¥1,512.27
¥1,764.75
¥2,020.80
¥2,225.59
¥2,393.47
¥2,538.36
¥2,635.41
¥2,773.58
¥2,748.24
¥2,805.80
¥2,853.41
¥2,864.22
¥2,936.06
Frm 00150
Fmt 4701
Net cost per fatal
equivalent
High
Low
$2,885.80
3,952.00
4,952.42
4,879.71
4,507.19
4,035.73
3,373.91
2,771.96
2,347.17
2,006.97
1,772.63
1,654.44
1,548.14
1,460.19
1,405.16
1,298.41
1,219.23
1,171.68
1,239.43
1,171.48
1,141.05
1,088.07
1,069.77
1,054.05
1,073.57
1,029.21
Sfmt 4702
$2,213.68
58.02
22.85
6.98
3.28
1.23
0.36
0.08
0.00
¥0.06
¥0.16
¥0.26
¥0.35
¥0.41
¥0.45
¥0.49
¥0.52
¥0.55
¥0.56
¥0.57
¥0.59
¥0.59
¥0.60
¥0.61
¥0.60
¥0.61
E:\FR\FM\12JAP2.SGM
High
$2,885.80
1,206.56
226.83
50.64
19.19
7.65
3.41
1.96
1.37
1.02
0.82
0.74
0.67
0.61
0.57
0.52
0.48
0.45
0.47
0.44
0.42
0.41
0.40
0.39
0.40
0.38
12JAP2
Costeffective
Low
*
*
*
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
High
*
*
*
*
*
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
4003
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–46—COST-EFFECTIVENESS ANALYSIS—Continued
[at 7 Percent, 2014 $ in millions]
Year
Model year
Fatal
equivalents
MY net
costs
Low
27
28
29
30
.............
.............
.............
.............
2047
2048
2049
2050
High
Low
2,711.29
2,721.94
2,734.33
2,747.06
4,815.03
4,845.29
4,873.87
4,905.91
Net cost per fatal
equivalent
High
¥2,976.53
¥3,011.12
¥3,043.14
¥3,028.20
Low
High
¥0.62
¥0.62
¥0.62
¥0.62
1,016.55
1,007.69
996.93
1,038.18
Costeffective
Low
0.37
0.37
0.36
0.38
High
2047
2048
2049
2050
2047
2048
2049
2050
* The proposed rule would not be cost effective for the MY vehicles since the net cost per fatal equivalent is greater than $9.7M in 2014
dollars.
2. Lifetime Net Benefits for a Specified
Model Year
The lifetime net benefits for a
specified MY vehicle (i.e., MY net
benefits) is the difference between the
monetized MY benefits and the
corresponding MY costs. Table VII–47
and Table VII–48 show the MY net
benefits at a 3 and 7 percent discount
rate, respectively. As shown, for both
discount rates, MY 2024 to MY 2026
vehicles would accrue positive lifetime
net benefits. (Due to rounding errors,
discrepancy existed between the
monetized MY benefits that were
deriving directly by multiplying $9.7
million by fatal equivalents and those
reported in the tables below.)
TABLE VII–47—MY NET BENEFITS
[at 3 Percent, 2014 $ in millions]
Model
year
Year
1 ...................................
2 ...................................
3 ...................................
4 ...................................
5 ...................................
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
12 .................................
13 .................................
14 .................................
15 .................................
16 .................................
17 .................................
18 .................................
19 .................................
20 .................................
21 .................................
22 .................................
23 .................................
24 .................................
25 .................................
26 .................................
27 .................................
28 .................................
29 .................................
30 .................................
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
Monetized MY benefits
MY costs
MY net benefits
Low
High
Low
High
$0.00
33.79
226.72
1,012.92
2,501.20
5,697.12
10,802.30
15,596.91
18,898.69
21,872.79
24,505.02
26,818.31
27,653.77
28,495.06
29,225.26
29,858.67
30,437.71
30,899.56
31,316.16
31,747.87
32,248.10
31,314.49
31,479.52
31,646.62
31,805.05
31,954.16
32,108.44
32,236.99
32,368.22
32,531.65
$0.00
658.99
2,025.12
5,632.53
9,876.22
17,235.41
25,455.98
30,013.55
31,568.66
33,164.45
34,605.22
35,906.98
38,606.57
41,189.00
43,456.01
45,432.21
47,182.69
48,621.96
49,909.68
51,151.88
52,480.81
51,302.48
51,801.61
52,246.36
52,662.57
53,032.36
53,407.94
53,762.45
54,098.58
54,460.39
$2,221.39
3,053.02
3,884.01
3,786.63
3,740.01
3,690.23
3,671.47
3,662.23
3,646.96
3,671.21
3,678.46
3,678.43
3,678.63
3,692.47
3,725.64
3,719.46
3,738.10
3,751.52
3,769.32
3,829.01
3,854.63
3,731.52
3,737.75
3,744.33
3,786.93
3,760.35
3,769.78
3,777.66
3,785.78
3,845.70
$2,893.52
3,968.08
4,997.52
5,026.18
4,842.01
4,769.58
4,736.63
4,718.02
4,693.24
4,714.08
4,717.95
4,714.96
4,713.02
4,729.11
4,764.99
4,736.74
4,730.26
4,738.62
4,857.85
4,842.19
4,870.78
4,709.39
4,712.04
4,715.51
4,755.86
4,726.88
4,734.65
4,740.64
4,747.09
4,806.01
Low
¥$2,893.52
¥3,934.29
¥4,770.80
¥4,013.26
¥2,340.81
927.54
6,065.67
10,878.89
14,205.45
17,158.71
19,787.07
22,103.36
22,940.75
23,765.95
24,460.27
25,121.92
25,707.44
26,160.94
26,458.31
26,905.68
27,377.32
26,605.10
26,767.49
26,931.12
27,049.18
27,227.28
27,373.79
27,496.35
27,621.14
27,725.64
High
¥$2,221.39
¥2,394.03
¥1,858.89
1,845.90
6,136.21
13,545.18
21,784.52
26,351.32
27,921.70
29,493.24
30,926.76
32,228.55
34,927.94
37,496.53
39,730.37
41,712.75
43,444.60
44,870.43
46,140.36
47,322.87
48,626.18
47,570.96
48,063.86
48,502.03
48,875.65
49,272.01
49,638.16
49,984.79
50,312.80
50,614.69
TABLE VII–48 MY NET BENEFITS
srobinson on DSK5SPTVN1PROD with PROPOSALS2
[at 7 Percent, 2014 $ in millions]
Model
year
Year
1
2
3
4
5
...................................
...................................
...................................
...................................
...................................
VerDate Sep<11>2014
23:49 Jan 11, 2017
2021
2022
2023
2024
2025
Jkt 241001
Monetized MY benefits
Low
High
$0.00
31.80
212.00
935.65
2,280.53
PO 00000
Vehicle costs
Frm 00151
Low
$0.00
497.03
1,549.29
4,371.50
7,725.00
Fmt 4701
MY net benefits
Sfmt 4702
High
$2,213.68
3,041.41
3,868.62
3,771.35
3,724.97
$2,885.80
3,956.46
4,982.14
5,010.90
4,826.97
E:\FR\FM\12JAP2.SGM
12JAP2
Low
¥$2,885.80
¥3,924.66
¥4,770.14
¥4,075.25
¥2,546.44
High
¥$2,213.68
¥2,544.37
¥2,319.34
600.15
4,000.03
4004
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
TABLE VII–48 MY NET BENEFITS—Continued
[at 7 Percent, 2014 $ in millions]
Monetized MY benefits
Model
year
Year
6 ...................................
7 ...................................
8 ...................................
9 ...................................
10 .................................
11 .................................
12 .................................
13 .................................
14 .................................
15 .................................
16 .................................
17 .................................
18 .................................
19 .................................
20 .................................
21 .................................
22 .................................
23 .................................
24 .................................
25 .................................
26 .................................
27 .................................
28 .................................
29 .................................
30 .................................
Low
TABLE VII–49—SUMMARY OF THE MY
WOULD BE COST-EFFECTIVE AND
HAVE POSITIVE NET BENEFITS
At 3 Percent .....
At 7 Percent .....
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Cost-effective
2024 to 2026 ...
2024 to 2026 ...
Net benefits
2024 to 2026.
2024 to 2026.
G. Uncertainty Analysis
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. 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-
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
High
5,123.26
9,604.09
13,759.41
16,607.61
19,177.23
20,869.91
21,687.48
22,427.83
23,165.40
23,809.50
24,365.23
24,879.46
25,274.25
25,637.28
26,005.75
26,422.20
25,651.68
25,798.30
25,932.43
26,078.29
26,185.33
26,328.44
26,431.78
26,552.13
26,675.71
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
3. Summary
Table VII–49 summarizes the MY
vehicles that would be cost-effective.
Discount rate
Vehicle costs
Low
13,562.13
20,174.30
23,879.93
25,236.98
26,621.24
28,619.59
31,344.84
33,779.21
36,043.23
38,028.75
39,765.77
41,318.79
42,579.22
43,709.92
44,798.85
45,936.55
44,908.74
45,351.86
45,727.85
46,098.16
46,411.61
46,757.14
47,050.95
47,328.48
47,639.58
3,674.84
3,655.69
3,646.03
3,630.38
3,654.18
3,661.00
3,660.57
3,660.38
3,673.77
3,706.49
3,699.88
3,718.05
3,731.05
3,748.39
3,807.57
3,832.67
3,709.90
3,715.80
3,722.05
3,764.31
3,737.41
3,746.51
3,754.07
3,761.88
3,821.49
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.
H. Estimated Costs and Benefits of V2V
Alternatives
In the interest of ensuring the
agency’s proposed approach to
regulating V2V technology is both fully
informed and backed by a
comprehensive regulatory analysis, the
agency considered two potential
alternative approaches for V2V
deployment. The first alternative
(Alternative 1) explores the concept
going beyond this proposal’s mandate
for only the V2V communications
equipment (radio), by also including a
mandate for two safety warning
applications: Intersection movement
assist (IMA) and left turn across path
(LTA). Alternative 2 is an ‘‘if-equipped’’
approach that would provide
requirements for V2V communication as
specified in this proposed rule but only
applicable if the equipment is used in
the vehicle fleet. These two alternatives
represent a significant range of potential
PO 00000
Frm 00152
Fmt 4701
Sfmt 4702
MY net benefits
High
4,754.19
4,720.85
4,701.83
4,676.66
4,697.04
4,700.48
4,697.09
4,694.77
4,710.41
4,745.84
4,717.16
4,710.22
4,718.15
4,836.91
4,820.75
4,848.82
4,687.77
4,690.09
4,693.23
4,733.25
4,703.94
4,711.38
4,717.05
4,723.19
4,781.80
Low
High
369.08
4,883.24
9,057.59
11,930.95
14,480.18
16,169.42
16,990.38
17,733.06
18,455.00
19,063.67
19,648.07
20,169.24
20,556.11
20,800.36
21,185.00
21,573.37
20,963.91
21,108.20
21,239.19
21,345.04
21,481.39
21,617.06
21,714.73
21,828.94
21,893.91
9,887.29
16,518.61
20,233.89
21,606.59
22,967.06
24,958.59
27,684.27
30,118.83
32,369.46
34,322.26
36,065.89
37,600.74
38,848.18
39,961.54
40,991.28
42,103.88
41,198.84
41,636.06
42,005.80
42,333.85
42,674.20
43,010.63
43,296.87
43,566.60
43,818.10
agency actions beyond the baseline and
the proposal.
Alternative 1 shares the same threeyear phase-in schedule (50%–75%–
100%) for V2V equipment as the
proposed rule but delays the same phase
in rate by one year delay for safety
application implementation (0%–50%–
75%–100%). Alternative 2 370 assumes
that a V2V implementation would be
both slower and most likely stay flat
thereafter versus the mandatory
implementation of the proposed rule,
never reaching all or even a significant
percentage of the fleet. The agency
believes this results from the cost of
installing V2V on any particular vehicle
is not dependent on adoption by others,
while the benefits are. With these
considerations, the agency assumes that
a 5 percent DSRC adoption for MY 2021
vehicles and a 5 percent increase for the
subsequent years until plateauing at 25
percent in MY 2025 and indefinitely
This assumption is broadly based upon
adoption rates of other advanced
technologies in the absence of a
mandate. Alternative 2 has the same
safety application implementation
schedule as the proposed rule as
implementation would be voluntary for
both regulatory options. Table VII–50
370 The agency believes that V2V would not occur
in the absence of any government action and has,
therefore, not estimated a ‘‘no action’’ alternative.
We request comment on this assumption.
E:\FR\FM\12JAP2.SGM
12JAP2
4005
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
and Table VII–51 summarize the DSRC
and safety application adoptions rates
for the proposed rule and these two
alternatives.
TABLE VII–50—DSRC ADOPTION RATES IN PERCENT
Model year
Regulation alternatives
2021
The Proposed Rule Mandating DSRC ................
Alternative 1 Mandating
DSRC and Apps ...........
Alternative 2 If-Equipped
2022
2023
2024
2025
2026
2027
2028+
50
75
100
100
100
100
100
100
50
5
75
10
100
15
100
20
100
25
100
25
100
25
100
25
TABLE VII–51—APP ADOPTION RATES * IN PERCENT
[of DSRC-equipped vehicles]
Model year
Regulation alternatives
2021
The Proposed Rule Mandating DSRC ................
Alternative 1 Mandating
DSRC and Apps ...........
Alternative 2 If-Equipped
2022
2023
2024
2025
2026
2027
2028+
0
5
10
25
40
65
90
100
50
0
75
5
100
10
100
15
100
20
100
25
100
25
100
25
Because of the aggressive app
adoption, Alternative 1 would be
expected to accrue more annual benefits
than the proposed rule before the entire
on-road fleet has been equipped with
V2V (i.e., reaching the maximum
benefits). Alternative 1 would also reach
the same maximum annual benefits as
the proposed rule, but would do so four
years earlier. This alternative would
achieve these benefits without
significant cost increase, since the
incremental cost of adding two apps
over the DSRC radios is very small (less
than 0.1 percent of the vehicle
technology cost). The annual costs of
this alternative would range from $2.2
to $5.0 billion.
Alternative 2 would accrue up to 6
percent of the maximum annual benefits
of the proposed rule due to lower DSRC
and app adoption rates. This alternative
also has relatively lower annual costs
than that of the proposed rule, since far
fewer vehicles would be installed with
DSRC. The annual cost of this
alternative would range from $254
million to $1.3 billion, with an average
annual cost about 26 percent of the cost
of the proposed rule.
Alternative 1 would breakeven
between 2027 and 2030 (combining 3
and 7 percent discount rates), two years
ahead of the proposed rule. The first MY
vehicles that would be cost-effective
and that would accrue positive net
benefits is expected to be between MY
2024 and MY 2026, also two years
earlier than the proposed rule. In
contrast, Alternative 2 would breakeven
between 2037 and 2055, eight to twentythree years behind the proposed rule.
The first MY vehicles that would be
cost-effective under Alternative 2 is
expected to be between MY 2026 and
MY 2031, two to five years later than the
proposed rule. The first MY vehicles
that would accrue positive net benefits
is between MY 2026 and MY 2033, two
to seven years later than the proposed
rule. Table VII–52 and Table VII–53
compares these visually at three and
seven percent discount rates.
TABLE VII–52—COMPARISON OF BREAKEVEN AND COST-EFFECTIVE MEASURES—3 PERCENT DISCOUNT
Cost-benefit measures
(3 percent discount)
Alternative 1
mandating
DSRC radios
and apps
The proposed
rule mandating
DSRC only
Breakeven (CY) ..................................................................................................................
Cost-Effectiveness (MY) .....................................................................................................
Positive Net Benefits (MY) .................................................................................................
2027 to 2029 ....
2022 to 2024 ....
2022 to 2024 ....
2029 to 2031 ....
2024 to 2026 ....
2024 to 2026 ....
Alternative 2
if-equipped
2037 to 2045.
2026 to 2030.
2026 to 2031.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
TABLE VII–53—COMPARISON OF BREAKEVEN AND COST-EFFECTIVE MEASURES—7 PERCENT DISCOUNT
Cost-benefit measures
(7 percent discount)
Alternative 1
mandating
DSRC radios
and apps
The proposed
rule mandating
DSRC only
Breakeven (CY) ..................................................................................................................
Cost-Effectiveness (MY) .....................................................................................................
Positive Net Benefits (MY) .................................................................................................
2027 to 2030 ....
2022 to 2024 ....
2022 to 2024 ....
2030 to 2032 ....
2024 to 2026 ....
2024 to 2026 ....
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00153
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
Alternative 2
if-equipped
2039 to 2055.
2027 to 2031.
2027 to 2033.
4006
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
Although mandating safety
applications like IMA and LTA along
with the V2V communication capability
(i.e., DSRC) would result in significant
safety benefits sooner, the agency is not
proposing to mandate these applications
as part of this proposal, because the
agency currently does not have
sufficient data to proceed with a
mandate at this time. As explained
above, further research for establishing
practicable and objective test
procedures and performance
requirements for the applications will
likely need to be conducted prior to
mandate to avoid potential unintended
consequences which could have broader
negative effects, such as false warnings
causing consumers to dismiss the
technology, on the development and
deployment of V2V-based applications.
Additional details on the analysis of
Alternative 1 and Alternative 2 can be
found in the PRIA accompanying this
proposal rule.
We request comment on the
alternative cost and benefits analysis
including the approach for the
alternative? Do commenters agree with
the costs assumptions used for
developing and implementing safety
applications? Why or why not? Please
provide supporting data. Do
commenters agree with our assessment
that mandating applications would
result in accruing benefits sooner? Do
commenters have estimates for the
potential costs that an earlier mandate
(like, consumer rejection of tech,
opportunity cost, etc.) that are not
quantified or are not quantifiable but
hold great importance? Do commenters
have any information that could assist
the agency in learning more about these
and any other applications that may be
useful in a potential agency decision to
mandate V2V-enabled safety
applications.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
VIII. Proposed Implementation Timing
This section of the NPRM describes
the proposed timing for implementing
the requirements for new vehicles and
aftermarket devices, and also describes
our expectations of the availability of
the national SCMS.
A. New Vehicles
The agency proposes the following
lead time and phase-in period for all
new light vehicles sold in the U.S. to
comply with this proposed rule.
1. Lead Time
We are proposing two years of lead
time, with the two years starting on
Sept. 1 following issuance of a final rule
to this proposal. This approach would
allow a minimum of two full calendars
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
of lead time. New light vehicles
manufactured for sale in the U.S. would
not be required to comply until that
time. NHTSA believes that a lead time
period is necessary to allow for the
development and production of
automotive-grade V2V communications
devices by the automotive supplier
industry. While a quantity of DSRC
devices were developed for the Safety
Pilot Model Deployment in Ann Arbor,
MI, these were mostly prototype
aftermarket devices that were not
designed to directly integrate into the
vehicle’s controller area network.
Furthermore, the expected lifespan of
these devices is only 3 to 5 years instead
of the lifespan of a typical vehicle.
Those devices, or ones based on their
design, would therefore not be
appropriate for meeting this proposed
standard. At the time of issuance of this
NPRM, we have limited information
regarding the capability of automotive
suppliers to produce the quantities of
DSRC devices to equip all new light
vehicles sold in the U.S. annually
(approximately 15 million 371).
However, the agency was able to
confirm, confidentially, with at least
one supplier while gathering
information for this proposal that
request for quotations were being issued
by original equipment manufacturers for
V2V capable devices. In addition, the
ITSA market study commissioned by
the agency indicated the industry would
need approximately 18 months to two
years to ‘‘ramp-up’ V2V devices for
mass production, considering the device
itself and the perceived integration as
original equipment are less complex
than other technologies such as ESC or
powertrain components.
Depending on when the final rule
establishing DSRC FMVSS is issued, the
agency concurs with the ITSA market
study and its own regulatory experience
that automotive suppliers with need
some lead time to generate productionlevel devices in the quantities that
would be required annually by
automotive OEMs.
Lead time also allows the automotive
OEMs time to integrate V2V
communications devices into their
product lines, as these devices are not
currently part of any production
vehicles sold in the U.S. This will
minimize costs by allowing OEMs to
incorporate the new technology into
product cycle planning. Many OEMs
conduct ‘‘refreshes’’ (i.e. minor cosmetic
changes, new features, quality fixes,
etc.) on their product lines in a
371 See the 2015 EIA Annual Energy Outlook,
available at https://www.eia.gov/forecasts/aeo/
tables_ref.cfm.
PO 00000
Frm 00154
Fmt 4701
Sfmt 4702
staggered fashion approximately three to
four years after a major redesign.
For these reasons, the agency is
proposing a two year lead time after
issuance of the final rule before
manufacturers are required to begin
complying with the requirements. Two
years was chosen because it is
approximately half the amount of time
between average vehicle refreshes,
allowing OEMs to integrate V2V
technology into their existing product
cycles. This will minimize the cost
burden on the OEMs by not requiring
concurrent redesigns of all production
lines at the same time. We seek
comment on whether this amount of
lead time is necessary and appropriate.
If commenters believe that additional
lead time is needed, or that less lead
time is needed, we ask that they support
their comments as best as possible with
specific information as to why.
2. Phase-In Period
While the agency understands that
design changes may be required in order
to integrate V2V communications
devices into all light vehicles, since V2V
technology is a cooperative system, the
potential benefits associated with V2V
devices depend on a high penetration
rate of equipped vehicles. As such, the
agency proposes an aggressive phase-in
schedule after the conclusion of the lead
time period. In addition to the proposed
two years of lead time, NHTSA proposes
a three year phase-in period. The three
year phase-in schedule, which starts
immediately after the conclusion of the
lead time, would be as follows:
• End of Year 1—50% of all new light
vehicles must comply with the rule
• End of Year 2—75% of all new light
vehicles must comply with the rule
• End of Year 3—100% of all new light
vehicles must comply with the rule
This proposed schedule allows a total
of five years until all new vehicles
would be required to comply with the
final rule. This is consistent with a
DOT-sponsored market study 372
conducted by ITS America, in which
interviews were conducted with a wide
range of V2V stakeholders including:
• Automotive OEMs
• Tier 1 Suppliers
• Tier 2 Suppliers
• Automotive Insurance Companies
• Component Manufacturers
• System Integrators and Service
Providers
372 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 https://ntl.bts.gov/lib/60000/
60500/60535/FHWA-JPO-17-487_Final_.pdf. (last
accessed Dec 12, 2016).
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
• Roadside Infrastructure Operators and
Manufacturers
The consensus from that research was
that OEMs and suppliers will need
approximately three to five years after
the final rule in order for all new
vehicles to comply with the
regulation.373 Therefore, the agency
believes that this comprehensive input
from the industry provides a sufficient
justification for the lead time and phasein period. See Table VIII–1 for the full
schedule.
Finally, depending on the number of
product lines and the timing of their
redesigns, it may be economically
advantageous for some OEMs to comply
with the regulation prior to the
proposed schedule. These OEMs will be
able to capitalize on arriving to market
earlier than their competitors, and the
customers of these OEMs will realize
safety, mobility, and environmental
benefits earlier than others. As such, the
agency does not envision granting
credits for early compliance with this
schedule as there are sufficient
incentives already in place for OEMs to
consider early compliance.
TABLE VIII–1—PROPOSED LEAD TIME
AND PHASE-IN SCHEDULE
Time period
srobinson on DSK5SPTVN1PROD with PROPOSALS2
1
2
3
4
5
Percentage of
vehicles
year after final rule ............
years after final rule ..........
years after final rule ..........
years after final rule ..........
years after final rule ..........
0
0
50
75
100
B. Aftermarket
Based on market study research,374
the agency believes that the aftermarket
device industry will move quickly
(within one year) after the issuance of
the final rule to develop and market
V2V communications devices that
support safety applications as well as
mobility, environmental, and other
applications. While these aftermarket
devices will support V2V, they will also
enable more fee-based services such as
mobility applications and data and
communications suites to be marketed
to device owners. While safety is
important to consumers, the other
applications offered by these devices
may be potentially more attractive to the
consumer. The agency believes that
373 Vehicle to Vehicle Crash Avoidance Safety
Technology Public Acceptance Final Report—
FHWA–JPO–17–491 See Docket No. NHTSA–2016–
0126.
374 ‘‘Impact of Light Vehicle Rule on Consumer/
Aftermarket Adoption—Dedicated Short Range
Communications Market Study’’, ITS America
Research, 2015, pp 21.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
there will be a market for these
aftermarket devices; however, it will be
driven by the totality of features offered
by these devices that directly impact the
consumers’ time spent in their vehicles,
as well as by device cost.
The agency believes aftermarket
device suppliers would need to react to
a newly issued FMVSS to capitalize on
the large volume of light vehicles that
will not be equipped with V2V
communications devices. The prevailing
view is the market for such aftermarket
devices will exist only during the
transition period between the issuance
of the final rule and the turnover of the
entire fleet. NHTSA typically assumes
that the maximum life span of a light
vehicle is 39 years. We would anticipate
that the vast majority of the light vehicle
fleet in the U.S. will be completely
replaced in less than 20 years, and they
will be capable of V2V communications.
This gives the aftermarket device
industry a relatively small window of
time to sell aftermarket devices to light
vehicles without V2V communications
capabilities installed by the OEMs.
Additionally, based on research from
the Safety Pilot Model Deployment and
additional market research, we believe
the aftermarket industry is capable of
producing V2V communications devices
that can meet the proposed performance
requirements and could be installed by
a qualified installer, if needed. These
aftermarket devices do not need to be
connected to the vehicle controller area
network vehicle bus; however, an
external GPS and V2V antenna will
need to be installed as well as a
connection to the in-vehicle power.
Therefore, the agency expects that
specially-trained installers should be
able to install these devices in a similar
manner to other devices such OnStar
FMV, which is installed at major
electronics retailers as well as at car
dealerships. Therefore, these devices
could deploy faster than OEM integrated
as they do not require an OEM to
integrate them into their vehicle build
and testing processes. For these reasons,
the agency believes it is technically
possible that these devices could be
available on the market within one to
two years after this proposed FMVSS is
finalized.
Based on this, the agency anticipates
that aftermarket devices will be
available for purchase and installation
during the lead time period and prior to
the start of the first year of the phasein period (i.e. less than two years after
the final rule is issued).
The agency seeks comment on these
lead time projections for both OEM and
aftermarket devices. Specifically, do
commenters believe the proposed lead
PO 00000
Frm 00155
Fmt 4701
Sfmt 4702
4007
times are reasonable? If so, why? If not,
why? What type of adjustments, if any,
should agency make? Do commenters
agree with the agency’s perspective on
a ‘‘window of opportunity’’ for
aftermarket devices? If so, why? If not,
why? Please provide any supporting
data for your response.
IX. Public Participation
A. How do I prepare and submit
comments?
Your comments must be written and
in English. To ensure that your
comments are correctly filed in the
Docket, please include the Docket
Number NHTSA–2016–0126 in your
comments. Your comments must not be
more than 15 pages long.375 NHTSA
established this limit to encourage you
to write your primary comments in a
concise fashion. However, you may
attach necessary additional documents
to your comments, and there is no limit
on the length of the attachments. If you
are submitting comments electronically
as a PDF (Adobe) file, we ask that you
scan the documents submitted using the
Optical Character Recognition (OCR)
process,376 thus allowing the agency to
search and copy certain portions of your
submissions in order to better evaluate
them. Please note that pursuant to the
Data Quality Act, in order for the
substantive data to be relied upon and
used by the agency, it must meet the
information quality standards set forth
in the OMB and Department of
Transportation (DOT) Information
Dissemination Quality guidelines.
Accordingly, we encourage you to
consult the guidelines in preparing your
comments. OMB’s guidelines may be
accessed at https://
www.whitehouse.gov/omb/
fedreg_reproducible (last accessed Dec.
7, 2016). DOT’s guidelines may be
accessed at https://www.dot.gov/
regulations/dot-informationdissemination-quality-guidelines (last
accessed Dec. 7, 2016).
B. Tips for Preparing Your Comments
When submitting comments, please
remember to:
• Identify the rulemaking by docket
number and other identifying
information (subject heading, Federal
Register date and page number).
• Explain why you agree or disagree,
suggest alternatives, and substitute
language for your requested changes.
375 See
49 CFR 553.21.
character recognition (OCR) is the
process of converting an image of text, such as a
scanned paper document or electronic fax file, into
computer-editable text.
376 Optical
E:\FR\FM\12JAP2.SGM
12JAP2
4008
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
• Describe any assumptions and
provide any technical information and/
or data that you used.
• If you estimate potential costs or
burdens, explain how you arrived at
your estimate in sufficient detail to
allow for it to be reproduced.
• Provide specific examples to
illustrate your concerns, and suggest
alternatives.
• Explain your views as clearly as
possible, avoiding the use of profanity
or personal threats.
• Make sure to submit your
comments by the comment period
deadline identified in the DATES section
above.
C. How can I be sure that my comments
were received?
If you submit your comments by mail
and wish Docket Management to notify
you upon its receipt of your comments,
enclose a self-addressed, stamped
postcard in the envelope containing
your comments. Upon receiving your
comments, Docket Management will
return the postcard by mail.
If you submit your comments through
www.regulations.gov, you can find very
useful information about how to
confirm that your comments were
successfully received and uploaded
under the ‘‘Help’’ link on the top right
of the home page, under ‘‘FAQs.’’
srobinson on DSK5SPTVN1PROD with PROPOSALS2
D. How do I submit confidential
business information?
If you wish to submit any information
under a claim of confidentiality, you
should submit three copies of your
complete submission, including the
information you claim to be confidential
business information, to the Chief
Counsel, NHTSA, at the address given
above under FOR FURTHER INFORMATION
CONTACT. When you send a comment
containing confidential business
information, you should include a cover
letter setting forth the information
specified in our confidential business
information regulation.377
In addition, you should submit a copy
from which you have deleted the
claimed confidential business
information to the Docket by one of the
methods set forth above.
E. Will NHTSA consider late comments?
NHTSA will consider all comments
received before midnight E.S.T. on the
comment closing date indicated above
under DATES. To the extent practicable,
we will also consider comments
received after that date. Additionally, if
interested persons believe that any
information that NHTSA may place in
377 See
49 CFR part 512.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
the docket after the issuance of the
NPRM affects their comments, they may
submit comments after the closing date
concerning how NHTSA should
consider that information for the final
rule. If a comment is received too late
for us to practicably consider in
developing a final rule, we will consider
that comment as an informal suggestion
for future rulemaking action.
F. How can I read the comments
submitted by other people?
You may read the materials placed in
the docket for this document (e.g., the
comments submitted in response to this
document by other interested persons)
at any time by going to https://
www.regulations.gov. Follow the online
instructions for accessing the docket.
You may also read the materials at the
DOT Docket Management Facility by
going to the street address given above
under ADDRESSES.
X. Regulatory Notices and Analyses
A. Executive Order 12866, Executive
Order 13563, and DOT Regulatory
Policies and Procedures
Executive Order 12866, ‘‘Regulatory
Planning and Review’’ (58 FR 51735,
Oct. 4, 1993), as amended by Executive
Order 13563, ‘‘Improving Regulation
and Regulatory Review’’ (76 FR 3821,
Jan. 21, 2011), provides for making
determinations whether a regulatory
action is ‘‘significant’’ and therefore
subject to OMB review and to the
requirements of the Executive Order.
The Order defines a ‘‘significant
regulatory action’’ as one that is likely
to result in a rule that may:
• Have an annual effect on the
economy of $100 million or more or
adversely affect in a material way the
economy, a sector of the economy,
productivity, competition, jobs, the
environment, public health or safety, or
State, local, or Tribal governments or
communities;
• Create a serious inconsistency or
otherwise interfere with an action taken
or planned by another agency;
• Materially alter the budgetary
impact of entitlements, grants, user fees,
or loan programs or the rights and
obligations of recipients thereof; or
• Raise novel legal or policy issues
arising out of legal mandates, the
President’s priorities, or the principles
set forth in the Executive Order.
The rulemaking proposed in this
NPRM will be economically significant
if adopted. Accordingly, OMB reviewed
it under Executive Order 12866. The
rule, if adopted, would also be
significant within the meaning of the
PO 00000
Frm 00156
Fmt 4701
Sfmt 4702
Department of Transportation’s
Regulatory Policies and Procedures.378
The benefits and costs of this proposal
are described above in Section VII of
this preamble. Because the proposed
rule would, if adopted, be economically
significant under both the Department
of Transportation’s procedures and
OMB guidelines, the agency has
prepared a Preliminary Regulatory
Impact Analysis (PRIA) and placed it in
the docket and on the agency’s Web site.
Further, pursuant to Circular A–4, we
have prepared a formal probabilistic
uncertainty analysis for this proposal.379
The circular requires such an analysis
for complex rules where there are large,
multiple uncertainties whose analysis
raises technical challenges or where
effects cascade and where the impacts of
the rule exceed $1 billion. This proposal
meets these criteria on all counts.
B. Regulatory Flexibility Act
Pursuant to the Regulatory Flexibility
Act (5 U.S.C. 601 et seq.), as amended
by the Small Business Regulatory
Enforcement Fairness Act (SBREFA) of
1996, whenever an agency is required to
publish a notice of rulemaking for any
proposed or final rule, it must prepare
and make available for public comment
a regulatory flexibility analysis that
describes the effect of the rule on small
entities (i.e., small businesses, small
organizations, and small governmental
jurisdictions). The Small Business
Administration’s regulations at 13 CFR
part 121 define a small business, in part,
as a business entity ‘‘which operates
primarily within the United States.’’ (13
CFR 121.105(a)). No regulatory
flexibility analysis is required if the
head of an agency certifies the rule will
not have a significant economic impact
on a substantial number of small
entities. SBREFA amended the
Regulatory Flexibility Act to require
Federal agencies to provide a statement
of the factual basis for certifying that a
rule will not have a significant
economic impact on a substantial
number of small entities.
NHTSA has considered the effects of
this proposed rule under the Regulatory
Flexibility Act. I certify that this
proposed rule will not have a significant
economic impact on a substantial
number of small entities. The following
is NHTSA’s statement providing the
378 DOT Order 2100.5, ‘‘Regulatory Policies and
Procedures,’’ available at https://www.dot.gov/
regulations/rulemaking-requirements (last accessed
Mar. 16, 2015).
379 See Chapter 12 of the PRIA accompanying this
NPRM.
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
factual basis for the certification (5
U.S.C. 605(b)).380
If adopted, the proposal would
directly affect twenty large single stage
motor vehicle manufacturers.381 None of
these would qualify as a small business,
however. Based on our preliminary
assessment, the proposal would also
affect 3 entities that fit the Small
Business Administration’s criteria for a
small business (Panoz, Saleen, and
Shelby). According to the Small
Business Administration’s small
business size standards (see 13 CFR
121.201), a single stage automobile or
light truck manufacturer (NAICS code
336111, Automobile Manufacturing;
336112, Light Truck and Utility Vehicle
Manufacturing) must have 1,000 or
fewer employees to qualify as a small
business. We believe that the
rulemaking would not have a significant
economic impact on these small vehicle
manufacturers because we believe that
the market for the products of these
several small manufacturers is highly
inelastic, and purchasers of these
products are enticed by the desire to
have an unusual vehicle. Additionally,
all vehicle models would incur a similar
cost to meet the proposed standard, so
raising the price to include the value of
V2V technology should not have much,
if any, effect on sales of these vehicles,
and costs should be able to be passed on
to consumers. Based on this analysis,
we do not believe that the proposed rule
would have a significant economic
impact on these three small domestic
vehicle manufacturers. Therefore, a
regulatory flexibility analysis was not
prepared, but we welcome comments on
this issue for the final rule.
C. Executive Order 13132 (Federalism)
NHTSA has examined today’s
proposal pursuant to Executive Order
13132 (64 FR 43255, August 10, 1999)
and concluded that no additional
consultation with States, local
governments or their representatives is
mandated beyond the rulemaking
process. The agency has concluded that
the rulemaking will not have sufficient
federalism implications to warrant
consultation with State and local
officials or the preparation of a
federalism summary impact statement.
The proposal will not have ‘‘substantial
direct effects on the States, on the
380 See also Chapter 13 of the PRIA accompanying
this NPRM.
381 BMW, Daimler (Mercedes), Fiat/Chrysler
(which also includes Ferrari and Maserati), Ford,
Geely (Volvo), General Motors, Honda (which
includes Acura), Hyundai, Kia, Lotus, Mazda,
Mitsubishi, Nissan (which includes Infiniti),
Porsche, Subaru, Suzuki, Tata (Jaguar Land Rover),
Toyota, and Volkswagen/Audi.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
relationship between the national
government and the States, or on the
distribution of power and
responsibilities among the various
levels of government.’’
NHTSA rules can preempt in two
ways. First, the National Traffic and
Motor Vehicle Safety Act contains an
express preemption provision: When a
motor vehicle safety standard is in effect
under this chapter, a State or a political
subdivision of a State may prescribe or
continue in effect a standard applicable
to the same aspect of performance of a
motor vehicle or motor vehicle
equipment only if the standard is
identical to the standard prescribed
under this chapter. 49 U.S.C.
30103(b)(1). It is this statutory command
by Congress that preempts any nonidentical State legislative and
administrative law addressing the same
aspect of performance.
The express preemption provision
described above is subject to a savings
clause under which ‘‘[c]ompliance with
a motor vehicle safety standard
prescribed under this chapter does not
exempt a person from liability at
common law.’’ 49 U.S.C. 30103(e).
Pursuant to this provision, State
common law tort causes of action
against motor vehicle manufacturers
that might otherwise be preempted by
the express preemption provision are
generally preserved. However, the
Supreme Court has recognized the
possibility, in some instances, of
implied preemption of such State
common law tort causes of action by
virtue of NHTSA’s rules, even if not
expressly preempted. This second way
that NHTSA rules can preempt is
dependent upon there being an actual
conflict between an FMVSS and the
higher standard that would effectively
be imposed on motor vehicle
manufacturers if someone obtained a
State common law tort judgment against
the manufacturer, notwithstanding the
manufacturer’s compliance with the
NHTSA standard. Because most NHTSA
standards established by an FMVSS are
minimum standards, a State common
law tort cause of action that seeks to
impose a higher standard on motor
vehicle manufacturers will generally not
be preempted. However, if and when
such a conflict does exist—for example,
when the standard at issue is both a
minimum and a maximum standard—
the State common law tort cause of
action is impliedly preempted. See
Geier v. American Honda Motor Co.,
529 U.S. 861 (2000).
Pursuant to Executive Order 13132
and 12988, NHTSA has considered
whether this proposal could or should
preempt State common law causes of
PO 00000
Frm 00157
Fmt 4701
Sfmt 4702
4009
action. The agency’s ability to announce
its conclusion regarding the preemptive
effect of one of its rules reduces the
likelihood that preemption will be an
issue in any subsequent tort litigation.
To this end, the agency has examined
the nature (e.g., the language and
structure of the regulatory text) and
objectives of today’s proposal and finds
that this proposal, like many NHTSA
rules, would prescribe only a minimum
safety standard. As such, NHTSA does
not intend that this proposal preempt
state tort law that would effectively
impose a higher standard on motor
vehicle manufacturers than that to be
established by today’s proposal.
Establishment of a higher standard by
means of State tort law would not
conflict with the minimum standard
announced here. Without any conflict,
there could not be any implied
preemption of a State common law tort
cause of action.
D. Executive Order 12988 (Civil Justice
Reform)
With respect to the review of the
promulgation of a new regulation,
section 3(b) of Executive Order 12988,
‘‘Civil Justice Reform’’ (61 FR 4729; Feb.
7, 1996), requires that Executive
agencies make every reasonable effort to
ensure that the regulation: (1) Clearly
specifies the preemptive effect; (2)
clearly specifies the effect on existing
Federal law or regulation; (3) provides
a clear legal standard for affected
conduct, while promoting simplification
and burden reduction; (4) clearly
specifies the retroactive effect, if any; (5)
specifies whether administrative
proceedings are to be required before
parties file suit in court; (6) adequately
defines key terms; and (7) addresses
other important issues affecting clarity
and general draftsmanship under any
guidelines issued by the Attorney
General. This document is consistent
with that requirement.
Pursuant to this Order, NHTSA notes
as follows. The issue of preemption is
discussed above. NHTSA notes further
that there is no requirement that
individuals submit a petition for
reconsideration or pursue other
administrative proceedings before they
may file suit in court.
E. Protection of Children From
Environmental Health and Safety Risks
Executive Order 13045, ‘‘Protection of
Children from Environmental Health
and Safety Risks’’ (62 FR 19855, April
23, 1997), applies to any rule that: (1)
Is determined to be ‘‘economically
significant’’ as defined under Executive
Order 12866, and (2) concerns an
environmental, health, or safety risk that
E:\FR\FM\12JAP2.SGM
12JAP2
4010
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
the agency has reason to believe may
have a disproportionate effect on
children. If the regulatory action meets
both criteria, the agency must evaluate
the environmental health or safety
effects of the planned rule on children,
and explain why the planned regulation
is preferable to other potentially
effective and reasonably feasible
alternatives considered by the agency.
This notice is part of a rulemaking
that is not expected to have a
disproportionate health or safety impact
on children. Consequently, no further
analysis is required under Executive
Order 13045.
F. Paperwork Reduction Act
Under the Paperwork Reduction Act
of 1995 (PRA), a person is not required
to respond to a collection of information
by a Federal agency unless the
collection displays a valid OMB control
number. There is no information
collection requirement associated with
this proposal. The proposal would
require new vehicles to be capable of
V2V communications, which would
require a new aspect of performance
where the vehicle broadcasts Basic
Safety Messages (BSMs) during
operation, which other vehicles could
then receive and interpret as
appropriate. BSMs include information
about a vehicle’s current location,
heading, and speed, among other
things—information that safety
applications on other vehicles could
interpret to determine whether a
warning to the driver is needed for the
driver to avoid a potential crash. The
agency does not foresee any reporting
requirements or PRA related impacts
directly attributable to the proposed
performance requirements in this
proposal.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
G. National Technology Transfer and
Advancement Act
Section 12(d) of the National
Technology Transfer and Advancement
Act (NTTAA) requires NHTSA to
evaluate and use existing voluntary
consensus standards in its regulatory
activities unless doing so would be
inconsistent with applicable law (e.g.,
the statutory provisions regarding
NHTSA’s vehicle safety authority) or
otherwise impractical. Voluntary
consensus standards are technical
standards developed or adopted by
voluntary consensus standards bodies.
Technical standards are defined by the
NTTAA as ‘‘performance-based or
design-specific technical specification
and related management systems
practices.’’ They pertain to ‘‘products
and processes, such as size, strength, or
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
technical performance of a product,
process or material.’’
Examples of organizations generally
regarded as voluntary consensus
standards bodies include ASTM
International, SAE International (SAE),
and the American National Standards
Institute (ANSI). If NHTSA does not use
available and potentially applicable
voluntary consensus standards, we are
required by the Act to provide Congress,
through OMB, an explanation of the
reasons for not using such standards.
This proposal would require new
light vehicles to be capable of V2V
communications. Section III.D.10 above
discusses how voluntary consensus
standards by SAE, IEEE, and ISO
interact with the agency’s proposed
requirements for V2V communication.
In summary, 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 this
proposal, NHTSA’s job is to identify and
define performance requirements and
verification tests that will indicate that
V2V devices have been designed and
implemented such that they will operate
to provide V2V communications and
security that will support crash
avoidance applications. The voluntary
consensus standards are building blocks
for those requirements, but as they are
not at the vehicle-level, they cannot be
incorporated wholesale into the FMVSS.
We seek comment on NHTSA’s
approach to inclusion of relevant
voluntary consensus standards in the
development of our proposed
requirements.
H. Unfunded Mandates Reform Act
Section 202 of the Unfunded
Mandates Reform Act of 1995 (UMRA)
requires federal agencies to prepare a
written assessment of the costs, benefits,
and other effects of proposed or final
rules that include a Federal mandate
likely to result in the expenditure by
State, local, or tribal governments, in the
aggregate, or by the private sector, of
more than $100 million annually
(adjusted for inflation with base year of
1995). Before promulgating a rule for
which a written statement is needed,
section 205 of the UMRA generally
requires the agency to identify and
consider a reasonable number of
regulatory alternatives and adopt the
least costly, most cost-effective, or least
burdensome alternative that achieves
the objectives of the rule. The
provisions of section 205 do not apply
when they are inconsistent with
applicable law. Moreover, section 205
allows the agency to adopt an
PO 00000
Frm 00158
Fmt 4701
Sfmt 4702
alternative other than the least costly,
most cost-effective, or least burdensome
alternative if the agency publishes with
the final rule an explanation of why that
alternative was not adopted.
As noted above, NHTSA has prepared
a detailed economic assessment of this
proposal in the PRIA. In that
assessment, the agency analyzes the
benefits and costs of requiring new light
vehicles to be capable of V2V
communications. NHTSA’s preliminary
analysis indicates that this proposal
could result in private expenditures of
between $2 and $5 billion annually.
The PRIA also analyzes the benefits
and costs of a range of regulatory
alternatives. While the ‘‘No Action’’
alternative would result in no costs, it
would also result in no benefits. For the
alternative that would include mandates
for safety applications, NHTSA’s
preliminary analysis indicates that the
costs would not be significantly
different from the proposal, but that
benefits would accrue faster, such that
the alternative would be cost-effective
and achieve positive net benefits two
model years before the proposal would.
The agency is proposing not to require
applications at this time, however, due
to the need for significant additional
research to establish performance
requirements and test procedures for
them, and without which unintended
consequences such as high false positive
rates could occur.
Since the agency has estimated that
this proposal could result in
expenditures of over $1 billion
annually, NHTSA has performed a
probabilistic uncertainty analysis to
examine the degree of uncertainty in its
cost and benefit estimates and included
that analysis in Chapter 12 of the PRIA.
I. National Environmental Policy Act
NHTSA has analyzed this rulemaking
action for the purposes of the National
Environmental Policy Act. The agency
has determined that implementation of
this proposed action will not have any
significant impact on the quality of the
human environment.
J. Plain Language
Executive Order 12866 requires each
agency to write all rules in plain
language. Application of the principles
of plain language includes consideration
of the following questions:
• Have we organized the material to
suit the public’s needs?
• Are the requirements in the rule
clearly stated?
• Does the rule contain technical
language or jargon that isn’t clear?
• Would a different format (grouping
and order of sections, use of headings,
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
paragraphing) make the rule easier to
understand?
• Would more (but shorter) sections
be better?
• Could we improve clarity by adding
tables, lists, or diagrams?
• What else could we do to make the
rule easier to understand?
If you have any responses to these
questions, please include them in your
comments on this proposal.
K. Regulatory Identifier Number (RIN)
The Department of Transportation
assigns a regulation identifier number
(RIN) to each regulatory action listed in
the Unified Agenda of Federal
Regulations. The Regulatory Information
Service Center publishes the Unified
Agenda in April and October of each
year. You may use the RIN contained in
the heading at the beginning of this
document to find this action in the
Unified Agenda.
L. Privacy Act
Anyone is able to search the
electronic form of all comments
received into any of our dockets by the
name of the individual submitting the
comment (or signing the comment, if
submitted on behalf of an association,
business, labor union, etc.). You may
review DOT’s complete Privacy Act
Statement in the Federal Register
published on April 11, 2000 (65 FR
19477–78).
List of Subjects in 49 CFR Part 571
Motor vehicles, Motor vehicle safety.
Proposed Regulatory Text
In consideration of the foregoing,
NHTSA proposes to amend 49 CFR part
571 as follows:
PART 571—FEDERAL MOTOR
VEHICLE SAFETY STANDARDS
1. The authority citation for part 571
continues to read as follows:
■
Authority: 49 U.S.C. 322, 30111, 30115,
30117, and 30166; delegation of authority at
49 CFR 1.95.
2. Add § 571.150 to subpart B to read
as follows:
■
srobinson on DSK5SPTVN1PROD with PROPOSALS2
§ 571.150 Standard No. 150; V2V
communications.
S1 Scope. This standard specifies
performance requirements for vehicleto-vehicle communications capability.
S2 Purpose. The purpose of this
standard is to ensure that new motor
vehicles are able to transmit and receive
standardized, authenticated Basic Safety
Messages (BSMs), in order to create an
information environment upon which a
variety of safety applications can rely,
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
which in turn can reduce deaths and
injuries on the roads.
S3 Application. This standard
applies to new passenger cars,
multipurpose passenger vehicles,
trucks, and buses with a gross vehicle
weight rating of 10,000 pounds (4,536
kilograms) or less.
S4 Definitions.
Basic Safety Message (BSM) contains
safety data according to specific
requirements and is used in a variety of
applications to exchange safety data
regarding vehicle status. BSM
transmission of 10 times per second is
typical when congestion control is not
active. BSM content, initialization time,
transmission requirements, and other
characteristics must comply with the
requirements of S5, below.
Channel busy ratio is a measure of the
amount of time a channel is designated
as busy over the total observed time
channel is available.
Coordinated Universal Time (UTC) is
the international standard of time that is
kept by atomic clocks around the world
Denial of Service (DoS) attack is an
attempt to make a machine or network
resource unavailable to its intended
users, such as to temporarily or
indefinitely interrupt or suspend such
as disrupting DSRC communications
DSRC device means a device uses
Dedicated Short Range Communications
to transmit and receive a variety of
message traffic to and from other DSRC
devices that include On-Board Units
(integrated into a vehicle), Aftermarket
Safety Devices, and Road-Side Units.
Event Flag is part of the Basic Safety
Message. An Event Flag conveys the
sender’s status with respect to safetyrelated events such as Antilock Brake
System activation, Stability Control
Activation, hard braking, and airbag
deployment.
GNSS (Global Navigation Satellite
System) means a satellite system that is
used to pinpoint the geographic location
of a user’s receiver anywhere in the
world.
Packet Error Rate refers to the unit of
data for radio transmission subject to
Forward Error Correction (FEC). The
number of error packets after FEC
divided by the total number of received
packets is the Packet Error Rate.
Reasonably Linkable refers to data
elements in the BSM or other aspects of
V2V transmissions 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. This is intended to have the
same meaning as ‘‘linkable as a practical
matter’’ as used in this standard.
PO 00000
Frm 00159
Fmt 4701
Sfmt 4702
4011
Roadside Equipment (RSE) means any
roadside equipment that prepares and
transmits messages to V2V devices and
receives messages from V2V devices for
the purpose of supporting V2I
applications or, potentially, security.
This is intended to include the DSRC
radio, traffic signal controller where
appropriate, interface to the backhaul
communications network necessary to
support the applications, and support
such functions as data security,
encryption, buffering, and message
processing.
Timestamp means the current time of
an event that is recorded by a computer.
Vehicle reference point means 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,
encompassing the farthest forward and
rearward points and side-to-side points
on the vehicle, including original
equipment such as outside side view
mirrors.
S5 Requirements. Each vehicle to
which this standard applies must
transmit and receive messages
consistent with the requirements below.
To obtain interoperable V2V
communications for crash avoidance
safety, DSRC devices must be capable
of: First, transmitting and receiving an
established message (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); Second, conforming
to DSRC transmission protocols that
will support crash avoidance safety (i.e.,
how far, how often, on what frequency,
etc.); Third, implementing a method for
a device to add validation context to
message transmissions such that a
receiver of that message can
authenticate certain information about
the sender of the message; Fourth,
incorporating a uniform method for
dealing with possible occurrences of
high volumes of DRSC messages (i.e.,
potentially reducing the frequency or
range of messages in high congestion
situations) and; Fifth, robustness to
incorrect or malicious incoming
messages.
S5.1 Content. Each BSM must
contain the following elements, except
as provided in S5.1.7.:
S5.1.1 Message packaging. As part
of each BSM, a DSRC device must
transmit a Message ID, a Message Count,
and a Temporary ID, as follows:
S5.1.1.1 The Message ID must be the
digit ‘‘2.’’
S5.1.1.2 The Message Count must
contain an integer between 0 and 127
that is 1 integer greater than the integer
used in the last BSM transmitted by the
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
4012
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
same DSRC device. If the last BSM
Message Count was 127, then the
Message Count for the following BSM is
0.
S5.1.1.3 The Temporary ID must be
a randomly generated 4-digit number.
The DSRC device must randomly
generate a new 4-digit number every
five minutes. However, if other
temporary identifiers, such as
pseudonym certificates, are used, the
Temporary ID should be changed every
time another identifier (such as a
pseudonym certificate) is changed.
S5.1.2 Time. As part of each BSM, a
DSRC device must transmit a data
element indicating the time, expressed
in UTC, and within +/¥ 1 milliseconds
of the actual UTC time.
S5.1.3 Location. As part of each
BSM, a DSRC device must transmit:
S5.1.3.1 Longitudinal and lateral
location within 1.5 meters of the actual
position at a Horizontal Dilution of
Precision (HDOP) smaller than 5 within
the 1 sigma absolute error; and
S5.1.3.2 Elevation location within 3
meters of the actual position at a
Horizontal Dilution of Precision (HDOP)
smaller than 5 within the 1 sigma
absolute error.
S5.1.4 Movement. As part of each
BSM, a DSRC device must transmit
speed, heading, acceleration, and yaw
rate, as follows:
S5.1.4.1 Speed must be reported in
increments of 0.02 m/s, within 1 km/h
(0.28 m/s) of the vehicle’s actual speed.
S5.1.4.2 Heading must be reported
accurately to within 2 degrees when the
vehicle speed is greater than 12.5 m/s
(∼28 mph); and to within 3 degrees
when the vehicle speed is less than or
equal to 12.5 m/s. Additionally, when
the vehicle speed is below 1.11 m/s
(∼2.5 mph), the DSRC device must latch
the current heading and transmit the
last heading information prior to the
speed dropping below 1.11 m/s. The
device is to unlatch the latched heading
when the vehicle speed exceeds 1.39 m/
s (∼3.1 mph) and transmit a heading
within 3 degrees of its actual heading
until the vehicle reaches a speed of 12.5
m/s where the heading must be
transmitted at 2 degrees accuracy of its
actual heading.
S5.1.4.3 Acceleration. Horizontal
(longitudinal and lateral) acceleration
must be reported accurately to 0.3 m/s2,
and vertical acceleration must be
reported accurately to 1 m/s2.
S5.1.4.4 Yaw rate. Yaw rate must be
reported accurately to 0.5 degrees/
second.
S5.1.5 Other event based
information.
S5.1.5.1 Path History. The Path
History data frame will be transmitted
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
as a required BSM element at the
operational frequency of the BSM
transmission
S5.1.5.1.1 Path History data frame
requires a history of a vehicles past
GNSS locations as dictated by GNSS
data elements including UTC time,
latitude, longitude, heading, elevation
sampled at a periodic time interval of
100 ms and interpolated in-between by
circular arcs, to represent the vehicle’s
recent movement over a limited period
of time or distance.
S5.1.5.1.2 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.
S5.1.5.1.3 Minimum number of Path
History points vehicles should report
the minimum number of points so that
the represented Path History distance
(i.e., the distance between the first and
last Path History point) is at least 300 m
and no more than 310 m, unless initially
there is less than 300 m of Path History.
If the number of Path History 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.
S5.1.5.1.3 Path History data frame
shall be populated with time-ordered
Path History points, with the first Path
History point being the closest in time
to the current UTC time, and older
points following in the order in which
they were determined.
S5.1.5.2 Path Prediction.
Trajectories in the Path Prediction 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 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.
S5.1.5.2.1 When a device is in
steady state conditions over a range
from 100 m to 2,500 m in magnitude,
the subsystem will populate the Path
Prediction data frame with a calculated
radius that has less than 2% error from
the actual radius. 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
PO 00000
Frm 00160
Fmt 4701
Sfmt 4702
where the average of the absolute value
of the change of yaw rate over time is
smaller than 0.5 deg/s2.
S5.1.5.2.2 After a transition from the
original constant radius (R1) to the
target constant radius (R2), the
subsystem shall repopulate the Path
Prediction data frame within four
seconds under the maximum allowable
error bound defined above.
S5.1.5.2.3 Path Prediction
trajectories will be transmitted as a
required BSM element at the operational
frequency of the BSM transmission.
S5.1.5.3 Exterior lights. 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 to indicate the light is on, the
data element should not be transmitted.
S5.1.5.3.1 The Exterior Lights data
element, if available, provides the status
of all exterior lights on the vehicle,
including parking lights, headlights
(including low and high beam, and
automatic light control), fog lights,
daytime running lights, turn signal
(right and left), and hazard signals.
S5.1.5.4 Event flags. If a stated
criterion is met as indicated for each
Event Flag listed, 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 BSM for as long as an
event is active.
• 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.
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
4013
S5.3.3 Transmission data rate. A
DSRC device must transmit the BSM at
a bit rate of 6 Mbps.
S5.3.4 Transmission staggering
timing. A DSRC device must transmit
the BSM every 100 ms +/1 a random
value between 0 and 5 ms.
S5.4 Signing the BSM. [Reserved for
message signature requirement if
needed]
S5.4.1 Rotating certificates.
[Reserved for rotating certificate
requirement if needed]
S5.5 Congestion Mitigation.
A DSRC device must transmit the
BSM as follows under the following
circumstances:
S5.5.1 Calculate Tracking Error.
This section specifies the set of steps
that calculate the tracking error in the
congestion control algorithm for the
system. Note that the tracking error is
communications-induced and
independent of the positioning system
tracking error. The system performs the
following operations every 100 ms.
• The system estimates the position
of the HV at the current time, defined
as HV local estimator, per defined
below.
3. If 50 ms <= Delta_time_ms <= 150
ms, then perform position extrapolation:
• Calculate the estimated distance
traveled by the vehicle in
Delta_time_ms.
• Ahead_distance_m = Speed_mps *
Delta_time_ms/1000
• Across_distance_m = 0
4. Use ConvertXYtoLatLon function to
find the vehicle’s new position at time
T′. ConvertXYtoLatLon(. . .)
INPUT
RefLat = e.g., REF_LATITUDE (rad)
RefLon = e.g., REF_LONGITUDE (rad)
RefHeading = e.g., REF_HEADING
(rad)
Y = ACROSS_DISTANCE (m w.r.t.
REF LATLON)
X = AHEAD_DISTANCE (m w.r.t. REF
LATLON)
a = 6378137; # semi-major axis of
earth
f = 0.003353; # flattening
f1 = (f*(2-f))∧0.5; # eccentricity
(1) Delta_time_ms = T ¥ T
2. Do not perform position
extrapolation in the following cases:
• If Delta_time_ms < 0, then there is
a time-related error.
• If Delta_time_ms > 150 ms, then the
vehicle has not received a position
update for a very long time and its
position is outdated.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00161
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.019
including but not limited to VIN, VIN
string, vehicle license plate, vehicle
registration information, or owner code.
S5.2 Initialization time. A DSRC
device must begin transmitting the BSM
within 2 seconds after the V2V device
power is initiated.
S5.3 Transmitting the BSM. A DSRC
device must transmit the BSM with the
following power/range, on the following
channel, and at the following data
rate(s) and times:
S5.3.1 Transmission range. A DSRC
device must transmit the BSM in all
directions on the same plane as the
device (i.e., 360 degrees) and at least 10
degrees above the vehicle and 6 degrees
below the vehicle (i.e., along the vertical
axis) such that it can be received at any
point within at least 300 meters from
the transmission antenna, with a Packet
Error Rate (PER) of less than 10 percent.
S5.3.2 Transmission channel. A
DSRC device must transmit the BSM on
Channel 172, as allocated for ‘‘public
safety applications involving safety of
life and property’’ in 47 CFR part 90,
subpart M. All non safety-critical
communications will occur on the
remaining channels allocated for DSRC
in subpart M.
1. First find Delta_time, the time since
vehicle’s last known position.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
• 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.
S5.1.6 Vehicle-based motion
indicators. As part of each BSM, a DSRC
device must transmit transmission state
and steering wheel angle.
S5.1.6.1 Transmission state must be
reported as either ‘‘neutral,’’ ‘‘reverse,’’
or ‘‘forward’’ for any forward gear.
S5.1.6.2 Steering wheel angle must
be reported accurately to 5 degrees.
S5.1.7 Vehicle size. Vehicle size
must be reported accurately to 0.2
meters of the vehicle’s length and
width.
S5.1.9 Prohibited elements of the
BSM. No BSM may contain data linked
or reasonably linkable to a specific
private vehicle or its driver or owner,
4014
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
f2 = a*(1-f1∧2)/(1f1∧2*(sin(RefLat))∧2)∧(3/2); #
radius of earth in meridian
f3 = a/(1-f1∧2*(sin(RefLat))∧2)∧(1/2);
# radius of earth in prime vertical
E = (cos(RefHeading)*Y +
sin(RefHeading)*X;
N = (cos(RefHeading)*X ¥
sin(RefHeading)*Y;
OUTPUT
NEW_LATITUDE (rad) = (1/f2)*N +
RefLat;
NEW_LONGITUDE (rad) =
(1/(f3*cos(RefLat)))*E + RefLon;
5. For all future calculations, use the
calculated New_Latitude and
New_Longitude as vehicle’s position,
and current time.
• The system makes an assumption of
the latest HV state information received
by the RVs based on a Bernoulli trial
corresponding to the quality of channel
indicator as defined below:
Assumption of latest HV State
Information at RVs
After each transmission, use a
Bernoulli trial with the channel quality
indicator P(k) to infer whether this
previous transmission is successfully
received by RVs.
• Channel Quality Indicator (P): The
system calculates P as an average of the
PERs observed by the HV from all of the
RVs within 100 m of the HV over an
interval 5000 ms, and updated at the
end of each 1000 ms sub-interval.
Let AVGPER be calculated as:
where
PERi
is for RV ‘i’ and N(k) is the Vehicle
Density within 100 m.
Next, P is calculated by smoothening
AVGPER to filter out temporal noise or
disturbance in the measurement as
follows:
where
(k) is the channel
i is the weight factor 0.9, P
quality indicator for the current interval
window. Note that, if P(k) exceeds 0.3,
then it is set to 0.3.
2. If, however, the outcome of this
Bernoulli trial is negative, treat the
previous transmission by HV as a failure
and do not update the latest HV state
information as that received by RVs.
3. Count the number of Bernoulli
trials with successive negative
outcomes. If this count is greater than 3,
set the previous transmission as
successful and update the latest
information the RVs have about the HV
as the state information contained in the
previous transmission.
The state information is defined:
Let qlatest be the HV’s assumed latest
state information received by RVs and
qPre-tx be the HV’s state information
contained in the message of its previous
transmission (wheret is the time in msec
when the longitudinal position x(in
degrees), lateral positiony (in degrees),
speed v(in m/s), and heading q(t)(in
degrees) are measured. The HV’s
assumed latest state information
received by RVs is updated after each
transmission as follows:
EP12JA17.034
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00162
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.020
srobinson on DSK5SPTVN1PROD with PROPOSALS2
1. If the outcome of this Bernoulli trial
is positive, assume that the previous
transmission by HV is successfully
received by RVs. Update the latest
information the RVs have about the HV
as the state information contained in
previous transmission.
srobinson on DSK5SPTVN1PROD with PROPOSALS2
where
rand () is a uniform random number generator
and P(k) is the estimated channel quality
indicator.
• Using the latest HV state
information assumption at RVs, the
system estimates the position of the HV
at the current time, defined as HV
remote estimator, using the estimator
described above. This indicates where
the HV believes the RVs ‘‘thinks’’ that
the HV is located at the current time.
• The system then calculates the
tracking error e(k), between where the
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
HV believes its current position is and
where the HV believes RVs think the HV
is located at the current time. It is also
known as the suspected, expected or
estimated tracking error between the HV
local estimator and the HV remote
estimator.
Where:
the tracking error is defined as the distance
between HV local estimator position
ˆ
ˆ
(x(k), (y(k)) and output of the HV remote
˜
˜
estimator position, ((x(k), (y(k)) using the
great circle formula, i.e.
PO 00000
Frm 00163
Fmt 4701
Sfmt 4702
4015
ˆ
ˆ
˜
e(k) = R(x(k)) × (cos¥1(sin(x(k)) × sin(x(k))
ˆ
ˆ
˜
˜
+ cos(x(k)) × cos(x(k)) × cos(y(k) ¥ y(k))))
where
ˆ
R(x(k)) = a × (1 ¥ f12)/(1 ¥ f12 × sin 2
ˆ
(x(k)))1.5
is the Meridian Radius of the Earth in meters
ˆ
x(k)), at latitude, a = 6378137 is the mean
radius of earth in meters, fi = (f × (2 ¥ f)) 0.5
is the Eccentricity, and f = 0.003353 is earth’s
flattening.
ˆ
ˆ
Here (x(k), y(k)) are the latitude and
longitude from the HV Local Estimator,
˜
˜
converted to radians, and (x(k), y(k)) the
latitude and longitude from the HV Remote
Estimator, converted to radians.
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.021
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
4016
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
transmitted at maximum power (20 dBm,
Pmax);
S5.5.2.3 If the channel busy ratio is above
80% (Umax) and the transmission is based
on Max_Trans_Time, then the BSM must be
transmitted at minimum power (10 dBm,
Pmin);
S5.5.2.4 If the channel busy ratio is
between (c) and (b), then the BSM must be
transmitted at a power based on a linear
function that proportionally reduces the
transmission power based on the channel
busy ratio value during the previous
transmission (U(k-1)) and the previous
transmission power (P(k-1). Where the
transmitted power (P(k)) is defined by:
S5.6 Detecting misbehavior. A DSRC
device must detect misbehavior in the
following ways:
S5.6.1 Internal self-diagnostics. A DSRC
device must be able to perform the following
self-diagnostic checks:
S5.6.1.1 If a DSRC device detects a
malfunctioning sensor which may cause
misbehavior, the device must:
(a) Either transmit the BSM with the
affected elements set to ‘‘Unavailable’’ if
relevant standards allow the element to be set
to ‘‘Unavailable’’; or
(b) Cease BSM transmission if relevant
standards do not allow the element to be set
to ‘‘Unavailable.’’
If either (a) or (b) is detected, [Reserved for
requirement to report malfunctions if
needed]
S5.6.1.2 [Reserved for requirement to
report physical tampering]
S5.6.2 Checking and reporting on the
plausibility of incoming BSMs. A DSRC
device must perform a preliminary
plausibility check on all incoming BSMs and
respond accordingly, as follows:
S5.6.2.1 The preliminary plausibility
check must identify as an implausible
message any BSM for which the components
of the vehicle dynamic state (position, speed,
acceleration, and yaw rate) are outside the
following values:
(a) Speed greater than 70 m/s (252 km/h or
156 mph);
(b) Longitudinal acceleration of 0–100 km/
h in fewer than 2.3 seconds (greater than 12
m/s2);
(c) Longitudinal deceleration of 100–0 km/
h in fewer than 95 feet (greater than 12 m/
s2);
(d) Lateral acceleration of greater than 11
m/s2 (1.12 G);
(e) Yaw rate of greater than
1.5 radian/s
Additionally, a BSM must be identified as
implausible if values within the BSM are not
internally consistent given the formula V2 =
ac/(Y′)2.
S5.6.2.2 A DSRC device must be able to
perform the plausibility checks described in
S5.6.2.1 on at least 5,500 BSMs per second.
S5.6.2.3 [Reserved for requirement to
report any failed plausibility check]
S5.6.2.4 A DSRC device must support the
detection of other devices which are
suspected of misbehaving, and at a minimum
detect the following types of misbehavior:
(a) Proximity Plausibility: Instances are
detected of two or more vehicles, either
partially or wholly, occupying the same
physical space based on the reported GPS
positions.
(b) Motion Validation: Attempts to validate
the reported position of a transmitting
vehicle based on the previously-reported
velocity and heading values of the vehicle.
(c) Content and Message Verification:
Attempts to categorize BSMs as suspicious by
checking the data validity of the BSM.
(d) Denial of Service Detection: Attempts to
disrupt, limit, or alter the functionality of
V2V device to meet the requirements through
exhaustions of storage, computation, or other
limited resources of the V2V device.
S5.6.3 [Reserved for requirements for
sending misbehavior reports]
S5.7 Indicating a malfunction. The DSRC
device must be able to indicate to its user the
occurrence of one or more malfunctions that
affect the performance of the device, its
supporting equipment, or the inputs used to
form, transmit, or receive a BSM, as follows:
S5.7.1 Malfunctions could include, but
are not limited to, the following:
(a) Device components not operating
properly;
(b) Input sensor data falling outside
tolerance levels;
(c) On-board memory failures;
(d) GPS receiver failures;
(e) An inability to transmit or receive
BSMs; or
(f) Any other failure that could prevent
normal operation.
S5.7.2 The malfunction indication must
be clearly presented to device users in the
form of a telltale lamp or message.
S5.7.3 Owners’ information for the device
(or vehicle, if the DSRC device is installed as
original equipment) must clearly describe the
malfunction indication, potential causes, and
when the device must be taken in for service
(as needed).
S5.7.4 The malfunction indication must
remain present and/or illuminated until the
malfunction no longer exists and the DSRC
device is returned to proper operation.
S5.8 [Reserved for requirement to
communicate with the SCMS if needed].
S5.9 Communicating about and obtaining
software and security updates. A DSRC
device must be able to indicate clearly to
users that either device software or security
updates are available and that the user must
consent to the update before it can occur. If
the DSRC device is included in a vehicle as
original equipment, the indicator must be
present in the vehicle. If the DSRC device is
not included in the vehicle as original
equipment, the indicator must be present in
the device itself.
S5.10 [Reserved for hardware protection
requirement].
S5.11 Consumer Privacy Statement.
S5.11.1 Owners information for the
device must include the statement set forth
in Appendix A below.
S5.11.2 Manufacturers also must make
the statement set forth in Appendix A easily
accessible to the public, as by publishing it
on an easily located Web site indexed by
make, model, and year.
S6 Test Conditions.
S6.1 Ambient conditions.
S6.1.1 The ambient temperature is
between 0 °C (32 °F) and 40 °C (104 °F).
S6.1.2 The maximum wind speed is no
greater than 10 m/s (22 mph) for passenger
cars and 5 m/s (11 mph) for multipurpose
passenger vehicles, trucks, and buses.
S6.2 Road test surface.
S6.2.1 The tests are conducted on a dry,
uniform, solid-paved surface. Surfaces with
irregularities and undulations, such as dips
and large cracks, are unsuitable.
S6.2.3 The test surface has a consistent
slope between level and 1 percent.
S6.3 Vehicle conditions.
S6.3.2 Test weight. The vehicle may be
tested at any weight consisting of the test
driver and instrumentation only that fall
between its lightly loaded vehicle weight
(LLVW) and its gross vehicle weight rating
(GVWR) without exceeding any of its gross
axle weight ratings.
S6.3.3 Tires. The vehicle is tested with
the tires installed on the vehicle at the time
of initial vehicle sale. The tires are inflated
to the vehicle manufacturer’s recommended
cold tire inflation pressure(s) specified on the
vehicle’s placard or the tire inflation pressure
label.
S7 Test Procedures.
S7.1 Pre-test/Inspection.
S7.1.1 Inflate the vehicles’ tires to the
cold tire inflation pressure(s) provided on the
vehicle’s placard or the tire inflation pressure
label.
S7.1.2 Vehicle dimensions.
S7.1.2.1 Measure vehicle length
including any equipment installed on the
vehicle when first sold.
S7.1.2.2 Measure vehicle width including
any equipment installed on the vehicle when
first sold.
S7.1.2.3 Measure vehicle height
including any equipment installed on vehicle
when first sold.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
PO 00000
Frm 00164
Fmt 4701
Sfmt 4702
E:\FR\FM\12JAP2.SGM
12JAP2
EP12JA17.022
srobinson on DSK5SPTVN1PROD with PROPOSALS2
S5.5.2 Transmission power must vary
depending on the following:
S5.5.2.1 If there is an Event Flag or a
transmission decision is based on p(k), the
BSM must be transmitted at maximum power
despite the presence of any other conditions;
S5.5.2.2 If the channel busy ratio is below
50% (Umin) and the transmission is based on
Max_Trans_Time, then the BSM must be
srobinson on DSK5SPTVN1PROD with PROPOSALS2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
S7.1.2.4 Measure the V2V System GNSS
Receiver Antenna.
S7.1.2.5 Measure the independent
instrumented vehicle sensor coordinates.
S7.2 Static Performance Test Procedure:
S7.2.1 Place the test vehicle on car wheel
rollers and position the vehicle on the test
track.
S7.2.2 Two dimensional Range: Position
a DSRC packet capture device directly in
front of the test vehicle with the following
characteristics:
S7.2.2.1 The device is 1.5 m above the
test surface;
S7.2.2.2 The device is at a nominal
distance of 300 m in front of the test vehicle.
S7.2.3 Upward elevation range: Position a
DSRC packet capture device at any point
along the following line.
S7.2.3.1 The line originates at a point that
is directly 1.5 m above the vehicle reference
point.
S7.2.3.2 The line rises at a +10 degree
angle from the test surface proceeding in the
direction directly in front of the test vehicle.
S7.2.3.3 The line terminates at a point
that is directly above the point used in
S7.2.2.
S7.2.4 Downward elevation range:
Position a DSRC packet capture device at any
point along the following line.
S7.2.4.1 The line originates at a point that
is directly 1.5 m above the vehicle reference
point.
S7.2.4.2 The line falls at a ¥6 degree
angle from the test surface proceeding in the
direction directly in front of the test vehicle.
S7.2.4.3 The line terminates at any point
where it intersects the test surface.
S7.2.5 Configure the DSRC packet capture
devices to log BSMs over-the-air (OTA);
devices must have a receive sensitivity of
¥92 dBm.
S7.2.6 Activate the DSRC packet capture
devices to log BSMs OTA.
S7.2.7 Activate the test vehicle starting
system to initiate BSM transmission.
S7.2.7.1 Run the vehicle for 110 mins.
S7.2.7.2 Rotate the vehicle 90 degrees in
the clockwise direction every 15 minutes
until the time in S7.2.7.1 expires.
S7.2.8 Deactivate the test vehicle and
DSRC packet capture devices.
S7.2.9 Retrieve and process the log files
to determine compliance with S.5.
S7.2.10 Positional Accuracy Test.
S7.2.10.1 Using the transmission blocking
water filled plastic blanket that will hold one
gallon of water with a water width of 1 inch,
cover the test vehicle GPS antenna to prevent
it from receiving a valid GNSS signal.
S7.2.10.2 Connect GPS signal generator to
the test vehicle OBE.
S7.2.10.3 Activate the test vehicle starting
system to initiate BSM transmission.
S7.2.10.4 Activate the DSRC packet
capture devices to log BSMs OTA.
S7.2.10.5 Using the GPS signal generator,
inject a known fake GPS signal into the OBE.
S7.2.10.6 After 5 minutes, deactivate the
test vehicle starting system and DSRC
capture packet device.
S7.2.10.7 Retrieve and process the log
files to determine compliance with the
positional accuracy requirements.
S7.3 Simulated Performance Tests.
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
S7.3.1 Place the test vehicle on the test
track.
S7.3.2 Position a DSRC packet capture
device directly in front of the test vehicle
with the following characteristics:
S7.3.2.1 The device is 1.5 m above the
test surface;
S7.3.2.2 The device is at a nominal
distance of 300 m in front of the test vehicle.
S7.3.3 Configure the DSRC packet capture
device to log BSMs over-the-air (OTA);
devices must have a receive sensitivity of
¥92 dBm.
S7.3.4 Congestion Mitigation.
S7.3.4.1 Position a reference OBE device
(i.e. rack of OBE modules) on the test track
within a 300 m range of the test vehicle.
S7.3.4.2 Activate the DSRC packet
capture device to log BSMs OTA.
S7.3.4.3 Activate the test vehicle starting
system to initiate BSM transmission.
S7.3.4.3.1 Run the vehicle for 15 minutes.
S7.3.4.3.2 After 5 minutes, activate the
reference OBE device in S7.3.4.1 to simulate
a congested DSRC environment.
S7.3.4.3.3 After another 5 minute period,
deactivate the reference OBE device in
S7.3.4.1.
S7.3.4.3.4 After another 5 minute period,
deactivate the test vehicle starting system.
S7.3.4.4 Retrieve and process the log files
to determine compliance with the correct
congestion mitigation strategy in S5.5.
S7.3.5 Misbehavior Detection.
S7.3.5.1 Position a reference OBE device
on the test track within a 300 m range of the
test vehicle.
S7.3.5.2 Activate the DSRC packet
capture device to log BSMs OTA.
S7.3.5.3 Activate the test vehicle starting
system to initiate BSM transmission.
S7.3.5.4 Using the reference OBE device,
transmit simulated misbehaving BSMs.
S7.3.5.4.1 After 10 mins, deactivate the
reference OBE device.
S7.3.5.7 Retrieve and process the log files
to determine compliance with the
misbehavior detection requirement in S5.6.
S7.4 Dynamic Performance Test
Procedure.
S7.4.1 Configure the test vehicle to send
BSMs representing the best estimate of the
BSM data parameters.
S7.4.2 Configure the test vehicle to send
ground truth data (position, speed, heading,
acceleration, yaw rate, and time) from
independent sensors mounted on the test
vehicle via non-DSRC wireless link.
S7.4.3 Configure the DSRC packet capture
device to log BSMs over-the-air (OTA);
devices must have a receive sensitivity of
¥92 dBm.
S7.4.4 Configure an RSE on the test track
to receive the test vehicles’ ground truth data.
S7.4.5 Dynamic test maneuver.
S7.4.5.1 Activate the test vehicle starting
system to initiate BSM transmission.
S7.4.5.2 Activate the DSRC packet
capture device to log BSMs OTA.
S7.4.5.3 Put the test vehicle transmission
in ‘‘Drive’’ and accelerate the vehicle to 30
mph +/¥1 mph.
S7.4.5.4 Apply the service brake to
decelerate the vehicle 0.3 g, bring the vehicle
to a stop.
S7.4.5.6 Shift the transmission to ‘‘Park’’
and cycle the ignition.
PO 00000
Frm 00165
Fmt 4701
Sfmt 4702
4017
S7.4.5.7 Shift the transmission to ‘‘Drive’’
and accelerate the vehicle to 15 mph
+/¥mph.
S7.4.5.8 Proceed up an incline with a
minimum rise of ? ft.
S7.4.5.9 Drive the test vehicle in a figure
eight at 18 mph.
S7.4.5.10 Bring the test vehicle to a stop
and shift the transmission to ‘‘Reverse’’.
S7.4.5.11 Accelerate the test vehicle in
the reverse direction.
S7.4.5.12 Decelerate the vehicle to a stop
and shift the transmission to ‘‘Park’’.
S7.4.5.13 Cycle the ignition.
S7.4.5.14 Deactivate the test vehicle
starting system.
S7.4.5.15 Retrieve and process the log
files to determine compliance with S5.
S7.4.6 Misbehavior Detection:
Plausibility.
S7.4.6.1 Configure a remote test vehicle
(RV1) to offset its positional BSM data
laterally into the left adjacent lane.
S7.4.6.2 Place RV1 on a two lane test
track and position it in the right most lane.
S7.4.6.3 Activate the test vehicle starting
system to initiate BSM transmission.
S7.4.6.4 Activate the DSRC packet
capture device to log BSMs OTA.
S7.4.6.5 Drive the test vehicle [30 mph
+/¥1 mph] along the test track in the left
lane and proceed past RV1.
S7.4.6.6 Repeat S7.4.6.5 three (3) times.
S7.4.6.7 Retrieve and process the log files
to determine compliance with S5.6.
S7.4.6.8 Drive the test vehicle past the
RSE at a constant [30 mph +/¥1 mph].
S7.4.6.9 Bring the test vehicle to a stop.
S7.4.6.10 [Reserved for requirement to
retrieve and process the log files to determine
if a Misbehavior Report was sent to the
SCMS].
S7.4.7 [Reserved for Misbehavior
Detection Signature Failure testing
requirement].
S7.5 V2V Malfunction Detection.
S7.5.1 Start-up Self test:
S7.5.2 Position the test vehicle on the test
platform.
S7.5.3 Position a DSRC packet capture
device at a nominal distance of 300 m from
the test device.
S7.5.4 Create a malfunction on the test
vehicle.
S7.5.5 Activate the DSRC packet capture
device to log BSMs over-the-air (OTA).
S7.5.6 Activate the test vehicle starting
system to initiate BSM transmission.
S7.5.7 Retrieve and process the log files
to determine compliance with S5.
S7.5.8 Cycle the test vehicle starting
system.
S7.5.9 Deactivate the vehicle starting
system.
S7.5.10 Correct the system malfunction.
S7.5.11 Reactivate the test vehicle
starting system.
S7.5.12 Deactivate the test vehicle
starting system.
S8 Phase-in schedule.
S8.1 Vehicles manufactured on or after
September 1, [2 years after issuance of a final
rule], and before September 1, [3 years after
issuance of a final rule]. For vehicles
manufactured on or after September 1, [2
years after issuance of a final rule], and
E:\FR\FM\12JAP2.SGM
12JAP2
srobinson on DSK5SPTVN1PROD with PROPOSALS2
4018
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
before September 1, [3 years after issuance of
a final rule], the number of vehicles
complying with this standard must not be
less than 50 percent of the manufacturer’s
production on or after September 1, [2 years
after issuance of a final rule], and before
September 1, [3 years after issuance of a final
rule].
S8.2 Vehicles manufactured on or after
September 1, [3 years after issuance of a final
rule], and before September 1, [4 years after
issuance of a final rule]. For vehicles
manufactured on or after September 1, [3
years after issuance of a final rule], and
before September 1, [4 years after issuance of
a final rule], the number of vehicles
complying with this standard must not be
less than 75 percent of the manufacturer’s
production on or after September 1, [3 years
after issuance of a final rule], and before
September 1, [4 years after issuance of a final
rule].
S8.3 Vehicles manufactured on or after
September 1, [4 years after issuance of a final
rule]. All vehicles manufactured on or after
September 1, [4 years after issuance of a final
rule] must comply with this standard.
S8.4 Calculation of number of complying
vehicles.
(a) For purposes of complying with S8.1,
a manufacturer may count a vehicle if it is
certified as complying with this standard and
is manufactured on or after June 5, [1 year
after issuance of a final rule], but before
September 1, [3 years after issuance of a final
rule].
(b) For purposes of complying with S8.2,
a manufacturer may count a vehicle if it.
(1) Is certified as complying with this
standard and is manufactured on or after
June 5, [1 year after issuance of a final rule],
but before September 1, [4 years after
issuance of a final rule], and is not counted
toward compliance with S8.1; or
(2) Is certified as complying with this
standard and is manufactured on or after
September 1, [3 years after issuance of a final
rule], but before September 1, [4 years after
issuance of a final rule].
S8.5 Vehicles produced by more than one
manufacturer.
S8.5.1 For the purpose of calculating
average annual production of vehicles for
each manufacturer and the number of
vehicles manufactured by each manufacturer
under S8.1 through S8.3, a vehicle produced
by more than one manufacturer must be
attributed to a single manufacturer as
follows, subject to S8.5.2:
(a) A vehicle that is imported must be
attributed to the importer.
(b) A vehicle manufactured in the United
States by more than one manufacturer, one of
which also markets the vehicle, must be
attributed to the manufacturer that markets
the vehicle.
S8.5.2 A vehicle produced by more than
one manufacturer must be attributed to any
one of the vehicle’s manufacturers specified
by an express written contract, reported to
the National Highway Traffic Safety
Administration under 49 CFR part 585,
between the manufacturer so specified and
the manufacturer to which the vehicle would
otherwise be attributed under S8.5.1.
S8.6 Small volume manufacturers.
Vehicles manufactured during any of the two
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
years of the September 1, [2 years after
issuance of a final rule] through August 31,
[4 years after issuance of a final rule] phasein by a manufacturer that produces fewer
than 5,000 vehicles for sale in the United
States during that year are not subject to the
phase-in requirements of S8.1 through S8.4.
Instead, all vehicles produced by these
manufacturers on or after September 1, [4
years after issuance of a final rule] must
comply with this standard.
S8.7 Final-stage manufacturers and
alterers. Vehicles that are manufactured in
two or more stages or that are altered (within
the meaning of 49 CFR 567.7) after having
previously been certified in accordance with
part 567 of this chapter are not subject to the
phase-in requirements of S8.1 through S8.4.
Instead, all vehicles produced by these
manufacturers on or after September 1, [5
years after issuance of a final rule] must
comply with this standard.
S9 Interoperable technology.
S9.1 The agency is also recognizing that
communications mediums other than DSRC
may be capable of providing equal or better
performance than DSRC. These alternative
technologies would be permissible if and
only if it satisfies all of the criteria set forth
in this section:
S9.1.1 Interoperable technology testing
requirements:
S9.1.1.1 Transmitting and receiving an
established message with all other V2V
devices, including DSRC devices, including
BSM content data as specified in S5.1.2,
S5.1.3, S5.1.4, S5.1.5, S5.1.6, and S5.1.7;
S9.1.1.2 Utilizing transmissions protocols
that achieve at least the same level of
performance as DSRC including S5.2, S5.3.1,
S5.3.4, and S5.3.5; and
S9.1.1.3 Ensuring, at the minimum, the
same robustness to incorrect or malicious
incoming messages as DSRC as specified in
the plausibility checks specified in S5.6.2.
S9.1.2 Interoperable technology
performance requirements:
S9.1.2.1 A device that enables V2V
communication, but does not use DSRC
technology must perform at the same level as
the requirements found in S5.2, S5.3, S5.4,
S5.7–S5.10 for DSRC devices, except that it
is not required to meet:
S9.1.2.2 Specific references to DSRC,
where the technology meets all other
requirements;
S9.1.2.3 The message packaging or
protocol suite requirements found in S5.1.1.
S9.1.2.4 The required channel or data rate
in S5.3.2 and S5.3.3; and
S9.1.2.5 The requirements associated
with message congestion mitigation and
misbehavior detection found in S5.5 and S5.6
except as specified in S5.6.2;
S9.1.3 Interoperability technology testing
procedures:
S9.1.3.1 The test conditions for testing
non-DSRC V2V devices shall be the same as
those for DSRC devices in S6.
S9.1.3.2 The test procedures for testing
non-DSRC V2V devices to determine whether
they can send BSMs that are interoperable
with DSRC devices shall be the same as those
for DSRC devices in S7, minus any specific
references to DSRC in the vehicle being
tested, including but not limited to S7.3.4,
S7.3.5, and S7.4.6.
PO 00000
Frm 00166
Fmt 4701
Sfmt 4700
S9.1.3.3 [Reserved for test procedures on
receiving BSMs from a DSRC test device]
S9.1.3.4 [Reserved for test procedures on
ensuring interoperability with other
approved non-DSRC V2V devices]
Appendix A to § 571.150: V2V Privacy
Statement
(a) V2V Messages
(1) The National Highway Traffic Safety
Administration (NHTSA) requires that your
vehicle be equipped with a Vehicle-toVehicle (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.
(2) 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.
(3) 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 crashavoidance safety applications.
(b) Collection, Storage and Use of V2V
Information
(1) 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.
(2) 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 safetyrelated 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
E:\FR\FM\12JAP2.SGM
12JAP2
Federal Register / Vol. 82, No. 8 / Thursday, January 12, 2017 / Proposed Rules
srobinson on DSK5SPTVN1PROD with PROPOSALS2
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
VerDate Sep<11>2014
23:49 Jan 11, 2017
Jkt 241001
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.
(3) 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
PO 00000
Frm 00167
Fmt 4701
Sfmt 9990
4019
Assessment, published by The U.S.
Department of Transportation at https://
www.transportation.gov/privacy.
(4) 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.
Dated: December 12, 2016.
Anthony R. Foxx,
Secretary, Department of Transportation.
[FR Doc. 2016–31059 Filed 1–3–17; 4:15 pm]
BILLING CODE 4910–59–P
E:\FR\FM\12JAP2.SGM
12JAP2
Agencies
[Federal Register Volume 82, Number 8 (Thursday, January 12, 2017)]
[Proposed Rules]
[Pages 3854-4019]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[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 https://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 https://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: gregory.powell@dot.gov. 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:
rebecca.yoon@dot.gov.
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 https://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 https://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 https://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 https://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: https://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. https://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 https://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 https://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
https://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 https://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''
https://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 https://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, https://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 https://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'' https://computer.howstuffworks.com/osi1.htm (last accessed: Dec 12, 2016).
\131\ See ``Physical Layer'', https://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)''
https://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'' https://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'' https://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'' https://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'' https://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 https://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, https://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,
https://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'', https://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 https://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 https://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 https://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 https://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 https://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 https://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 https://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 https://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