Updated_DTFH6115R00003.pdf

DTFH6115R00003

SOLICITATION, OFFER AND AWARD

4. TYPE OF SOLICITATION2. CONTRACT NUMBER 3. SOLICITATION NUMBER

7. ISSUED BY CODE 8. ADDRESS OFFER TO (If other than Item 7)

ORDER UNDER DPAS (15 CFR 700)

6. REQUISITION/PURCHASE NUMBER

NOTE: In sealed bid solicitations "offer" and "offeror" mean "bid" and "bidder".

NEGOTIATED (RFP)

SEALED BID (IFB)

5. DATE ISSUED

1. THIS CONTRACT IS A RATED RATING PAGE OF PAGES

1 94

C. E-MAIL ADDRESS

EXT.NUMBERAREA CODE

B. TELEPHONE (NO COLLECT CALLS)A. NAME

10. FOR

INFORMATION

CALL:

CAUTION: LATE Submissions, Modifications, and Withdrawals: See Section L, Provision No. 52.214-7 or 52.215-1. All offers are subject to all terms and conditions contained in this solicitation.

(Date)(Hour) local timeuntildepository located in copies for furnishing the supplies or services in the Schedule will be received at the place specified in Item 8, or if hand carried, in the

SOLICITATION

9. Sealed offers in original and

PART IV - REPRESENTATIONS AND INSTRUCTIONS

OTHER STATEMENTS OF OFFERORS

EVALUATION FACTORS FOR AWARD

INSTRS., CONDS., AND NOTICES TO OFFERORS

REPRESENTATIONS, CERTIFICATIONS AND

LIST OF ATTACHMENTS

CONTRACT CLAUSES

PART III - LIST OF DOCUMENTS, EXHIBITS AND OTHER ATTACH.

I

J

K

L

M SPECIAL CONTRACT REQUIREMENTS

CONTRACT ADMINISTRATION DATA

DELIVERIES OR PERFORMANCE

INSPECTION AND ACCEPTANCE

PACKAGING AND MARKING

DESCRIPTION/SPECS./WORK STATEMENT

SUPPLIES OR SERVICES AND PRICES/COSTS

SOLICITATION/CONTRACT FORM

PART II - CONTRACT CLAUSESPART I - THE SCHEDULE

H

G

F

E

D

C

B

A

SEC. DESCRIPTION PAGE(S) (X) DESCRIPTION SEC. (X)

11. TABLE OF CONTENTS

18. OFFER DATE17. SIGNATURE

SUCH ADDRESS IN SCHEDULE.

IS DIFFERENT FROM ABOVE - ENTER

15C. CHECK IF REMITTANCE ADDRESS

EXT.NUMBERAREA CODE

15B. TELEPHONE NUMBER

(Type or print)AND

ADDRESS

OF

OFFEROR

CODE FACILITY

16. NAME AND TITLE OF PERSON AUTHORIZED TO SIGN OFFER15A. NAME

DATEAMENDMENT NO.DATEAMENDMENT NO.

and related documents numbered and dated):

amendments to the SOLICITATION for offerors

(The offeror acknowledges receipt of

14. ACKNOWLEDGEMENT OF AMENDMENTS

CALENDAR DAYS (%)30 CALENDAR DAYS (%)20 CALENDAR DAYS (%)10 CALENDAR DAYS (%)

(See Section I, Clause No. 52.232.8)

13. DISCOUNT FOR PROMPT PAYMENT

designated point(s), within the time specified in the schedule.

by the offeror) from the date for receipt of offers specified above, to furnish any or all items upon which prices are offered at the price set opposite each item, delivered at the

12. In compliance with the above, the undersigned agrees, if this offer is accepted within ______________ calendar days (60 calendar days unless a different period is inserted

NOTE: Item 12 does not apply if the solicitation includes the provisions at 52.214-16, Minimum Bid Acceptance Period.

OFFER (Must be fully completed by offeror)

IMPORTANT - Award will be made on this Form, or on Standard Form 26, or by other authorized official written notice.

28. AWARD DATE

(Signature of Contracting Officer)

27. UNITED STATES OF AMERICA

25. PAYMENT WILL BE MADE BY

26. NAME OF CONTRACTING OFFICER (Type or print)

CODE 24. ADMINISTERED BY (If other than Item 7)

ITEM

(4 copies unless otherwise specified)

23. SUBMIT INVOICES TO ADDRESS SHOWN IN

41 U.S.C. 253 (c) ( 10 U.S.C. 2304 (c) (

22. AUTHORITY FOR USING OTHER THAN FULL AND OPEN COMPETITION:

21. ACCOUNTING AND APPROPRIATION20. AMOUNT19. ACCEPTED AS TO ITEMS NUMBERED

AWARD (To be completed by government)

CODE

HOIT-21-21-1501801/30/2015

X

HCFA

FEDERAL HIGHWAY ADMINISTRATION

OFFICE OF THE CHIEF FINANCIAL OFFICER

OFFICE OF ACQUISITION & GRANTS MGMT

1200 NEW JERSEY AVENUE, SE

WASHINGTON DC 20590

See Box 7 1500 ES 03/27/2015

Sarah H. Khan 202 Sarah.Khan@dot.gov

366-0220

X

X

X

X

X

X

X

X

X

X

X

X

X

PAGE(S)

Joseph A. Fusari

AUTHORIZED FOR LOCAL REPRODUCTION

Previous edition is unusable

STANDARD FORM 33 (Rev. 9-97)

Prescribed by GSA - FAR (48 CFR) 53.214(c)

Sarah.Khan Typewritten Text

Sarah.Khan Typewritten Text Location: E66-101

Sarah.Khan Typewritten Text See Section L.5 joseph.fusari Typewritten Text joseph.fusari Typewritten Text joseph.fusari Typewritten Text joseph.fusari Typewritten Text joseph.fusari Typewritten Text

Sarah.Khan Typewritten Text

Sarah.Khan Typewritten Text 02/27/2015

Sarah.Khan Typewritten Text

Sarah.Khan Typewritten Text

Sarah.Khan Typewritten Text

Sarah.Khan Typewritten Text

Broad Agency Announcement No. DTFH6115R00003

SECTION B - Supplies or Services/Prices

This acquisition supports two parts made up of three phases. Phase 1, Concept Development, will be conducted under Firm Fixed Price (FFP) contracts. Phases 2 and 3 will be conducted under a follow-on assistance agreement. Issuance of a follow-on assistance agreement is at the discretion of the Government. Only entities receiving a contract for the Phase 1 requirement are eligible for an assistance agreement under Phases 2 and 3.

B.1 FIXED PRICE

The Contractor shall furnish all equipment, travel, materials and personnel necessary to provide the Federal Highway Administration (FHWA) with non-personal technical support for “The Connected Vehicle Pilot Deployment Program, Phase 1”, as described in Section C below.

This is a FFP contract.

B.2 FIRM FIXED PRICE

The total amount for the performance of this FFP contract is [To Be Determined].

NOTE: See Section J.1 for the Milestone Payment Schedule.

SECTION C - Description/Specifications

C.1 BACKGROUND

The United States Department of Transportation (USDOT) connected vehicle research program is a multimodal initiative that aims to enable safe, interoperable networked wireless communications among vehicles, the infrastructure, and travelers' personal communications devices. Connected vehicle research is being sponsored by the USDOT and others to leverage the potentially transformative capabilities of wireless technology to make surface transportation safer, smarter, and greener. That research has resulted in a considerable body of research work that is now in hand to support pilot deployments, including systems engineering documentation and prototyping for more than two dozen connected vehicle applications. Concurrent federal research efforts have developed critical cross-cutting technologies and other enabling capabilities required to integrate and deploy applications. Descriptions of the following relevant research products, developed by the component connected vehicle research programs, can be found at www.its.dot.gov/pilots.

These programs seek to identify, develop, and deploy applications that leverage the full potential of trusted communications among connected vehicles, travelers, and infrastructure to better inform travelers, enhance current operational practices, and transform surface transportation systems management. In 2012-2013, the connected vehicle research program conducted the Safety Pilot Model Deployment in Ann Arbor, Michigan to assess the potential of V2V (and other) safety applications to reduce crashes and improve roadway system safety.

Building on the collective body of connected vehicle research work, the Connected Vehicle Pilot Deployment Program seeks operational deployments of connected vehicle applications that synergistically capture and utilize new forms of connected vehicle and mobile device data to improve multimodal surface transportation system performance and enable enhanced performance-based systems management. Improved performance should relate to one or more of the following: improved safety, mobility, or public agency efficiency; or reduced environmental impact. Connected vehicle applications support improved decision-making by both system users (travelers) and system managers. The intent is to deploy site-tailored collections of applications that address specific local needs while laying a foundation for additional local/regional deployment, and to provide transferable lessons learned for other prospective deployers across the nation.

The Connected Vehicle Pilot Deployment (CV Pilots) Program seeks to spur innovation among early adopters of connected vehicle application concepts. The pilot deployments are expected to integrate connected vehicle research concepts into practical and effective elements, enhancing existing operational capabilities. The intent of these pilot deployments is to encourage partnerships of multiple stakeholders (e.g., private companies, state and local agencies, transit agencies, commercial vehicle operators, and freight shippers) to deploy applications utilizing data captured from multiple sources (e.g., vehicles, mobile devices, and infrastructure) across all elements of the surface transportation system (i.e., transit, freeway, arterial, parking facilities, and tolled roadways) to support improved system performance and enhanced performance-based management. Contractors are expected to identify a set of key quantitative performance measures http://www.its.dot.gov/pilots and develop a deployed system that supports continuous monitoring of observed data capable of quantifying these measures. Pilot deployment sites are also expected to support an independent evaluation effort conducting a comprehensive assessment of cost-benefit, user acceptance/satisfaction, and lessons learned. Finally, pilot deployments are expected to become part of a permanent connected vehicle capability that is fully integrated into routine operational practice in the pilot site – and create a foundation for expanded and enhanced deployments. The CV Pilots program seeks institutional and financial models that enable long-term sustainment of successful elements of pilot deployments without dedicated federal funding.

C.2 CONTRACT SCOPE

The scope of this contract is limited to the development of the Connected Vehicle Pilot Deployment Concept.

C.3 OBJECTIVE

The objective of this contract is to develop an innovative and synergistic connected vehicle pilot deployment concept, to build partnerships among stakeholders, and to prepare a comprehensive pilot deployment plan that reduces technical, institutional and financial risk.

The overall objective of concept development Phase 1 is to set the stage for a connected vehicle pilot deployment that has an observable measureable near-term impact, deployed on-time and within budget.

C.4 INFORMATION

The work described below is for the structured development of a pilot deployment site concept to prepare for later phases of activity in which the envisioned system can be systematically designed in detail, built, tested, operated, maintained, and used to support evaluation.

Needs-Driven Focus. The USDOT has structured this Concept Development phase to follow a needs-driven approach as one of its key organizing principles. Needs related to system performance (mobility, safety, public agency efficiency and reduced environmental impacts) must be identified by relevant stakeholders. These needs must be represented in a focused set of performance measures and performance targets. Applications addressing these needs are then identified. Finally, the ability to capture and analyze observed data to monitor performance over time must be considered as a key requirement of the pilot deployment. In addition, Contractors shall support data needs associated with an independent evaluation effort.

Phases of the Pilot Deployment Effort. Each pilot deployment site is expected to be developed in three distinct phases:

• Phase 1: Concept Development – award up to 12 months.

In this phase the preliminary proposed idea is developed into a structured concept that is suitable for further design, building, testing, and operation. The structured concept will include identifying specific performance measures, targets, and capabilities associated with performance monitoring and performance management. Key deliverables include:

o Concept of Operations o System Requirements o Comprehensive Pilot Deployment Plan

• Phase 2: Design/Build/Test – up to 20 months.

In this phase, the pilot deployment concept is designed in detail, built, and tested prior to operation.

o System Architecture and System Design Development o Application Enhancement and Integration o Pilot Deployment System Build Out o Pilot Site Preparation for System Interoperability Test o System Interoperability Testing, including security operations interface testing

• Phase 3: Operate and Maintain – 18 months.

In this phase, the tested pilot deployment applications and technologies are placed into operational practice. The impact of the deployment on a set of key performance measures will be monitored and reported on a daily, weekly, and monthly basis. Further, performance and other data supporting a comprehensive assessment of deployment impacts are to be shared with an USDOT-identified independent evaluator.

Figure 1. The Three Phases of a Connected Vehicle Pilot Deployment

In the Concept Development Phase 1, the Contractor shall refine their proposed approach (See Section J.2) and create a clear set of documents defining deployment scope and requirements;

training, security, performance measurement, and safety management plans; codify partnering arrangements and contracts, and develop a preliminary deployment site plan. Upon successful completion of the Concept Development Phase 1, the FHWA may issue a site-specific Assistance Agreement covering the second and third phases of the effort, namely a Design/Build/Test (Phase

2) and Maintain/Operate Phase (Phase 3). After the three phases of the effort are complete, successful elements of the pilot deployment are expected to transition to become elements of routine operational practice. Pilot Deployment sites will be responsible for the funding of continued operations of successful elements of the Pilot Deployment beyond the period of performance of the federal Pilot Deployment Program. The Connected Vehicle Pilot Deployment Site life cycle is summarized graphically in Figure 1.

C.5 DELINEATION OF PHASE 1 WORK

The Contractor shall perform the work described in the following tasks:

• Task 1 Program Management

• Task 2 Pilot Deployment Concept of Operations (ConOps)

• Task 3 Security Management Operating Concept

• Task 4 Safety Management Plan

• Task 5 Performance Measurement and Evaluation Support Plan

• Task 6 Pilot Deployment System Requirements

• Task 7 Application Deployment Plan

• Task 8 Human Use Approval

• Task 9 Participant Training and Stakeholder Education Plan

• Task 10 Partnership Coordination and Finalization

• Task 11 Outreach Plan

• Task 12 Comprehensive Pilot Deployment Plan

• Task 13 Deployment Readiness Summary

NOTE: The COR will supply supporting tools and technical assistance to the Contractors.

Technical assistance includes technical support for all USDOT-supplied tools as well as technical support associated with providing updated source code, data, and documentation from the set of completed and ongoing application prototyping efforts, as available.

Task 1 - Program Management

This task shall extend over the entire period of performance of this effort. Shortly after contract award, the Contractor shall attend a kick-off meeting to be held in Washington, DC with the COR and its representatives to ensure that all parties have a common understanding of the COR’s requirements and expectations. The Contractor shall bring its key personnel to this meeting and the COR will arrange the location, the agenda, and the list of other (non-Contractor) attendees. This Kick-Off meeting shall occur no later than fifteen (15) business days after contract award.

The Contractor shall prepare a Program Management Plan (PMP) that describes the activities required to perform the work described in all identified Concept Development task areas, per current PMBOK guidance1. At a minimum, the PMP shall contain a Scope Management Plan, a Schedule Baseline and Work Breakdown Structure, a Communications Management Plan, a Cost Management Plan, a Schedule Management Plan, a Quality Management Plan and a Risk Management Plan. The Communications Plan shall describe internal team communications and governance methods, as well as communications with the COR. The Quality Management Plan shall explicitly describe Configuration Management.

A Stakeholder Registry shall be developed and updated as needed throughout the Concept Development Phase. Note: For the purposes of the Pilot Deployment effort, a Pilot Deployment partner refers to an organization or individual on the Contractor’s team. A stakeholder refers to an

1 PMI (2012), A Guide to the Project Management Body of Knowledge, 5th Ed.

organization or individual potentially impacted by the Pilot Deployment itself, regardless of whether they are team members (partners) or not. Each stakeholder shall be identified by organization and role within the Stakeholder Registry.

The PMP shall be accompanied by a detailed Concept Development Project Schedule, considered to be a logical component of the PMP, although it may be a physically separate electronic file. The Phase 1 Project Schedule shall list all activities required to bring all required work to a successful completion and shall contain – at a minimum – three levels of the Work Breakdown Structure (WBS). The Project Schedule shall be updated monthly. The Project Schedule shall describe the following:

• Name of the work activity

• Expected start and end dates

• Name of the individual with the primary responsibility for accomplishing the work

• Dependencies with other work activities in the Project Schedule

• All deliverables, procurements, or milestones resulting from the work activity

The PMP shall be delivered in draft to the COR. After receiving the COR’s comments and resolving them, the Contractor shall provide the “final” version of the PMP and its related documents. During the course of the Connected Vehicle Pilot Deployment, the Contractor may propose modifications to the PMP. Any such modifications shall go through the cycle of draft submission, COR review and comment, comment resolution, and submission of a “final” version.

The Contractor shall also provide monthly progress reports that identifies all deliverables and deliverable status (not initiated, in progress X% complete, draft delivered, in revision X% complete, final delivered, accepted). The monthly report shall contain a narrative of accomplishments by task and projected activities in the next monthly period. The monthly report shall contain the updated Project Schedule. Each monthly report shall contain a schedule risk narrative, a technical risk narrative, a partnership risk narrative, a retrospective cost narrative, and a projected cost-to-complete narrative.

Task 1 Deliverables

• Kickoff Briefing

• Project Management Plan (Draft and Final)

• Monthly Reports

Task 2 - Pilot Deployment Concept of Operations (ConOps)

The purpose of this task is to refine and improve the proposed pilot deployment concept and document this in a complete Pilot Deployment Concept of Operations. Among other elements, the ConOps shall refine the set of proposed high-priority needs through structured stakeholder interaction, rigorously define a set of key performance measures and identify associated quantitative performance targets for each performance measure that are achievable within the time frame of the Pilot Deployment. The ConOps shall describe the specific combination of applications to be deployed in the Pilot Deployment, and how operational practice will be altered based on the introduction of these applications.

Structured Stakeholder Interaction. Using the Stakeholder Registry developed in Task 1, the Contractor shall conduct a structured stakeholder interaction to gain insight on draft needs, performance measures (and targets), and descriptions of altered operational practice. These methods of interaction may include but are not limited to surveys, interviews, webinars, and in-person meetings. A ConOps Stakeholder Review Panel shall be identified, drawing on the Stakeholder Registry developed in Task 1. The Stakeholder Review Panel is a subset of all stakeholders intended to participate in the ConOps Walkthrough (see below). The Contractor shall deliver a draft Stakeholder Review Panel Roster for COR review.

Performance Measurement. The ConOps shall incorporate an essential need to monitor and quantify a set of quantitative performance measures associated with the motivating needs underlying the Pilot Deployment.

The Pilot deployment sites (See Section J.2) shall necessarily focus on combinations of applications that result in improved and measureable system performance in one, or preferably more, of the following high level categorical areas:

• Safety, for example o transportation system users in all modes (e.g., pedestrian, passenger, driver) o first responders and public agency personnel o construction and maintenance workers

• Mobility, for example o the ability of individuals to travel predictably, reliably, and rapidly under a representative set of operational conditions reflecting variations in travel demand as well as incident and weather impacts.

o the ability of all individuals (including subgroups such as persons with disabilities) to access goods and services via multiple transportation modes (e.g., walk, bike, rail and bus transit, carpool, and ridesharing) o the ability of freight movements to be conducted rapidly, efficiently, and reliably

• Environment, for example o reductions in fuel consumption o reductions in emissions

• Public Agency Efficiency, for example o all-season efficiency in maintenance and operations activities o improved system management capabilities in extreme conditions

(e.g., major incident response, intense weather, and special events)

Enhancements to Operational Practice. The ConOps shall describe proposed operational practice (“with Pilot Deployment”) and current operational practices (“no Pilot Deployment”) for benchmarking system performance. The ConOps shall identify a set of proposed applications to deployed as a part of a deployed system supporting the proposed enhanced operational practice.

The ConOps shall identify and detail the specific use cases relevant to the proposed Pilot Deployment concept, specifically in the use cases where applications associated with the Pilot Deployment are expected to have the most impact in achieving target performance goals. Key factors that could confound performance measurement shall be identified and a high-level mitigation approach outlined for each confounding factor. The ConOps shall include a set of quantitative performance targets associated with each performance measure (e.g., within the Operational Impacts portion of the ConOps).

Needs Summary. The Contractor shall provide a summary of identified draft needs for COR review prior to developing a draft ConOps. At this time, the COR will also provide input on any expected additional needs supporting a broader independent evaluation effort that will run concurrently with Phases 2 and 3 of the Pilot Deployment. The Contractor shall finalize the needs summary based on the COR’s comments.

Context Diagram. The ConOps shall include a schematic context diagram illustrating a high-level physical description of the proposed system (see Figure 2). The context diagram shows the set of physical objects expected in the deployed pilot deployment system. The context diagram shows high-level data exchanges expected among system objects. Text supporting the diagram shall detail all assumptions made and catalog any/all uncertainties in these assumptions. This diagram does not replace or define system architecture or system design. It is intended only to provide context for the ConOps in the elicitation of needs and to surface ambiguities or uncertainties associated relevant to ConOps development.

Draft ConOps Development. The Contractor shall follow the guidelines for format and content in IEEE Standard 1362-1998 to develop a ConOps that describes the proposed Pilot Deployment.

The Contractor may use the template structure in the IEEE standard (Section 4), or the template in the FHWA Guidebook2 for developing the ConOps.

2 http://www.fhwa.dot.gov/cadiv/segb/views/document/Sections/Section8/8_4_5.htm Although the template structure in the IEEE standard (Annex B) differs from that in the Systems Engineering Guidebook for ITS, the content suggested is essentially the same.

http://www.fhwa.dot.gov/cadiv/segb/views/document/Sections/Section8/8_4_5.htm

Figure 2. Generic Context Diagram for ConOps

ConOps Walkthrough. The Contractor shall deliver a draft ConOps for COR review. The Contractor shall revise the draft report based on comments from COR. After revision based on COR comments, the Contractor shall schedule and conduct a ConOps Walkthrough (see IEEE Standard 1362-1998 for required elements) of the revised report with COR and key stakeholders.

The Contractor shall also provide a walkthrough comment resolution report containing a description of the resolution of all comments received. The Contractor shall revise the report based on comments received at the walkthrough, and provide a final version. The COR must accept and approve all comment resolutions before the revised report is considered final.

ConOps Webinar. After COR’s concurrence of the Final ConOps, the Contractor shall deliver a one-hour webinar that describes the approved deployment concept for interested internal and external stakeholders. The intent of this webinar is to inform and engage the broader connected vehicle deployment community. The Contractor shall coordinate with COR in scheduling, promoting, and delivering this webinar. COR staff will monitor the webinar and track comments and questions off-line using a chat box or similar function. At the end of the webinar, the Contractor staff shall be asked to verbally respond to these off-line comments. The COR will record the webinar, and post all briefing materials, questions and answers on the COR CV Pilots website.

Task 2 Deliverables

• Stakeholder ConOps Review Panel Roster (Draft and Final)

• Needs Summary (Draft and Revised)

• Concept of Operations (Draft and Final)

• ConOps Walkthrough Briefing Deck

• ConOps Comment Resolution Report (Draft and Final)

• ConOps Webinar (public)

Task 3 - Security Management Operating Concept

As a companion document to the ConOps, the Contractor shall develop a Privacy and Security Management Operating Concept. This document shall describe the underlying needs of the Pilot Deployment to protect the privacy of users, ensure secure operations, and outline a concept that addresses these needs.

Privacy Needs. Private information relates to any data emitted, collected, or stored about individuals. A key concept in privacy analysis is Personal Identifiable Information (PII). PII is any information that can be used to distinguish or trace an individual’s identity. PII is not specific to any category of information or technology, each case and associated risks must be individually examined for context and the combination of data elements that are provided or obtainable.

Table 1 provides examples of PII-related data. Note that some data with potential PII implications may be generated through an opt-in agreement, while other data may be envisioned as a part of a regulatory messaging environment. For example, an opt-in agreement may enable a tailored multi-modal traveler information application to utilize user-generated planned itinerary and target time of arrival trip data. Whether these data are obtained by partners in the public or private sectors in a regulatory or an opt-in mobile environment, the need to justify the collection of these data and the need to protect these data remains the same.

Type of PII-Related

Data

Definition Examples

Non-PII Information that is collected but cannot trace back to an individual

Browser Type, Local Time Zone, Date and Time of Visitor Requests, Device Type, Traffic

Counter Information

Potential PII Data elements that cannot be linked to a specific person until combined with other actual PII

Internet Cookies, IP Addresses, Credit reports

Actual PII Information that can be used to locate or identify an individual

Names, Addresses, Telephone Numbers, any Identifying

Number (e.g., VIN)

Locational

PII

Information that can be used to identify an individual at a particular location

License Plate Numbers, GPS Device Location Information

Sensitive PII PII which, if lost, compromised or disclosed without authorization either alone or with other information, carries a significant risk of economic or physical harm

Medical Records, Social Security Numbers, Bank

Account Numbers, Passport Numbers

Table 1. Types of Personally Identifying Information (PII)

The Contractor shall determine and document in the Privacy and Security Management Operating Concept the extent to which their system or systems will collect or store PII and PII-related information, and ensure that there is a legitimate need for this information in order to meet the goals of the system and that the data is only accessible for and used for these legitimate purposes.

Privacy Operational Concept. The Privacy and Security Management Operating Concept shall describe, at a high level, the concepts to be implemented to ensure the privacy is protected and that any required PII is handled appropriately. Consideration shall be given to, at a minimum, the following types of protections:

• Transparency

• Individual Participation and Redress

• Purpose Specification

• Data Minimization

• Use Limitation

• Data Quality and Integrity

• Security ( see security needs, below)

• Accountability and Auditing

Security Needs: For each individual proposed application, and for the system as a whole, the Contractor shall address the needs, if any, for confidentiality, availability, integrity, authenticity and non-repudiation. Confidentiality is ensuring that information is not made available or disclosed to unauthorized persons or systems. Note that confidentiality is not always a requirement. Connected vehicles broadcast Basic Safety Messages (BSMs) with the intent that any nearby system can receive an interpret them, i.e., there are no unauthorized persons or systems in this case. Availability deals with the needs for the system or service to be accessible, functioning, and able to provide any necessary information when needed. Denial of Service attacks are a well-known type of attack on the availability of systems connected to the Internet. Integrity is the preservation of the accuracy and consistency of data, including protecting against unauthorized modification and the ability to detect attempts at unauthorized modification. BSM’s should not be able to be modified and then rebroadcast, for example. Similarly, billing records must be protected against unauthorized changes. Authenticity and non-repudiation deal with the ensuring that data and information is authentic, that the sender is who it is claimed to be, and that a sender cannot later successfully claim not to have sent a message they have sent, and a receiver cannot successfully claim not to have received it. Note that this can be important for financial transactions and also as part of internal system security controls, but is clearly not needed for all transactions or all applications.

Security Operational Concept: The Privacy and Security Management Operating Concept shall describe, at a high level, the concepts to be implemented to meet system security and privacy needs. The COR will provide a prototype national-level Security Credential Management System (SCMS) as a key tool for implementing a Public Key Infrastructure (PKI) based system for communication security controls to meet these needs. The SCMS provides digitally signed certificates that can be used as part of the process for signing and encrypting messages. The proposed pilot shall utilize the SCMS as a tool to support general deployment communication security. Physical security of the elements that make up the installation should be addressed as well. In addition, the proposed pilot shall utilize the SCMS for at least one of the proposed applications, and all applications where utilizing the SCMS is deemed appropriate (e.g., applications where trust and security are essential). It is allowable to use alternative means to meet the communication security needs for applications that are at a relatively mature state with respect to their security implementation and that already meet all security and privacy needs through an alternative approach, provided the SCMS is used on at least one application in the proposed pilot.

The COR will supply technical support interfacing with the prototype SCMS, as well as tools intended to support this effort. For example, the Connected Vehicle Reference Implementation Architecture (CVRIA) (url: http://www.iteris.com/cvria/) is being developed as the basis for identifying the key interfaces across the connected vehicle environment which will support further analysis to identify and prioritize standards development activities. CVRIA will also support policy considerations for certification, standards, core system implementation, and other elements of the connected vehicle environment. COR technical support also includes the Systems Engineering Tool for Intelligent Transportation (SET-IT), a single software tool that integrates http://www.iteris.com/cvria/ drawing and database tools with the CVRIA so that users can develop project architectures for pilots, test beds and early deployments (http://www.iteris.com/cvria/html/resources/tools.html).

The Contractor shall deliver a draft version of the Security Management Operating Concept to the COR for review. The Contractor shall prepare a revised finalized document in response to COR comments. The COR must accept and approve all comment resolutions before the revised report is considered final.

Task 3 Deliverables

• Security Management Operating Concept (Draft and Final)

Task 4 - Safety Management Plan

As a companion document to the ConOps, the Contractor shall develop a Safety Management Plan. This document shall describe the underlying safety needs associated with the safety of all travelers, subjects, and other personnel associated with the Pilot Deployment.

Safety Needs. The Contractor shall develop a set of Safety Scenarios related to the applications and technologies selected for the Pilot Deployment. These scenarios shall include an analysis of likelihood and potential impact. Potential mitigating actions taken at various times and locations shall be identified for each scenario. A set of Safety Needs shall be derived from this scenario-based analysis. The Contractor shall identify levels of safety risk associated with the Pilot Deployment, using established processes where possible, (e.g., ISO 26262 ASIL). The nature of these assessment processes will be dependent on the applications selected and the nature of the specific safety risks.

Safety Operational Concept. The Contractor shall develop a Safety Operational Concept that describes the actions expected to be taken within the deployment to reduce the likelihood and potential impact in each safety scenario. The Safety Operational Concept shall also include a description of a fail-safe system mode and associated stakeholder response that can be deployed as a default in the case of unanticipated safety-related events.

The Contractor shall deliver a draft version of the Safety Management Plan to the COR for review.

The Contractor shall prepare a revised document in response to the COR’s comments. The COR must accept and approve all comment resolutions before the revised report is considered final.

Task 4 Deliverables

• Safety Management Plan (Draft and Final)

Task 5 - Performance Measurement and Evaluation Support Plan

In Phase 3, the tested pilot deployment applications and technologies are placed into operational practice. The impact of the deployment on a set of key performance measures (identified in Task

2) will be monitored and reported on (at a minimum) a daily, weekly, and monthly basis. In Task 5, the Contractor shall develop a plan to ensure quantitative performance measurement against identified targets is embedded as a core pilot deployment capability. Further, performance against http://www.iteris.com/cvria/html/resources/tools.html baseline measurements and targets are anticipated to be routinely and publically reported throughout Phase 3 daily (or more frequently). Some results related to prototype application performance are posted at www.its.dot.gov/pilots to assist the Contractors. Weekly and monthly summaries/dashboards of performance to date covering all key measures are anticipated to be required features in all Phase 3 deployment sites. Additional quantitative and qualitative performance measurement may also be required to support an independent evaluation effort.

Building from material describing the set of critical performance measures in the ConOps, the Contractor shall prepare a detailed Performance Measurement Plan. Procedures built into the pilot deployment system shall generate a set of quantitative estimates associated with each critical performance measure and independent evaluation needs (these requirements shall be described and referenced in the System Requirements Specification (SyRS) Document. The Contractor may choose to develop the Performance Measurement Plan prior to, or simultaneously with the SyRS.

Regardless of the order, the Performance Measurement Plan and SyRS must be mutually consistent with and appropriately cross-referenced when in final form. The intended actions of the system managers and users in the deployment that ensures accurate performance measurement must be enabled by data collected, processed and presented by the proposed deployed system (SyRS).

Participant Action Logs. The Performance Measurement Plan shall contain a proposed protocol for recording actions taken by key deployment participants. Participants include any system manager (e.g., TMC staff) or system user (e.g., bus driver) who adapt their behaviors to utilize the new capabilities enabled by the Pilot Deployment. These protocols shall describe the specific actions required or requested that participants follow in Phase 3. For example, a TMC operator may currently have a decentralized protocol when organizing a multi-organizational incident response. With a new deployed capability, this same staff member might instead follow a detailed protocol broadcasting prepared or tailored response plans enabled by connected vehicle and mobile device technologies. This record of actions is intended to strengthen the linkage between actions taken and changes in measured performance in the transportation system.

Field Performance Data Collection. The Performance Measurement Plan shall define how the proposed operational case (“with Pilot Deployment”) and the current case (“no Pilot Deployment”) for benchmarking system performance will be represented in the Pilot Deployment Operate and Maintain Phase (Phase 3). For example, the Contractor may describe a time-series “before” and “after” approach. However, a more complex (and potentially revealing) plan may also be considered wherein participant actions and deployment sub-elements are selectively activated to create control and treatment groups throughout Phase 3. The Performance Measurement Plan shall identify, by data source, the data elements, frequency, precision, and nature of observed data to be collected, processed and utilized to measure pilot deployment impact against targets.

Modeling and Simulation. The Performance Measurement Plan shall describe plans to incorporate modeling and simulation (in coordination with field data collection) to assist in key system performance measurement/estimation. For example, analytical tools may be useful in the estimation of measures difficult to directly observe (e.g., system-wide travel time reliability, aggregate mobile emissions, or system-wide fuel consumption). As needed, the Performance http://www.its.dot.gov/pilots

Measurement Plan shall include a summary of the nature of proposed analytic software (i.e., tools) and software inputs (i.e., models). For example, a tool might be a specific transportation simulation software package (e.g., TRANSIMS). The set of inputs created for the software tool representing a specific facility, corridor, or region is considered a model. Each item in the summary shall be described in terms of current maturity, proposed extension or integration, and the ability of a third-party evaluator to access and utilize developed tools, models, and/or analytic outputs.

Confounding Factors. The Performance Measurement Plan shall identify expected confounding factors that might influence performance measurement. Potential mitigation approaches shall be identified for each confounding factor. The use of statistical techniques or counterfactual modeling and simulation assessments to mitigate these factors shall be described. For example, if fuel prices rise rapidly during the course of Phase 3 and suppress overall transportation system demand, the plan should identify feasible methods (e.g., statistical or simulation based) to isolate the effect of this confounding factor and accurately estimate the impact of the pilot deployment on aggregate system delay.

Use Cases/Scenarios. The Performance Measurement Plan shall describe methods used to create, identify or otherwise generate the specific use cases where the Pilot Deployment is expected to have the most impact in achieving target performance goals. For example, if reduction in incident duration is identified as a key measure, the process by which data and human resources are combined to identify incidents and measure incident duration shall be detailed in the Performance measurement Plan. The Performance Measurement Plan shall contain information on how suitable participants will be identified, recruited, and compensated.

Support to Independent Evaluation Effort. COR will provide broader evaluation-related capabilities required support a site-specific independent evaluation effort. The Performance Measurement Plan shall specifically identify data flows (including but not limited to field data, calculated performance measures, and action log entries) that will be provided to support the evaluation effort.

Data Sharing Framework. The Performance Measurement Plan shall include a Data Sharing Framework, a description of performance measurement data to be generated and transmitted to COR, including the frequency of these updates. These data, at a minimum, shall include system performance against the performance measures selected to be routinely and periodically reported throughout Phase 3. The description of these data shall include the sources of field data, the format and nature of the performance measures reported, and Action Log entries contemporaneous with data collection. The expected nature and content of data sharing outlined in the plan shall be consistent with and complementary to Action Logs, Field Data Collection, performance measure calculation processes (including use of Modeling and Simulation, Confounding Factors, and Use Cases/Scenarios), and Support to Independent Evaluation. The Data Sharing Framework shall be consistent with the Privacy Operational Concept, and shall describe how the Privacy Operational Concept is expected to be operationalized in the Pilot Deployment.

The Contractor shall deliver a draft version to the COR for review. The Contractor shall prepare a revised document in response to COR’s comments. The COR must accept and approve all comment resolutions before the revised document is considered final or return for re-revision with comments.

Performance Measurement Webinar. After the COR’s concurrence of the Final Performance Measurement Plan, the Contractor shall deliver a one-hour webinar that describes the approved performance measurement plan for interested internal and external stakeholders. The intent of this webinar is to inform and engage the broader connected vehicle deployment community. The Contractor shall coordinate with COR in scheduling, promoting, and delivering this webinar.

Task 5 Deliverables

• Performance Measurement Plan (Draft and Final)

• Performance Measurement Plan Webinar (public)

Task 6 - Pilot Deployment System Requirements

The Contractor shall develop a System Requirements Specification (SyRS) Document based on the COR-approved ConOps, following the guidance in IEEE Standard 1233-1998. At a minimum, the following requirements shall be included:

• Functional requirements including communications, security, and safety requirements

• Interface requirements including identification of relevant standards (where appropriate)

• Performance requirements including system performance targets and performance requirements

• Data requirements including data-sharing requirements

The requirements shall identify what the Pilot Deployment must accomplish; identify the subsystems; and define the functional and interface requirements among the subsystems.

Each performance measure and target identified in the ConOps in Task 2 should have a corresponding performance requirement. The role of each subsystem in supporting system-level performance requirements shall be identified, including associated subsystem functional, interface, data, and performance requirements. Further, the SyRS must be consistent with and support all essential elements of the Performance Measurement Plan (Task 5).

Requirements shall meet the test of being “well-formed requirements” based on forthcoming USDOT guidance, e.g.: Tangible, Atomic, Necessary, Consistent, Accurate, Complete and Testable. The Pilot Deployer shall provide a Needs-To-Requirements Matrix, tracing requirements back to needs defined in the ConOps.

SyRS Stakeholder Review Panel. A SyRS Stakeholder Review Panel shall be identified, drawing on the Stakeholder Registry developed in Task 1. The SyRS Stakeholder Review Panel is a subset of all stakeholders intended to participate in the SyRS Walkthrough (see below). The Contractor shall deliver a draft Stakeholder SyRS Review Panel Roster for COR review. The Contractor shall prepare a revised document in response to COR’s comments. The COR must accept and approve all comment resolutions before the revised document is considered final or return for re-revision with comments.

SyRS Walkthrough. The Contractor shall deliver a draft SyRS Report for COR review. The Contractor shall revise the draft report based on comments from COR. After revision based on COR comments, the Contractor shall schedule and conduct a SyRS Walkthrough (“walkthrough”

– see IEEE Standard 1028) of the revised report. This SyRS Walkthrough will be conducted as an in-person meeting in Washington, DC in a USDOT-designated facility that supports a webinar function. The SyRS Review Panel members may participate in-person or via webinar, however, key Contractor team members associated with the SyRS must attend in person. The Contractor shall also provide a walkthrough comment resolution report containing a description of the resolution of all comments received. The Contractor shall revise the report based on comments received at the walkthrough, and provide a final version. The COR must accept and approve all comment resolutions before the revised report is considered final.

Task 6 Deliverables

• Stakeholder SyRS Review Panel Roster (Draft and Final)

• System Requirements Specification (SyRS) Document (Draft and Final)

• SyRS Walkthrough Workbook

• Walkthrough Comment Resolution Report (Draft and Final)

Task 7 - Application Deployment Plan

The Contractor shall systematically assess the requirements to incorporate into the selected applications as a part of the deployment concept. These application deployment requirements shall be incorporated into the System Requirements Specification (SyRS) document (Task 6).

When the System Requirements are complete, the Contractor shall prepare an Application Deployment Plan. This plan describes the additional functionality and/or performance elements required to further develop, tailor, and integrate applications for use within the Pilot Deployment.

Each identified application modification shall be accompanied by an assessment of the amount of development work required in Phase 2 (both schedule and cost).

The Application Deployment Plan shall identify any/all expected open source software and other supporting contributions expected from the system design and development process intended for posting on the Open Source Application Development Portal (OSADP).

The Contractor shall deliver a draft version of the Application Deployment Plan to the COR for review. The Contractor shall prepare a revised document in response to COR comments. The COR must accept and approve all comment resolutions before the revised document is considered final or return for re-revision with comments.

Task 7 Deliverables

• Application Deployment Plan (Draft and Final)

Task 8 - Human Use Approval

The Contractor shall obtain Human Use Approval from an accredited Institutional Review Board (IRB). Note that the COR will not act as an IRB for the purposes of the Pilot Deployment.

The Contractor is responsible for granting IRB approval for human participation within the Pilot Deployment.

The Contractor shall deliver a draft version of Human Use Approval Summary to the COR for review. The Contractor shall prepare a revised document in response to COR comments. The COR must accept and approve all comment resolutions before the revised document is considered final or return for re-revision with comments.

Task 8 Deliverables

• Human Use Approval Summary (Draft and Final)

Task 9 - Participant Training and Stakeholder Education Plan

The Contractor shall prepare a high-level plan for the recruitment and training of all travelers, drivers, and other personnel participating in the Pilot Deployment. Note that this plan shall be consistent with the outcomes and plans associated with both the Human Use Approval Plan (Task

8) and Safety Management Plan (Task 4). The Participant Training Plan shall identify the roles that participants will take during the pilot deployment, including a rough description of their activities and responsibilities, and likely training…