U.S. Department of Transportation
Research and Innovative Technology Administration
ITS Joint Program Office

IntelliDrive^SM Governance Needs Summary

Introduction

The concept of governance has long been recognized as a critical component of the eventual success of IntelliDrive^SM. Almost since the inception of the Vehicle-Infrastructure Integration (VII) research initiative (the predecessor program to the IntelliDrive^SM Program), the issue of governance has been a central theme in anticipation of the policy requirements that need to be resolved and in place to support successful deployment and operations. Between 2005-2009, the issue has been discussed, researched, and described in a variety of ways.

Nearly five years of investigation have led to a large body of knowledge that totals over one thousand pages. However, the majority of this body of knowledge addresses governance from the perspective of the VII visions — a system that was to be deployed, operated, and maintained based on a specific architecture and specific set of technologies. Since 2008 and the rebranding of the VII initiative into the IntelliDrive^SM Program, this vision has expanded to incorporate a more open architecture and broader set of technologies. The textbox below provides a short summary of the differences and commonalities between VII and IntelliDrive^SM.

What’s Changed

What Remains the Same

DSRC only Technology options OEM production units only Aftermarket and retrofit considered Light vehicle focus All vehicle types Prototyping/proof of concept Focus towards deployment Limited stakeholders Broader stakeholder engagement Limited visibility by "outsiders" Greater program transparency US focus International harmonization Loosely coupled programs Strong, collective USDOT support, coordination, and leadership

Connectivity → V2V and V2I National level interoperability – Open standards for communications and data DSRC for safety Safety, mobility, and convenience applications Must not compromise on safety or security Must protect privacy Continued close collaboration among USDOT, AASHTO/local agencies, and vehicle manufacturers

This white paper provides a summary of the body of knowledge developed for VII governance; provides a high level synthesis of what can be learned from past documents and how this information provides a foundation for moving forward; and the identification of a set of proposed next research steps needed to develop a set of viable governance options for IntelliDrive^SM. This white paper is divided into five sections as follows:

1. Definitions: A set of definitions that generically describe governance.
2. Summary: A summary of the materials on VII governance options developed between 2005-2009.
3. Synthesis: A synthesis on the body of knowledge.
4. Gaps/Missing or Unknown Information: A list of items that need consideration in addition to the information provided by past documents.
5. Next Steps: A set of proposed next steps.

I. Definition of Governance

According to the United Nations, the concept of governance is gaining increased attention around the world as citizens and stakeholders desire a greater understand of how authority is granted and is used by institutions. The UN provides a political definition of governance and notes that it is:

…the process of decision-making and the process by which decisions are implemented (or not implemented). Governance can be used in several contexts such as corporate governance, international governance, national governance, and local governance. Since governance is the process of decision-making and the process by which decisions are implemented, an analysis of governance focuses on the formal and informal actors involved in decision-making and [implementation]…and the formal and informal structures that have been set in place to arrive at and implement the decision. ¹

The Worldwide Governance Indicators project of the World Bank defines governance as:

The traditions and institutions by which authority…is exercised. This considers the process by which governments are selected, monitored and replaced; the capacity of the government to effectively formulate and implement sound policies; and the respect of citizens and the state of the institutions that govern economic and social interactions among them.²

An alternate definition sees governance as:

…the use of institutions, structures of authority and even collaboration to allocate resources and coordinate or control activity in society or the economy. ³

According to the United Nations Development Programme's Regional Project on Local Governance for Latin America:

Governance has been defined as the rules of [a] system to solve conflicts between actors and adopt decision (legality). It has also been used to describe the "proper functioning of institutions and their acceptance by the public" (legitimacy). And it has been used to invoke the efficacy of government and the achievement of consensus by democratic means (participation).⁴

A final definition, found on Wikipedia and noted throughout many articles on governance and political philosophy, notes the difference between politics and governance:

Politics involves processes by which a group of people with initially divergent opinions or interests reach collective decisions generally regarded as binding on the group, and enforced as common policy. Governance, on the other hand, conveys the administrative and process-oriented elements of governing rather than its antagonistic ones. Such an argument continues to assume the possibility of the traditional separation between "politics" and "administration". Contemporary governance practice and theory sometimes questions this distinction, premising that both "governance" and "politics" involve aspects of power. In general terms, governance occurs in three broad ways:

1. Through networks involving public-private partnerships (PPP) or with the collaboration of community organizations.
2. Through the use of market mechanisms whereby market principles of competition serve to allocate resources while operating under government regulation.
3. Through top-down methods that primarily involve governments and the state bureaucracy.⁵

As governance theory has been applied throughout society, narrower areas of governance have emerged to provide more specific definitions and performance metrics for institutions and organizations. In some cases, governance has been established through standards. By codifying governance within standards, the parties to governance have identified best practices for determining hierarchy and levels of system governance, management parameters, accountability, compliance, performance metrics, market involvement, and other elements. The most notable of these areas is information technology governance for which the industry has produced a working standard—ISO 38500—that defines governance as a focus on the stewardship of resources on behalf of the stakeholders who expect a return from their investment while also accounting for the management of risk and assurance of compliance.⁶ The IT Governance Institute takes this definition further to delineate the processes that address enterprise governance versus governance of the IT system, and to highlight their relationship to one another:

Effective and timely measures aimed at addressing…top management concerns need to be promoted by the governance layer of an enterprise. Hence, boards and executive management need to extend governance…to IT by way of an effective IT governance framework that addresses strategic alignment, performance measurement, risk management, value delivery and resource management….IT governance is an integral part of enterprise governance and consists of the leadership and organizational structures and processes that ensure that the organization's IT sustains and extends the organization's strategies and objectives. An IT governance framework, such as Control Objectives for Information and related Technology (COBIT) can be a critical element in ensuring proper control and governance over information and the systems that create, store, manipulate and retrieve it. The IT Governance Institute takes this definition further to delineate the processes that address enterprise governance versus governance of the IT system, and to highlight their relationship to one another:⁷

These definitions are provided as a means of developing a common understanding of the concept of governance. With further analysis and input from experts in the field of governance, the definitions will be used to guide:

• The identification of the types of governance that is relevant for IntelliDrive^SM.
• The identification of the aspects of the IntelliDrive^SM system that will require governance (what they are, what level of governance is needed, and with what functions).
• The identification of the types of outcomes and deliverables that will ultimately form the basis for IntelliDrive^SM governance:
  • A framework that defines the requirements for how the system is governed (by whom), how authority is granted (legislated? Voluntary? Some combination?), and how decision making processes occur – a framework akin to enterprise governance.
  • A framework that defines system governance, in particular with regard to:
    • Standards development
    • Development of rules and standard operating and maintenance procedures that ensure consistency across jurisdictional boundaries
    • Enforcement procedures
    • Certification procedures
    • User authentication and access procedures, and rules for removing a user from the system
    • Processes for solving conflict among stakeholders
    • Processes for setting and measuring progress toward performance standards
    • Processes for identifying and addressing the evolution of technology and incorporation into IntelliDrive^SM.
  • A framework that identifies an appropriate hierarchy of access and controls.
  • An analysis of the alignment between enterprise requirements, government requirements for safety, and market opportunities.

II. Summary of the Existing Body of Knowledge

The body of knowledge previously developed for VII between 2004 and2009, identifies governance issues and concerns within the context of technical and institutional issues and business models. Over 20 related documents and countless notes from relevant meetings offer in-depth discussions and insights into the previous discussions and research on governance for VII.⁸ These documents are listed in Appendix A.

Although many of these reports are technical in nature, they conclude that governance, institutional issues, and business models must be resolved before the technical components can become operational. Additionally, an important theme running throughout these documents is the notion that governance, institutional issues, and financing and business models are tightly entwined, at times leading to chicken-and-egg type situations in which the ability to concretely define or recommend action in one area is dependent upon the need to provide better definition in another area. To an extent, entanglement of these issues appeared to present an obstacle to the development of governance options or recommendations within these documents. These documents are listed in Appendix A.

In summary, the VII documents provided:

• General recommendations to conduct further research and analysis (see Appendix B for a synthesized list of proposed questions to guide further work). Common topics for further research included:
  • Public sector leveraging capabilities through policies, regulations, and funding.
  • Device certification
  • Standards and their opportunities and limitations
  • System architecture and access controls
  • System requirements
• Recommendations on proposed roles and responsibilities of public and private stakeholders, and some of the conflicts that exist among the different perspectives offered.
• Identification of what industry aspect of VII might lead market development (safety, security, mobility, or tolling).
• A review of baseline VII assumptions that would be necessary for a more detailed examination of governance and business models, and attempted to structure a means for developing consensus among stakeholder on these assumptions (see list in Appendix C).
• The identification and examination of a range of business models that were developed as a means of assessing the viability for various forms of financing VII or for how private sector market opportunities and investments could be leveraged against the public sector investment. In general, the past documents concluded that any combination of the model structures may be appropriate. These model structures are pulled from a number of documents and identified in Appendix D.
• An examination of what should be the appropriate level of security. Specifically, documents referenced and compared the security and stability of the system against the approaches taken by the telecommunications and information services industries—industries characterized by aggressive competition among competing systems, dynamic technology, volatile business entities, and continuous evolution and rollout of new systems and services.
  

Lastly, in spring 2008 in Detroit, Michigan, the VII Program conducted a set of proof-of-concept (POC) tests to examine system performance under the challenges of a real-world environment. The results are posted on the IntelliDrive^SM website⁹ and were included in the summary of documents. For the most part, governance issues did not arise much during the POC tests. To the extent that they did, Appendix E summarizes the issues that were captured in the POC test results documents.

III. Synthesis

Examination of these past research and discussion documents leaves the reader with the conclusion that there are still a great deal of decisions necessary to move forward toward an agreed upon governance structure. The review also indicates that there is a great deal of overlap of governance with institutional issues, finance, and business models—it is a complex undertaking to fully separate activities, impacts, decisions, and resolution.

In moving forward to restructure this research under the IntelliDrive^SM Program’s Policy and Institutional Issues track, the previous work offers the following foundation:

• A list of robust questions that are still relevant to IntelliDrive^SM and that need to be answered and resolved for successful deployment.
• A foundation for understanding the range of the types of governance models and some insight into governance models that exist in other industries and that may offer lessons learned for IntelliDrive^SM.
• Insights into how to segregate governance issues from institutional and business/market issues in order to develop recommendations that are more specific to the elements of governance needed for IntelliDrive^SM. The table on the following page offers a first attempt to segregate these elements in order to lead to a more focused methodology for developing governance options and recommendations (see section V. Next Steps).
  

IV. Gaps/Missing or Unknown Information

While the VII (and more recent IntelliDrive^SM) documents provide a wide range of governance options and enough insights to allow for the segregation of the governance/institutional/business elements, they also highlight what is not known and still needs to be resolved before the governance and business models can be reduced in number and more detailed. The following are considered gaps, or missing or unknown information:

• The VII Focus. The governance concepts presented in the previous documents are predominantly focused on the VII model of deployment. While it is useful to have a well-described deployment scenario to determine governance issues and options, the VII model has changed in substantial and important ways. These shifts need to be more fully considered in moving forward to develop IntelliDrive^SM governance options.
• IntelliDrive^SM Deployment Scenarios. To conduct directed and outcome-based research on governance options for IntelliDrive^SM, deployment scenarios that identify the technical configuration(s) of IntelliDrive^SM will need to be developed and used as the basis for identifying what needs to be governed. Without this level of specificity, the proposed research will result in the same outcome as previous research—no clear options can be recommended without understand what IntelliDrive^SM will be.
• Time Frame. The IntelliDrive^SM launch was initially envisioned as “big-bang” a nationwide rollout; however, further discussions among key players have raised differences of opinions regarding the deployment time frames. A number of potential stakeholders have characterized the IntelliDrive^SM deployment as an evolutionary process whereby applications will be developed and deployed, and that various stakeholders will be more fully integrated into the IntelliDrive^SM Program as time progresses and technology evolves. Phased deployment will mean that some stakeholders are involved with the operations and maintenance functions earlier than other stakeholders, indicating that the early operators may have a greater governance role during the early deployment phases and thus may help provide better definition to the definitions of the governance functions.
• Funding / Financing Opportunities. Funding sources for capital, operations, and maintenance of the IntelliDrive^SM systems has not been identified. Different sources are likely to result in scenarios under which different agencies or entities assume the management and administrative responsibilities.
• The Complexity of IntelliDrive^SM Applications Interactions. A systems engineering task is scheduled to update and ensure that the IntelliDrive^SM Concept of Operations addresses the new complexities introduced by (a) the concept of phased deployment and how new applications will either build from or integrate with existing applications, and identify some of the conflicts that may arise (for instance, in message prioritization), and (b) the new taxonomy levels of IntelliDrive^SM that recognize a roll for aftermarket and retrofit technologies that may or may not require the same level of access, security, certification, or user authentication as the technologies identified for active safety.

These gaps and unknown pieces of information are listed as a means of acknowledging that as these issues get worked out, they may or may not have a significant impact on the development of governance options. The efforts that will be taken to address the issues on this list above (and others, should they be identified by stakeholders) will be closely coordinated with the efforts to develop governance options.

V. Next Steps

The IntelliDrive^SM Policy and Institutional Issues Plan and Roadmap offers a five-track structure for addressing the major policy and social issues. The Plan and Roadmap were developed using many of these previous documents summarized in this white paper and incorporated many of the same questions that are listed in Appendix B.¹⁰

Track 1 offers an approach for developing a set of high level deployment scenarios that, in essence, define what an IntelliDrive^SM system could look like. Track 1 efforts are expected to deliver a set of scenarios. Track 3 specifically focuses on developing governance options; the efforts of Track 3 will be closely coordinated with the efforts in Track 2 to develop options for financing and analyze market issues; and Track 4 efforts that will analyze and recommend options for resolving institutional issues.

There are three approaches that are proposed for development of governance requirements:

• V.1. Engage stakeholders on governance requirements.
  • Using the questions listed in Appendix B, engage stakeholders on concerns and lessons learned from previous experiences
• V.2. Review other industries for lessons learned and models that can apply to IntelliDrive^SM governance:
  • Review of ISO-38500 for a framework and options that may apply to IntelliDrive^SM.
  • Research into other industries that meet the following criteria:
    • Significant use of communications technologies, and governance through standards, security, authentication, certification, and access procedures;
    • Have a need to track and incorporate evolving technologies;
    • Have a strong private sector interest and a dynamic and sustainable marketplace
    • Have a highly diverse set of stakeholders and perspectives.
• V.3. Use the deployment scenarios developed through Track 1 to develop governance requirements, accounting for the inputs and lessons learned gained from the first two approaches above:
  • Analyze by technical requirements, analyze by taxonomy (IntelliDrive^SM levels 1 and 2), and analyze by applications to identify:
    • What parts of the system need to be governed?
    • Who will govern and how will the system be governed?
    • What are the most effective governance procedures that provide a balance among safety, operations, interoperability and open platform, and market sustainability and penetration requirements?
    • What is publicly acceptable?

Once governance requirements are developed, further work will be needed to more fully develop a set of viable, implementable options for IntelliDrive^SM governance with enough detail to allow for stakeholder review and comment. Assuming that stakeholders agree on some elements that are common across the options, further work can proceed and tap experts for the development of templates for procedural, rule-based, and guidance documents that will be needed in support of implementing IntelliDrive^SM governance.

The following timeline identifies a series of steps that launch initial efforts under V.1 and V.2 above:

• October 2009: Vet concepts within this white paper at an IntelliDrive^SM Working Group meeting in Detroit, Michigan from October 28-30, 2009. Present on the questions, ideas, and ways to segregate the elements of governance from the other institutional and business/market issues.
• November 2009: Modify this white paper and present to stakeholders for comment through a posting to the IntelliDrive^SM website.
• November 2009 – February 2010: Working closely with the technical IntelliDrive^SM team and stakeholders, develop a high level framework(s) for IntelliDrive^SM governance and begin to tailor the generic governance concepts for IntelliDrive^SM.
• November 2009 – February 2010: Examine other industries and their governance frameworks in a broad way and select those that appear relevant for further examination (using the criteria described above in V.2.)
• November 2009 – February 2010: Continue engagement with stakeholders to explore issues of concerns and ideas associated with governance. Develop a publicly available document that summarizes the overall themes, ideas, and concerns.
• February 2010: Hold a stakeholder workshop to gain feedback and input on initial deployment scenarios and the likely direction of governance frameworks.
• May 2010: Stakeholder workshop to review and discuss draft frameworks (most likely in concert with the ITS America Annual Meeting in Houston, Texas).
• May 2010-2011: Use deployment scenarios to engage experts and more fully develop governance options for IntelliDrive^SM and identify the foundational requirements (documents) for IntelliDrive^SM entities; procedures; rules of use, operations, and enforcement; and guidance.
• May 2010 – 2011: Engage experts on providing the appropriate legal, policy, and societal details for the governance options and for the development of rules of use, operations, and enforcement. Analyze options for viability of implementation and impact on market opportunities.

Appendix A: Reference Information for IntelliDrive^SM and VII Documents Reviewed for Governance

IntelliDrive^SM Policy and Institutional Issues - Research Plan (Version 7) - August 18, 2009 Draft

To achieve effective deployment of IntelliDrive^SM, this plan identifies how new policy and, potentially, regulatory requirements will be needed to establish the institutional foundations, catalyze deployment and markets, and manage risks. This plan is describes the research and analysis needed to develop options and how key partners and industry will contribute to the development of actions and recommendations that will move the IntelliDrive^SM research and deployment forward.

Public Sector Powers and Abilities to Support Implementation of IntelliDrive^SM - Prepared by: Cambridge Systematics, Inc. with PB Consult; Prepared for: ITS Joint Program Office, RITA, USDOT - April 23, 2009

The focus of this paper is on the general range of actions that the Federal government can take to encourage implementation of IntelliDrive^SM. The paper starts by articulating the primary goals of IntelliDrive^SM from a public sector perspective. It then identifies the types of leverage available to the public sector at the Federal, state, and local level to encourage IntelliDrive^SM implementation, including policy, regulation, and funding. Specific action items are identified within each category.

Marketing and Outreach Plan - IntelliDrive^SM - Prepared by: Manifest Inc. with SAIC; Prepared for: ITS Joint Program Office, RITA, USDOT - February 23, 2009 Draft

The overall objective of this Plan is to develop tools and processes for more focused, effective, and coordinated IntelliDrive^SM marketing and outreach. Because IntelliDrive^SM includes SafeTrip-21, this Plan proposes ongoing mechanisms for coordinating outreach and messaging for SafeTrip-21 with the rest of the IntelliDrive^SM program.

IntelliDrive^SM Principles (Strawman) – Prepared for ITS Joint Program Office, RITA, USDOT - February 19, 2009

These principles were developed to provide a common set of principles about the IntelliDrive^SM Program that could be agreed upon by the ITS Joint Program Office, RITA, USDOT, and key IntelliDrive^SM stakeholders. The ITS JPO presented these principles publicly during the ITS America Annual meeting June 1-3, 2009 in the Washington, DC metropolitan region. The ITS JPO provides the list of IntelliDrive^SM principles within this paper as a strawman to begin discussions. The principles listed are not endorsed by USDOT, but are intended to be examined and modified by stakeholders.

Anonymity and IntelliDrive^SM: Pre-Decisional Discussion Document – Prepared by: Noblis (Contract #: DTFH61-05-D-00002); Prepared for ITS Joint Program Office, RITA, USDOT - February 2009

The purpose of this paper is to provide information for a discussion among the major IntelliDrive^SM stakeholders regarding whether or not the current anonymity by design approach should be maintained as a program requirement or modified in a way that still retains the key privacy principles. This paper defines the implications of anonymity by design requirements on the IntelliDrive^SM requirements and system architecture.

5.9GHz DSRC Device Certification Program - Recommendations on Program Structure (Task #2 of Agreement DTFH61-06-H-00026) - Prepared by: OmniAir; Prepared for: ITS Joint Program Office, RITA, USDOT - January 2009.

This document provides recommendations on the structure of a certification scheme to test radio device compliance to 5.9GHz DSRC standards and requirements. The report combines policy, practice, institutional and the technical elements as all impact conformity assessment.

Vehicle Infrastructure Integration (VII) Concept Of Operations – Prepared by: Booz Allen Hamilton; Prepared for: Federal Highway Administration - September 2006

The purpose of this document is to provide a basis for the planning, design, implementation and operation of the national VII system. The Concept of Operations (ConOps) is the first step in the systems engineering process. The ConOps summarizes the need for VII and outlines the goals and objectives of the program. It defines VII on a conceptual level, lists the functions to be performed by the envisioned system, and identifies the roles and responsibilities of the project stakeholders in the operation of the system.

VII Operations Oversight Entity Workshop – June 19, 2006 Revision

This working document was used as the basis for a Workshop to explore the relevant institutional precedents for the establishment of a Public-Private business “entity” that would operate and manage a nationwide communications infrastructure as a key component of a new VII system. The VII concept, as defined at that time, was proposing a fundamentally new set of relationships among the key components of highway transportation: the vehicles, the driver/owner, the vehicle manufacturer, the road infrastructure, and public and private road-related service providers. The proposed workshop was envisioned as an opportunity to elicit key stakeholder inputs.

VII Applications Access Control Issues - June 14, 2006

Different issues are presented in this paper, but within the scope of access policy. The report defines the essence of VII as it supports public objectives (safety and mobility) and commercial objectives (brand differentiation and revenues, etc.) -- recognizing that a robust mix of the two is essential to the viability of a VII program.

Vehicle Infrastructure Integration: Access (Data/Driver/Vehicle) Issues – Date: 2006

This brief paper identifies the potential access issues that the Institutional Issues Working Group has identified. These were previously identified in the VII Institutional and Policy Issues paper. The purpose of this paper is to set forth the access issues for discussion with the VII Working Group and recommend an approach to address these issues.

Vehicle Infrastructure Integration - Liability Issues – Date: 2006

This brief paper identifies the potential liability risks that the Institutional Issues Subcommittee has identified. These were derived from the VII Institutional and Policy Issues paper. The purpose of this paper is to identify the potential VII liability risks for discussion with the VII Working Group and recommend an approach to address these risks.

Public-Private Agreements/Arrangements Associated With VII Implementation – Prepared by: Stephen Lockwood, PB Consult - August 15, 2005

This paper represents the first attempt to identify the wide range of issues associated with the unique public private partnership and nationwide systems installation implied by VII. Recognizing the lack of precedent and the program scope, a set of key issues have been set forth which are central to success of the proposed endeavor.
purposes, etc.]

Vehicle Infrastructure Integration (VII): A Discussion Of Potential Implementation Approaches (Revised as a result of Working Group Meeting on September 30 and October 1, 2004) - Prepared By: ITS Joint Program Office, US Department Of Transportation - October 26, 2004

As a result of the working group meeting on the above dates, the options to be considered for the implementation of VII were altered substantially. This paper is responding to the request that the options under consideration be more clearly defined and that the differences be explained more thoroughly.

Basic Assumptions with Implications Regarding Institutional Arrangements for VII Deployment, Governance and Business Models (Preliminary DRAFT V-5) - Date: Unknown

This memo is a working document that was expected to be revised over time. Its purpose is to establish baseline assumptions that will serve as the point of departure for more detailed examination of governance and business model issues. In particular, this memo represents initial thinking regarding “what we need to know/assume” in describing the institutional capacities required and the range of reasonable options for evaluation.

VIIC's Final Report

This report summarizes a program of work resulting from a Cooperative Agreement # DTFH61-05-H-00003 between the United States Department of Transportation (USDOT) and the Vehicle Infrastructure Integration Consortium (VIIC) to develop and test a Proof of Concept (POC) Vehicle Infrastructure Integration (VII) system, based on Dedicated Short Range Communications (DSRC), a wireless communication between an infrastructure and mobile terminals. It supports applications for improvement in safety, mobility and enables other commercial applications. Key findings and recommendations for further work are presented.

Final Report: Vehicle Infrastructure Integration Proof of Concept Executive Summary – Vehicle

This report provides an overview of the program goals and objectives, program organization, program technical direction and key findings and recommendations. It does not detail test results (See Volumes 3a, 4a and 5a for test result details) and is recommended for executives and managers of organizations concerned with the deployment of VII systems.

The remaining four volumes are:

Volume 2a – Final Report: VII Proof of Concept Technical Description – Vehicle

This volume describes the technical approach of the program and specifically describes the system architecture, the system component design and the sample applications designed to enable some of the system testing. In addition, the deployment of the system to the test track and Development Test Environment (DTE) is described. This report is recommended for engineering managers and practicing engineers concerned with the deployment of VII systems.

Volume 3a – Final Report: VII Proof of Concept Results and Findings Summary – Vehicle

This volume describes the test objectives and approach and presents a summary of results and findings for both the system and application testing. Detailed results are not presented. This report is recommended for engineering managers and engineers concerned with the deployment of VII systems. It assumes the reader has knowledge of the system architecture as described in Volume 2a.

Volume 4a – Final Report: VII Proof of Concept System Detailed Test Results – Vehicle

This volume describes the system test objectives, the system test approach and details the results of the individual components and the end-to-end system tests. This report is recommended for engineers concerned with the deployment of VII systems. It assumes the reader has knowledge of the system architecture and components as described in Volume 2a.

Volume 5a – Final Report: VII Proof of Concept Applications Detailed Test Results –Vehicle

This volume describes application test objectives, the application test approach and details the results of the individual application tests. This report is recommended for engineers concerned with the deployment of VII systems and the design of VII applications. It assumes the reader has knowledge of the system architecture and applications as described in Volume 2a.

Appendix B: IntelliDrive^SM and VII Questions

A number of VII and IntelliDrive^SM governance and related questions arise from what has already been documented by the stakeholders.

1. Who are parties involved?
2. What part of system needs to be governed?
3. Who will decide or control access into the system – by OEMs, vendors, public entities, consumers (market)?
4. Determination of roles and responsibilities for each stakeholder will help direct to appropriate business model. What responsibilities can only be dedicated to the public sector? Any responsibilities dedicated to a specific government entity or level? What responsibilities can only be dedicated to the private sector?
5. Who determines what regulations, guidance and legislation are needed? Who develops these?
6. Who will take the lead positions during system development? System deployment? VII operations (including maintenance and overall management)?
7. What is the hierarchy in oversight functions?
8. Clear definition of roles between the Federal government and States is critical and probably need to be standardized across the U.S.
9. Need a delineation of roles of various parties regarding deployment or provision of each of the three key elements – RSU network, cache, data.
10. What are the public and private sector roles and responsibilities for each deployment scenario?
11. How are other organizations that are not primary stakeholders impacted? What role might they potentially play? Are there any synergies?
12. Given a governing entity composed of multiple representatives designed to ensure that stakeholder interests are taken into account, which public and private stakeholders should be selected for direct representation in the governing entity?
13. Which (if any) existing governance model might be appropriate (in whole, in part, or in combination) for VII?
14. Which governance model is more likely to result in the fairest balance among stakeholders’ interests and between them and the public good?
15. In what ways and to what extent do decisions regarding the composition of the governing entity and the finance model chosen for VII influence each other (i.e., does one tend to drive the other)?
16. What governance structure is most efficient and sustainable for each deployment scenario?
17. What legislation is necessary to establish authority? For whom? To do what?
18. Who has access to the system? Under what conditions and what costs?
19. What is the process for standards development, maintenance, and upgrade?
20. Who will do compliance and enforcement (for security, certification, etc.)?
21. What are associated funding strategies or revenue streams that will sustain the management of the proposed governance structure?
22. What role does regulation play? What should be regulated under each governance scenario? What are the reasons for regulation under each governance scenario?
23. A contract-like approach to a Public-Private Partnership for the VII program appears to be without precedent, but the limits regarding the form of agreement needs to be further explored.
24. Mutual assurances between the auto industry and the transportation infrastructure community (federal, state and local governments) that each will provide its respective component of the overall system that in turn justifies their respective investments AND that common national standards will be met.
25. Any formal commitment has to have sufficient legal standing to support the assurances by each party.
26. Appropriateness (or inappropriateness) of assigning stewardship of public resources to private entities.
27. Co-mingling of federal and private funds or joint governance will require specific federal enabling legislation.
28. A new form of formal and permanent cooperative oversight mechanism is needed to ensure the consistency and sustainability of mission-critical systems, continued technical evolution and ongoing operational coordination.
29. Which PPP option offers the most effective and efficient level of public and private stakeholder roles and responsibilities?
30. What are the relative benefits of public versus private ownership and financing of the VII program?

Appendix C: Synthesized list of IntelliDrive^SM and VII Assumptions Needing Consensus as a Foundation for further Research and Analysis

A number of VII IntelliDrive^SM deployment scenarios are offered throughout the summarized VII documents. While the deployment scenarios appear similar, the participants, roles and responsibilities, and the governance structure often differed among each scenario. They were provided as a means to identify and better specific the appropriate and effective parameters of any VII governance structure:

• A long term commitment (decades rather than years) to maintain the viability of VII must be made in advance of deployment. VII only functions if both the necessary vehicle and infrastructure components and supporting elements are maintained in a cooperative fashion.
• A coordinated, schedule-certain roll out of both instrumented vehicles and infrastructure is required a critical mass of equipped vehicles to justify the infrastructure investment and a critical mass of installed infrastructure to enable the VII functions. The initial “footprint” will identify the minimum necessary to fulfill these requirements.
• To support the major investments in in-vehicle equipment and fleet turnover-related expected lifespan, long-term stability and interoperability must be built into the system and institutional arrangements.
• Roadside equipment (RSE) deployment and operations would ultimately be nationwide.
• The deployment would take place in a discrete and pre-specified time frame.
• The implementation approach presumes near-simultaneous rollout of new vehicles equipped with on-board DSRC units and dedicated high speed data communications to roadside units tied into a nationwide communications network. The need for coordinated national rollout and the high degree of reliability and security required is unprecedented.
• Deployment of the landside backhaul infrastructure will be managed to take place in a relatively short time period.
• The sequence of availability of VII services will be important to public benefits, customer interest and business results.
• The overall approach to RSE deployment and network service provision must be designed for minimal burdens on state and local governments.
• The deployment approach will utilize the local deployment conventions of the utility industry regarding access, construction, oversight, etc.
• A streamlined approach, including an innovative streamlined deployment permitting process, is required for installation of RSUs and traffic signal controller integration among multiple state and local governments. Streamlined approaches must be organized for both state and local government
• The core VII services are presumed to be based on DSRC communications between a public backhaul network (with government and OEM access) via public roadside RSUs with a custom tailored OEM-provided vehicle OBE.
• There may be possible arrangements through which third parties may utilize VII components (public RSUs or OEM-supplied OBE) outside of the VII program.

Appendix D: Range of Business Models proposed for IntelliDrive^SM and VII

In general, the previous documents coalesced around a business model approach that assumed a “national” approach – or at least strong central coordination – following the precedent of the creation of the Interstate Highway. The existing and potential array of primary and general stakeholders offers a considerable spectrum of business model choices that vary in terms of their direct representation of public vs. private interests, the conventional political comfort with the models, and the likely complexity of congressional legislative challenges. At one end of the business model spectrum for VII was a public sector approach, such as a federal agency charged by Congress with implementing and administering a national VII system. The other end offered a model of a federally-authorized and regulated, private, non-profit entity that could represent key private stakeholders, such as ARINC did for the airline industry in its early years as a provider of air traffic communication. Between these end points of the spectrum are a variety of public-private options with joint ownership and governance for which several precedents exist, such as Amtrak, Comsat, and others. It was further noted that under the VII program, multiple value-added transaction activities were likely and that some of these may evolve as pure business relationships by contract, while others could only be enabled by broader cooperative agreements at the industry-government and government-to-government level. The existing variations of potential VII business models included:

FEDERAL ESTABLISHMENT & OVERSIGHT -

• “No Entity”, which implies drawing upon a combination of existing programs, regulations and standards, such as the Federal-Aid Highway Program.
• Federal Administration Agency / Federal Operating Agency: FAA ATC, FCC
• Federal Government Corporation (FGC) or enterprise, which can have different mixes of public and private ownership.
  • Wholly-Owned Federal Government Corporation (FGC) / Congressional established: SLSC
  • Regulated private stakeholder-owned monopoly corporation, which would be a utility created primarily by state legislation, such as TVA.
  • Mixed Public-Private Federal Government Corporation (FGC) / Congressional established Mixed ownership: FDIC, AMTRAK

FEDERAL DESIGNATION OF PRIVATE ENTITY -

• Congressionally-established Private, Non-Profit FGC (monopoly-like scope monopoly national concession, which would be designated by federal government.): NAV Canada; COMSAT
• Federal agency management plus one or more private sole-source contractors designated to operate the infrastructure and network
• Federally-Designated Sole Source, Non-Profit Contractor: ICANN
• Federally-Designated Sole-Source Stakeholder-Owned Non-Profit: ARINC

PRIVATE PARTNERSHIPS OR INDEPENDENT PRIVATE ENTITY -

• Existing forms of federal agency operating entities such as FAA’s Air Traffic Organization – where private corporate interests cannot be represented directly
• Federally owned privately operating entities established for production (GOCOs). Examples include federal labs and production facilities.
• Research partnerships such as Cooperative Agreements, CRADAs, “Other transactions” or FFRDCs
• Public-Private Partnership
• Private stakeholder-created and owned corporation (private for profit enterprise), operating within external general context regulation.

Documents also suggested topics to guide further business model research, which also include aspects of governance:

1. Need for a legally-established national institution – or its equivalent – to stabilize service provision commitments (including handling of non-participants)
2. General pros and cons of a private/ Non-Profit Corporation vs. government-established entity
3. Dependence/independence on legislation to establish entity and potential for delay and diversion (such as appointment of directors, ownership, legal status)
4. Mechanism for representing collective interests, such as OEMs, States
5. Issues flowing from legal status and mode of establishment that might impact staffing and contracting (conditions of employment, ability to contract for services)
6. Experience with representing/accommodating public and private interest through either ownership or director representation, including risks and related issues
7. Issues associated with assessing fee on public and private users of network services
8. Target and forms of regulation to which an entity might be subject
9. Anti-trust and immunity issues as they might impact choice of entity
10. Mechanism for representing collective interests, such as OEMs, States
11. Ability to accommodate third party service providers (other than motor vehicle manufacturers) representation directly or indirectly in policy and/or governance
12. Basic organizational structure (appointed board, power of appointment, retention of management, level and focus of staffing vs. contracting)

Appendix E: VII Governance Issues Identified from POC Test Results

A series of POC evaluative reports were produced in 2009. These reports are posted on the IntelliDrive^SM website (http://www.intellidriveusa.org/library/rept-dsrc-poc.php.). The following two reports were the only documents from the POC test results that addressed any aspects of governance.

1. Final Report: Vehicle Infrastructure Integration Proof of Concept Executive Summary ─ Vehicle VII Consortium. May 2009. FHWA-JPO-09-003.

The Vehicle Infrastructure Integration Consortium (VIIC) developed and tested a Proof of Concept (POC) Vehicle Infrastructure Integration (VII) system that was based on Dedicated Short Range Communications (DSRC), a wireless communication between an infrastructure and mobile terminal. The POC final report, which is organized into five volumes, outlines the program goals and objectives, technical direction, detailed results of the system and application tests, and recommendations. While the final report is technical nature, it highlights key governance issues that will need to be addressed before system deployment. The results of the POC final report raised the following issues that will need to be considered within the IntelliDrive^SM governance model:

1. Who will define system requirements?
   1. The POC test found that positioning functionality is required by user terminals in order to provide accurate state information, so the system requirements need to impose some basic accuracy requirements on user devices to assure that data provided to the system or to the user is valid.
   2. Functionality associated with migrating service sessions between RSEs should also be included in the system requirements as a system function, so it is implemented in a consistent way across the system.
2. Who will issue/approve security credentials?
   1. Ensuring anonymity and security is essential to IntelliDrive^SM. The system will require a Certificate Authority (CA) to issue and manage security credentials.
3. How will competing advisory messages be prioritized?
   1. When a large number of messages are sent how will the competing messages be prioritized?
4. What are the public and private sector roles and responsibilities for system operations management?
   1. The POC system found that the ILS provides an effective way to use the system, but it is very inefficient. For example, it is likely that many private network users (private service providers) will not care specifically which RSEs their services are provided from (the more the better), and it is equally likely that road management organizations will care about roads and intersections much more than about RSE identifiers. The POC test found that the system as currently configured is usable, but that simpler, more intuitive and more relevant interfaces should be available for service and data providers. Such interfaces could be left to each road authority to develop independently, but a unified system element would benefit all users.

2. Footprint Analysis for IntelliDrive^SM V2V Applications, Intersection Safety Applications, and Tolled Facilities: Pre-Decisional Discussion Document. Noblis. March 2009.

This White Paper presents “order of magnitude” estimates of the number of roadside DSRC locations (i.e. the DSRC footprint requirements) that would be required for three different deployment scenarios:

• To support only V2V safety applications.
• To support V2I intersection safety applications.
• To equip toll roads and HOT lanes.

The DSRC footprint requirements are driven by the need for secure and private communications supported by infrastructure-based systems. The White Paper identifies two options for maintaining security and privacy: (1) anonymity by design, and (2) anonymity by policy. Each option has unique implications for the IntelliDrive^SM governance model.

Anonymity by Design

Anonymity by Design means that multiple technical controls have been built into the system to ensure that a vehicle’s or person’s identity cannot be determined based on their IntelliDrive^SM data exchanges, or based on what was captured in one system’s log file. Governance issues to consider under Anonymity by Design include:

• What entity will serve as the Certification Authority (CA)?
• Issuing anonymous certificates by cell phone or WiFi technology will require that 3G cellular technology is implemented on a consistent basis, and that over-the-air security is in use by all carriers throughout the U.S.

Anonymity by Policy

Anonymity by Policy means that a user’s privacy is protected through adherence to written policies. Under Anonymity by Policy, policies, regulations, and possibly laws would be need to be put in place to limit access to personally traceable information.

Appendix F: Additional References

1. Document on etymology prepared by the European Commission at http://ec.europa.eu/governance/docs/doc5_fr.pdf.
2. World Bank, Managing Development - The Governance Dimension, 1991, Washington D.C. http://www.wds.worldbank.org/external/default/WDSContentServer/WDSP/IB/2006/03/07/ 000090341_20060307104630/Rendered/PDF/34899.pdf.
3. A Decade of Measuring the Quality of Governance.
4. Bell, Stephen, 2002. Economic Governance and Institutional Dynamics, Oxford University Press, Melbourne, Australia.
5. 'Triumph, Deficit or Contestation? Deepening the 'Deepening Democracy' Debate' Institute of Development Studies (IDS) Working Paper 264 July 2006.
6. Empter, Stefan & Josef Janning (2009): Sustainable Governance Indicators 2009 - An Introduction, in: Bertelsmann Stiftung (ed.): Sustainable Governance Indicators 2009. Policy Performance and Executive Capacity in the OECD. Gütersloh: Verlag Bertelsmann Stiftung, 2009.
7. Becht, Marco, Patrick Bolton, Ailsa Röell, "Corporate Governance and Control" (October 2002; updated August 2004). ECGI - Finance Working Paper No. 02/2002.
8. Eells, R.S.F. (1960), The Meaning of Modern Business: An Introduction to the Philosophy of Large Corporate Enterprise (Columbia University Press, NY).
9. Türke, Ralf-Eckhard: Governance - Systemic Foundation and Framework (Contributions to Management Science, Physica of Springer, September 2008).