Meeting Summary — August 27, 2010

Produced by:
Volpe National Tranportation Systems Center
Research and Innovative Technology Administration
U.S. Department of Transportation

Presenters

Valerie Briggs
Team Lead, Knowledge Transfer and Policy
ITS Joint Program Office
Research and Innovative Technology Administration 
U.S. Department of Transportation

Suzanne Sloan
Industry Analyst
Volpe National Transportation Systems Center
Research and Innovative Technology Administration 
U.S. Department of Transportation

Executive Summary

Connected Vehicle Safety Workshop

The Intelligent Transportation Systems (ITS) Joint Program Office (JPO) hosted a three day connected vehicle workshop from July 20th – 22nd, 2010 in Chicago, Illinois. The objectives of the workshop were to provide an informational briefing on the status of connected vehicle Safety Programs, solicit stakeholder feedback on the program roadmaps, and discuss policy issues critical to supporting deployment. On the first day of the workshop, presentations were given on the technical roadmaps for each connected vehicle Safety research program. Stakeholders were encouraged to provide input on program roadmaps and ask questions. The second day of the workshop included a bidder’s conference for DSRC devices and an connected vehicle policy discussion. Finally, the last day of the workshop was dedicated to smaller breakout sessions focusing on specific topics that were of interest to stakeholders.

Connected Vehicle Policy Discussion

Connected vehicle research is a multimodal initiative that aims to enable networked wireless communications among vehicles, the infrastructure, and passengers' personal communications devices. Connected vehicle research is being sponsored by the U.S. Department of Transportation (USDOT) and others to leverage the potentially transformative capabilities of wireless technology to achieve safety, mobility, and environmental benefits for surface transportation.

The connected vehicle program includes multiple research programs, which include both a technical research and policy research component. The objectives of the connected vehicle policy discussion were to present the policy roadmaps for the Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) Safety programs and discuss how they complement the technical program roadmaps. During the discussion, presenters explained the approach used in developing the policy roadmaps, the status of policy program activities, and solicited input on specific policy issue areas. The discussion also included a question and answer session. Presentation slides for this session can be found at:

• Overview of Connected Vehicle Policy Program, Valerie Briggs [PDF 468KB]
• Connected Vehicle Safety Program Policy Roadmap, Suzanne Sloan [PDF 501KB]

Presentation Outline

Overview of Connected Vehicle Policy Program
(Valerie Briggs)

• Agenda
• Technical and Policy Interactions
• What do we mean by Connected Vehicle Policy?
• Policy Roadmap Development Path
• Policy Roadmaps for Connected Vehicle Programs
• Policy Roadmap Development
• Lessons Learned
• Recent Activities

Connected Vehicle Safety Program Policy Roadmap
(Suzanne Sloan)

• Vehicle to Vehicle Safety Application Research Plan
• Safety Program Policy Roadmap
• Critical Policy Areas
• Device and Equipment Certification
• Certificate Authority for Security
• Risk Allocation and Data Ownership
• Benefit-Cost Analysis
• Infrastructure and Deployment
• Rules of Operation and Standards
• Spectrum Analysis and FCC Role
• Governance Structure &Authority

Device and Equipment Certification

Key Comments

• The roadmap does a good job in recognition of policy issues. It is important to note that the challenge of addressing these issues is that you tend to deal with a moving target. We should be hesitant to put a solid stake in the ground and should avoid too much concrete specificity.
• Communication interoperability (i.e. Bluetooth, WiFi standards) is an important capability. Once this is decided, you can determine what devices are allowed in the system due to the safety-related nature of the system.
• The key policy challenge is around the idea of cooperative safety.  For the first time, a manufacturer will need to rely on things outside its control for safety-related issues.
• In discussing equipment certification for safety, the issue of fail-safety must be addressed.  The FAA has defined ‘fail safe’ very well, but FHWA needs to define fail safe even better.
• An additional policy issue should be the issue of jurisdiction.  In many cases, specific issues will span jurisdictions (i.e. seatbelts required federally but use is mandated locally).

Questions and Answers

•  What is the product going to look like when the policy research is done?  How can it be meaningful to us?
  • It will vary across the policy areas.  Walt’s team is in the lead and documentation comes primarily from him.  The policy group may just provide a clear set of recommendations that will be documented.  There will be a need for guidance and training going forward.
  • In many cases we will need to examine what the Federal role should be.
  • There remains the question of who will perform enforcement.
• Can you give me an example of certification relating to existing technology?
  • Self-certification already exists, this could be an example.
• Have you looked at what other people have done in the past, which could inform Walt’s certification process?
  • We’re looking at different analyses and will come up with recommended alternatives. We are looking at what is the trade-off and the policy issue is to say what are we comfortable with.
• Question from Valerie to Audience: We’ve focused on devices themselves for certification.  Is this same process needed for the devices that are going on roadways?
  • You have to do something at a national level if you expect interoperability.
• How do applications behave on the devices and what’s allowed?
  • This is a technical issue.
• Comment: As a state representative, we’re not going to get into the certification business and will look to industry.
  • (Response from audience): They [states] should specify that they will only buy certified products.

Certificate Authority for Security

Key Comments

• As end users of other similar CA services, we should evaluate existing examples and business processes in other areas or industries (e.g. internet).
• The ability to detect misbehavior and determine its associated risk or harm could be more important then identifying who is behind actual misbehavior.

Questions and Answers

• We’ve had a lot of discussions about misbehavior.  It’s important to find and detect, but it’s not so important to punish.
  • That is an option.  One consideration is “what is potential damage or threat” by separating these issues?
•  Just to clarify, when you’re speaking specifically about privacy as it related to this certificate authority and not the more general privacy principles?
  • Yes, the certificate authority privacy needs to be evaluated against these privacy principles and also whether they need to be changed.
• At the back end, who is a certificate authority, what databases do they control, etc?
  • It’s both.  We have to figure it out technically and from a political perspective.
• I think security will have big impact on ability to deploy at RSE. At most of these RSE locations, we don’t have internet access – and if we are required to have an update (communications) to all of our intersections – this would be expensive.  The only reason you need this is really for security – when you look at cost, this will restrain ability to deploy this.
  • One of the things we’re looking at is security vs. threat and tradeoff analysis.
• You mentioned having multiple entities.  Will there be policy investigation about having multiple top-level CAs?
  • We need to figure out the best configurations and what tradeoffs we can accept.

Risk Allocation and Data Ownership

Key Comments

• Clarifying terminology in this area is crucial because nuances in definitions can be significant. One suggestion is to develop a glossary of relevant terms that is also publicly available. A 2013 NPRM requires an official glossary of definitions.
• The policy roadmap does a great job of raising issues.  We encourage you to look deeply within the legal industry at the immunity issues since this will encourage OEMs to release these products.
• There is skepticism about the willingness of the insurance industry to be helpful in this area. OEMs are essentially self insured and liability risk is a real problem.  The direction that is chosen between driver warning and autonomous vehicle control will be a significant factor.  
• Accident statistics and data are important. By demonstrating the benefits of the system over time, it can become increasingly accepted, reliable, and distributed. This will have a big impact.
• Certain public agencies have maximum indemnity.  However, public agencies still need to self insure with underwriters, which requires a risk profile for experiments.  The Safety Pilot will need to develop a risk model, find an underwriter, obtain insurance, and pay premiums to ensure that all participating parties are covered.
• At some point, you must separate observed data (vehicle, speed, license plate numbers) and non-observable data (financial and driver information). It may be necessary to separate or isolate these two data streams.
• It may not be necessary to store information for longer than it is needed. 

Questions & Answers

• You mentioned working on this for a long time, and you mentioned “when deployment starts.”  Deployment has begun and it seems that we’re kicking off discussions again.  When we go to install safety-critical equipment at an intersection and there’s essentially unlimited liability to a supplier, no one will be able to get insurance for these installations unless there’s some sort of shared liability.
  • (Response): At a state level we don’t get sued frequently.  What is the application?  When you start taking control is when the issue rears its ugly head.
  • (Response): It depends on the application – I think it depends on when/where you take control.  Business as usual – states get sued all the time.
• Regarding liability, do traffic signal vendors carry unlimited liability?
  • (Response from audience) The answer is essentially yes.  There is no logic to the way things are resolved in the courts.
  • (Response from audience)  For signals we have conflict monitors in the cabinets, and we have to prove state of the signal.  Different laws in states.
• If the first thing deployed is V2V and my vehicle gives bad advice or takes control, the victim will sue me, not my vehicle—right?
  • (Response from audience)  The reality is that many stakeholders will be involved in legal cases.  I think it will be worthy to investigate whether we can – structure insurance policy – to cover participants (stakeholders) –similar to universal healthcare – many manufacturers are facing challenge of insuring their product.
• We talked about open source, open data, which conflicts with the privacy issue.  What about maintenance?  Does device need to be re-certified?
  •  You’re raising the issue of depending on who does the maintenance is re-certification necessary?
  • (Response from Audience) At Raytheon, for fail safe systems we have a process to allow cost-effective recert process for devices that have been maintained.
• Although I think it’s true that immunity would relate to automaker or deploying agency, how far downstream does that flow?  OEM? Supplier?  Sub-supplier?  Also, since we’re talking immunity for mandated systems, what if we don’t want to wait that long?  Will early-release systems be offered the same protection?
  •  These are good questions – we need to capture them.  NHTSA regulatory decision is not a done deal; all these questions will help that process.
• A device that I put in my car voluntarily or otherwise: who owns that data?  Does every other vehicle have the right to that data?
  • That’s an interesting way to look at the problem.  We’ve asked the question of data ownership.  Black box concept offers a way to look at the problem, but we’re continuing to look at the issue.
  • Data ownership is a huge issue.  We’ve seen it more relevant to mobility and private sector applications so we haven’t discussed it extensively here.
• Are you plugging into what’s been done by Portable Navigation Device (PND) vendors and OEMs?
  • Where there is lots of emerging data / legal issues is around transit data.  Your point about private systems is a very good one, thanks.
• We need to address needs for privacy so that we can have access to probe data for operational improvement.  From a societal perspective there are definitely benefits to be gained.  Also – as a state agency I don’t want to know about driver personal infroamtion – the less I know about driver, the better.
  •  This gets into the issue of “situational privacy.”
• In thinking about models for data collections and retention, the public attitude seems calmer about private companies collecting data (i.e. credit card companies) rather than government.
  •  Very good point.  It begs the issue of how industry comes to the table for partnership.
• If you think about wireless devices and mobility / trail of information that is left, in the wireless/mobile world, GPS is everything.  There are a number of perspectives.  From a personal perspective, that data is used in decisions users make when using the device.   From an infrastructure perspective, there is some data captured about how a device operates on a network.  Used in a few different ways—to improve function of device on infrastructure and to educate the customer on the next generation of device or service that they might buy.  It’s information that is available, but it should not be used in a way that is outside of the infrastructure that you support. It might be important to tap into those models – to use an example.
  •  Tapping into those models will be critical.
  • (Follow-up, Walt): Given your understanding, as we move around the environment is there any storage of movement activity of a cellular device in a network? 
  • (Response): As users travel, certain information is stored.  Certain agents can relay information about where you came from.  It’s nomadic information—doesn’t identify you as a person, only a user.  We maintain a log only for transition from one tower to the next.
  •  (Walt) I thought law enforcement used this information to track suspects?
  •  (Response) There are elements within the network that can establish a time and location. From a network perspective – all we are doing is relaying information.

Benefit-Cost Analysis

Key Comments

• The economic benefits resulting from a connected vehicle communications platform is not promoted enough. This system can drive economic growth.
• A confidence range should be provided in the benefit-cost analysis.

Questions & Answers

• Regarding requirements for network side for safety applications, what are network requirements for safety applications?
  • From a V2V perspective, we may have communication coming from infrastructure, still TBD, from V2I perspective, will be discussed tomorrow
• What considerations will there be for defining time horizon for economic analysis?
  •  Usually the time horizon matches longevity of the asset, or the longest-lived asset if there is more than one.
• In some of the previous CBA you have to assume effectiveness.  With the Safety Pilot hopefully there will be some real info on V2I effectiveness, although info will be mostly relating to V2V.
  •  We’re integrating V2I in planning process; there will be some aspect of V2I on Safety Pilot.
  • Much of what we expect to see on V2I are spot improvements in intersections.  We eventually think we’ll be able to make the case for it.
• As part of cost side, is this exercise going to consider a range of incentives towards aftermarket or retrofit to accelerate deployment?
  • We have to first put out options for what those incentives might look like.  Is there incentive through insurance that’s a viable incentive?  Then feed that into CBA.
  • This is a very specific question—we need to understand what the benefits are for retrofit, and then we need to see what incentives could be added.

Infrastructure for Safety

Key Comments

• It is likely that in addition to security infrastructure, more infrastructure will be needed. Unless we assume that all geometries for all roadways are updated in all devices, there will be a need for additional infrastructure.
• There is a national committee that develops uniform standards for traffic control devices and it involves every state.  There should be clear guidelines and standards for state DOTs in deployment of devices and RSEs.
• With regard to V2I, the infrastructure already exists in the form of Bluetooth, WiFi and others. This should be taken advantage of.
• Infrastructure deployment should be evaluated at a practical and real-world level. AASHTO is in the process of developing actual deployment scenarios.

Questions & Answers

• It’s curious that on NHTSA decision V2I seems to be incorporated, but NHTSA decision seems to be premised on zero infrastructure.
  • NHTSA has separated V2V from V2I but it is recognized that some infrastructure must be necessary for security.
• Some of the standards for signal controllers, i.e. NTCIP standards J2735 are already there.  How the RSE massages the info it has into the necessary message set could and should be standardized.  What’s important is what’s going out over the air.  Shouldn’t J2735 cover most of this?
  • (Response from Audience): Those standards are for message sets; there’s no standard for the applications.  The roadside device could be the traffic signal- they have the computing power.
• Will you be doing an independent evaluation of the limited deployments?
  •  No investments at this stage; we will have to look at how deployments work.

Rules of Operation and Standards

Key Comments

• Standards represent a critical area. There is an existing body of knowledge on standards, which should be leveraged. Standards could be a separate policy area instead of being coupled with rules of operation.
• The term, “rule” can have different interpretations and should be carefully defined. One suggestion would be to use the term “operating procedures” instead. The terminology presented should be explicitly defined and carefully presented, especially in this area.

Questions & Answers

• Good standards always lower costs.  I get the impression that we intend to develop standards and then harmonize them.  Can I suggest that this is backwards, and that it’s more difficult to harmonize standards later?  I really think that standards are so important that they ought to have their own section where they are considered separately and thoroughly.
  • It may read that way, but we certainly recognized that going forward we should look for harmonization as early as possible.  We also recognize that to some extent the horse has already left the barn and we ought to at least see what can rationally be down to harmonize standards.  We’re not suggesting that we leave harmonization to the very end.
• What standards you’re dealing with here are minimum uptime, operation or how you actually install this stuff.
  •  This area is emerging—we need your help to identify the standards that make sense.

Spectrum Analysis and FCC Role

Key Comments

• A spectrum working group has been developed for this program. The current allocation does not allow for a spectrum manager. As a result, we need to evaluate whether a spectrum manager is needed.
• There are regions in this country where 5.9 GHz safety capability may not operate satisfactorily. When the spectrum was allocated, this was not as clearly understood.
• It may not be necessary to have a spectrum manager as an ongoing role, although there will be a need for spectrum management during initial device deployment.  A major role is to deal with interference mitigation.  Something of an interim coordinator role might be appropriate. It is not clear whether we can recommend an ongoing role, but we could have a role as a safety net for initial deployment.

Questions & Answers

• No questions.

Governance Structure &Authority

Key Comments

• It is unclear how you can provide governance using standards. This concept should be more explicit.
• One suggestion is to use the certification process as a form of governance. If you are not certified (equipment, etc.) then you are not allowed to participate in the a connected vehicle system.

Questions & Answers

• My sense is that we’re looking at a system and the governance of those two items in that you may require operational guidance, legislation and other aspects rather than standards.  For devices and components and interfaces, form fit, standards clearly apply.  I’m trying to separate where standards apply vs. where they fit into a governance structure.
  •  That’s some of the work we need to do.  We also need to have a concept of operations on the table.
• Could you say more about your thinking regarding bottom up governance formation?
  •  We’re not forming any structures, and I think we need to look at what needs to be governed before giving any guidance.

Additional Participant Comments

• The issue of liability needs greater evaluation.
• Greater practicality and using more real-world examples can assist in addressing these issues. Many of the roadmap charts are abstract.
• The first two issue areas of the policy roadmap (Certification and CA Security) are the key building blocks for other elements to fall into place. Other issues are driven by these two activities.
• Stakeholders are looking for a commitment to deployment, especially for V2I Safety. The sooner that this is clear, the more tangible this becomes.