1	IntelliDrive^SM Mobility Program Policy Roadmap Mobility Program Workshop Arlington, Virginia December 1, 2010 Valerie Briggs Suzanne Sloan U.S. DOT / Volpe National Transportation Systems Center
2	Two Approaches Top-Down: Policy Roadmap (version 8), December 2009 Major, cross-cutting policy focused on deployment Bottom-Up: Specific technical policy issues focused on supporting ongoing research and major research milestones Policy issues identified by deconstructing technical research roadmaps Example is Safety Policy Roadmap
3
4
5	Mobility Program Policy Roadmap Purpose: Outline policy and institutional issues in an organized, structured manner. Develop plan for research and analysis that results in options and recommendations in support of Mobility IntelliDrive. Research results and decision points are driven by: Acquisition of Data Sets for Phase I (static) and Phase II (real-time) (Data Set Acq.) Development of Test Data Environment(s) (Data Env.) Launch of an Open Source Portal for Software Programmers (OS Portal) Acquisition of Applications (Apps.) Launch of Federated Data Environments (Federated Env.) Organization: Key policy questions Specific research tasks Outcomes for major program milestones
6	Critical Policy Areas Identified 4 key policy issue areas in collaboration with technical team and stakeholders: Intellectual Property Rights Governance Structure and Authority Participation and Access Rules of Conduct and Operation Standards Metadata Risk Privacy Liability Security Market Analysis
7	Questions from User Perspective Developers – what can I expect? What requirements will be placed upon me? How will this world operate? What can I claim as intellectual capital and commercialize? What do I have to provide in return? Contributors of Data – what copyright will I retain, if any? What liability might I have? What format/standards must I adhere to in providing data? Is there a corresponding return/benefit to me? Agencies as Purchasers/Users of products – what is quality of product? What liability might I have? Do my local laws allow me to purchase and use OS? To provide OD? What additional costs must I consider?
8	Questions from User Perspective Travelers/Users – does any of this violate my privacy or have the ability to expose personal information? Who owns the data that I generate? Does it have value? To whom and for what purpose? Will any of these new products distract me from safe driving or travel? Will my warnings and alerts be from a safe, authenticated source? General – is this world secure enough to prevent viruses or hacking into systems? Is the data of enough quality to be used for safety warnings? Who are decision makers? Who resolves conflicts? What is value to data/value to access of data? Are their laws that act as barriers? Are they uniform across States/locales/organizations? What is cost of OS products?
9
10	Intellectual Property Rights Definition Intellectual property rights address issues application developers are concerned with: patents, copyrights, and trademarks. Intellectual property rights must be defined in order to protect software and enable application production. Objectives Define what intellectual property rights are being granted to whom, by whom, and when. Identify conflicts associated with open source programming and retention of intellectual property. Identify methods for protecting a data contributor’s intellectual property rights. Evaluate and adopt a licensing agreement template in order to grant application developers rights that support their ability to gain value from their enhancements. Generate rules of conduct for access to and modification of data environments and open source code, respectively. Define what makes for a good open source environment Define how to develop an active and interested community of users and a service industry (maintenance, upgrades)
11
12	Intellectual Property Rights Expected Outcomes by Milestone:
13	Governance Three types: Governance of Data Environments and OS Portal Data Governance Mechanisms Governance Authority/Entity
14	Governance of Data Environments and OS Portal: Participation and Access Definition Governance analysis will determine who can participate and how in the IntelliDrive Mobility data environments. The structure includes agreements, permissions, and levels of access. Objectives Identify logical participation requirements for the data environments. Develop an administrative structure that corresponds to the structure of the environment itself. Determine appropriate levels of access and the criteria associated with those access levels. Analyze issues associated with foreign requests for data. Determine if there is an appropriate level of disclosure of personal information in return for access to data environments. Ensure that data and portal provide accessibility to all who wish to access these tools.
15	Governance of Data Environments and OS Portal: Conduct and Operation Definition Rules create the boundaries that define the conduct of developer actions within the open source and data environments and define the role/expectation for operations within the environments, including appropriate use of data and code. Objectives Identify proper rules associated with use and operation within the environment that do not clash with federal, state, and local laws, in particular, accessibility laws. Develop a proper system for monitoring misbehavior and applying sanctions to users who do not follow rules of conduct Create an easily accessible rules of conduct document. Develop rules and guidance for administrative staff associated with the data environments.
16	Data Governance: Standards Definition Standards refer to the application of an expected level of data quality and composition within the open source environment. Standards also refer to the standards and requirements for providing safe and effective displays, warnings, and alerts. Objectives Work with the ITS Standards experts to Identify whether data will be standardized according to existing or new standards; identify impact. Develop a code of standards for data quality, accuracy, and the elimination of PII where appropriate. Determine the best format to store and gather data sources and ensure that the data is uniform and compatible. Work with the Human Factors experts to develop policy recommendations on visual / audial / haptic standards and develop guidance for developers.
17	Data Governance: Metadata Definition Metadata refers to the need for a high-level description of the data environment itself, including what data it contains and the general conditions under which data were captures and should be prepared. Objectives Assign responsibility for the creation of the metadata system as well as its upkeep. Determine mechanisms for access to documentation. Define process for adding new categories or changing existing ones – who makes the decision? Who needs to be involved and/or notified? How will this be implemented? Determine what efforts /costs are needed for maintenance and upgrade.
18	Governance: Structure and Authority Definition Governance analysis defines roles, responsibilities, rules, and authorities and results in options for models that define who can take what actions with what information, under what circumstances, and using what methods; and the consequences for not following the appropriate rules. Objectives Identify the type of governance best suited for IntelliDrive data environments; and whether different environments will require different governance. Review different options for how to best optimize the goals of the program through governance. Address whether there is a need for new governance entities if not being managed by Federal government. Analyze costs associated with establishing governance structures. Identify common elements of misbehavior and enforcement techniques (and how they are applied).
19	Governance Expected Outcomes by Milestone: ***Looking to mechanisms on previous slides for governance before identifying need for governance entity
20	Risk: Privacy Definition Privacy includes two key elements: ability to be tracked through location data and exposure of personally-identifiable information (PII). If PII is involved, other elements of privacy include use of data, notification of how data is used, and transparency and accountability (based on VII Privacy Policies, 2007). Objectives Identify the key risk areas associated with non-DSRC communications including WiFi , satellite, and cellular signals. Develop a code of conduct for developers who intend to use PII and require they divulge prospective use of PII to consumers. Identify a process for allowing or disallowing data with PII from data contributors. Determine whether there is a level of non-intrusive PII that would serve to optimize mobility applications. Identify potential differences between jurisdictions regarding privacy.
21	Risk: Liability Definition For IntelliDrive Mobility, liability is likely to focus on product liability law and the complications arising from shared data and cooperatively developed source code and applications. Objectives Analyze how current product liability law applies to IntelliDrive (given shared data/cooperatively developed code and applications) and analyze at which point liability is transferred from one party to another. Identify liability issues associated with the dissemination of PII. Analyze the probability of malicious action within the open source environment and the relative likelihood of serious consequences. Develop policies that mitigate the consequences and enable market development and ensure that data has passed rigorous quality control tests before entering data environments.
22	Risk: Security Definition The identification of potential security risks within the communication spectrum is a complex issue, in particular because Mobility IntelliDrive leverages wireless other than DSRC. Addressing the security issues within all of these spectrums will be key to protecting the public at large from predatory actions and ensure that message transmission is authentic. Objectives Data Environments: Analyze the risks associated with storing data in large repositories and if that makes data a more attractive target. Applications: Identify risks associated with non-DSRC communications and how that effects the deployment and safety of consumer applications. Analyze whether certain applications are likely to be more vulnerable than others. Compare and recommend different encryption techniques for managing the safety of PII. Determine whether open source software/applications are more open to security breaches than proprietary software/applications.
23	Risk Expected Outcomes by Milestone:
24	Market/Deployment Analysis: Definition Market analysis will provide input on recommended options in support of market development, deployment, and use of innovative mobility applications. Objectives Analyze the prospect of a data environment becoming financially self-sustaining after an initial government investment; and determine whether there are commercial scenarios associated with that prospect. Attempt to identify value of pertinent data and/or access to data. Determine what incentives attract private sector participation in development of open source applications, and/or commercialization of applications, once developed. Identify external costs and issues associated with the adoption of new open source software for transportation management entities. Identify user acceptance issues – both agencies and consumers – and laws that might hinder adoption. Analyze and frame policy issues may occur for agencies in system optimization versus personal mobility optimization versus environmental optimization
25	Market/Deployment Analysis Expected Outcomes by Milestone:
26	Next Steps Take comments and finalize roadmap Post to website and request feedback Develop final policy roadmap for Mobility IntelliDrive Develop execution plan Identify what is already known or best practice – report in Winter 2011 Identify what further requires research in support of deployment --and the Federal role in providing that research to the community Identify how stakeholders and experts play a role in conducting the research Present results to Mobility technical team in accordance with key milestone dates to keep technical progress moving forward Present results to stakeholders through meetings, webinars, website postings