Attachment 1 - Draft Performance Work Statement.docx

Attachment 1 Draft Performance Work Statement

INTERSECTION SAFETY SYSTEM (ISS) PROTOTYPING

PERFORMANCE WORK STATEMENT (PWS)

OBJECTIVE, PHASING, AND TIMELINE

The objective of this effort is to acquire ISS prototypes to assess the potential benefit and feasibility of broader ISS deployment.

The ISS Prototyping effort has two phases:

· Phase 1: Prototype Development and Testing (Base Period)

· Minimum 12-month duration

· Maximum 18-month duration

· Phase 2: Prototype Refinement and Assessment (Optional Task)

· Minimum 18-month duration

· Maximum 24-month duration

NOTE: Contractors may propose phase durations and corresponding deliverable schedules for each phase within the Government-identified minimum and maximum values.

Figure 1 illustrates the two-phase approach, including the Government option decision prior to executing Phase 2.

Figure 1. Two-Phase Approach for ISS Prototyping

PHASE 1: PROTOTYPE DEVELOPMENT AND TESTING (BASE PERIOD)

The objective of Phase 1 is to develop and test initial ISS prototypes in an access-controlled testbed situated apart from public roadways and closed to the general public, hereafter referred to as a closed testbed. ISS prototypes must address high-value real-world intersection safety issues identified by a public sector partner. ISS prototypes are developed and tested iteratively in the closed testbed with public sector partner engagement. ISS prototypes are demonstrated and assessed for operational readiness at the conclusion of this initial phase. Each Contractor team must include:

· a lead entity responsible for ISS development and testing,

· an entity providing access to an accredited configurable closed testbed, and

· a public sector partner committed to the following activities by phase (documented in a letter of support):

· Providing supporting data and ensuring the prototype concept and testing aligns with high-priority intersection safety issues relevant to intersections under their jurisdiction (Phase 1).

· Supporting the installation of ISS prototypes in appropriate intersections under their jurisdiction in observe-only mode, with deployed ISS prototypes potentially taking specific real-time mitigating actions subject to prior approval (Phase 2).

NOTE: A single organization may play one or more of these required roles.

Using currently available data sources, the Contractor teams characterize high priority intersection safety issues under the jurisdictional control of the public sector partner. Contractor teams document observed intersection safety issues in a set of detailed use cases, scenarios, and operational conditions describing, at a minimum, location/geometry, weather/visibility, road user demand conditions, and observed road user behavior, among other factors. Contractor teams utilize the detailed use cases, scenarios, and operational conditions to develop a detailed Test Plan. The Test Plan must reflect, in structure and intent, the Government-provided high-level (experimental) test plan provided as Exhibit A: ISS Prototyping Phase 1 Test Plan Requirements of this PWS and required measures of effectiveness comprising both safety and congestion-reduction improvements. Note that Contractor teams are expected to share data obtained during the experiment, and later structure/process and share these data. Details regarding data sharing are included in Appendix A as well as below in the Task 1-7: Code/Data Sharing description.

Within a configurable closed testbed, the prototype ISS is tested against the detailed Test Plan to address key research questions related to conflict prediction, identifying unsafe conditions, and proposed mitigation strategies. Contractor teams analyze data from the tests regarding the key research questions, and document findings in a final report. Contractor teams are required to demonstrate the ISS operating in real-time within the closed testbed for a delegation of USDOT subject matter experts. This demonstration is intended to show the nature and timing of strategies used to address unsafe conditions and mitigate individual conflicts.

Based on the results obtained in the experimentation and demonstration, each of the Contractor teams assesses the deployment readiness of their ISS prototype in a summary report. Finally, Contractor teams share data and code from their experiments according to the Test Plan.

In Phase 1, the Government seeks ISS prototypes capable of:

· Predicting and mitigating individual conflicts in real-time

· Conflicts are situations wherein the risk of imminent collision among specific nearby road users is high. The Government seeks ISS prototypes that are capable of predicting individual conflicts, e.g., an imminent collision between a vehicle and a pedestrian, and take an immediate mitigating action, e.g., issuing an auditory or visual warning to the vehicle driver, the pedestrian, or both.

· Characterizing unsafe conditions as they develop and making appropriate operational changes to improve intersection safety

· Unsafe conditions reflect more general operational conditions under which a high rate of conflicts and collisions has been observed in the past. The Government seeks ISS prototypes that are capable of characterizing and predicting unsafe conditions (e.g., unprotected left-hand turning movements across crosswalks with significant pedestrian volume) and make real-time operational changes to mitigate or eliminate the unsafe conditions (e.g., alter signal phasing to include a protected left-hand turning movement phase where conflicting pedestrian movements are not permitted and another phase where pedestrian movements are permitted and left-hand turns are not permitted).

· Implementing and testing practical mitigation strategies for predicted conflicts and/or identified or anticipated unsafe conditions, within the context of a closed testbed

· Mitigating strategies may include the real-time modification of intersection control and/or the issuance of warnings.

Phase 1, Key Research Questions:

· Conflicts. Can an ISS reliably predict conflicts among vehicles and road users?

· How far in advance can conflicts be predicted?

· Under what conditions can reliable conflict predictions be made?

· Unsafe Conditions. Can an ISS reliably identify conflicts and characterize unsafe conditions?

· What types of unsafe conditions can be reliably identified or anticipated?

· How quickly can unsafe conditions be reliably identified or anticipated?

· Mitigating Strategies. Can an ISS take meaningful mitigating actions, either in the form of warnings or changes to intersection control, to mitigate conflicts and/or unsafe conditions?

· Can changes to intersection control be implemented in real-time to mitigate unsafe conditions (e.g., eliminating permissive vehicle turning movements traversing busy crosswalks)? What changes to intersection control are most effective?

· Can warnings be issued in real-time to mitigate conflicts? What types of warnings are most effective (e.g., visual, auditory, haptic)?

· Can modifications to intersection control be utilized to mitigate individual conflicts (e.g., delay the illumination of a WALK signal until all approaching vehicles have safely cleared the crosswalk)?

· What are potential safety and congestion-reduction impacts resulting from these mitigating strategies?

PHASE 1 TASK STRUCTURE:

· Task 1-1: Project Management

· Task 1-2: Concept of Operations

· Task 1-3: Test Plan Development

· Task 1-4: Iterative Prototype Development and Testing

· Task 1-5: Prototype Demonstration

· Task 1-6: Operational Readiness Assessment

· Task 1-7: Code/Data Sharing

Task 1-1. Project Management This task establishes the Contractor’s Project Management approach for this effort, documented in a Project Management Plan (PMP). This task also covers the routine cadence of progress meetings and monthly report generation.

Phase 1 Kickoff Meeting. Within four weeks after the effective date of the award, representatives from the Contractor’s deployment team must schedule and attend a kickoff meeting with the USDOT and its representatives to ensure that all parties have a common understanding of the contract requirements and expectations. The kickoff meeting is planned as an in-person meeting in Washington, DC or at a Contractor-identified site, subject to Contracting Officer's Representative (COR) approval. A virtual meeting may replace the in-person kickoff, subject to COR approval.

Kickoff Meeting Attendance. The Contractor must bring its key personnel or their designees to this meeting. The COR will coordinate with the Contractor on the location, the agenda, and the list of other attendees. The COR will arrange for the meeting location, if held at USDOT.

Kickoff Meeting Travel Costs. Travel costs to attend the kickoff meeting (if any) must be limited to the Contractor’s key personnel only. A virtual web conference will be made available for remote participation by additional Government and/or Contractor team members.

Monthly Reporting. The Contractor must submit a monthly report detailing accomplishments and deliverables completed in the reporting period, identify key actions to be taken in the next reporting period, and assess overall project performance with respect to project schedule and cost. The monthly report must also include a description of all project risks, and actions taken to mitigate or eliminate these risks.

Project Management Plan. A successful deployment concept will require a disciplined approach to managing the execution of the work and making sure the team responsible for the deployment delivers the highest quality products on time and within budget. Consistent processes and procedures should be used to ensure quality and timeliness. The Contractor must conduct effective program management activities to include, at a minimum:

· Scope Management. This includes ensuring that all required activities are performed and that only required activities are performed. The Contractor must have mechanisms in place for verifying and controlling the overall scope of the deployment.

· Schedule Management. This includes managing the timely execution of work activities. A Project Schedule should list all activities required to bring the necessary work to a successful completion. Successful schedule management must identify how the team will monitor the project schedule and manage changes after a baseline schedule has been approved. Schedule management includes identifying, analyzing, documenting, prioritizing, approving or rejecting, and publishing all schedule-related changes. Schedule changes must receive approval from the Government prior to publishing.

· Communications Management. This includes the systematic planning, implementing, monitoring, and revision of all the channels of communication with project partners and with other stakeholders. For the purposes of this effort, a partner refers to an organization or individual on the Contractor team. A stakeholder refers to an organization or individual potentially impacted by the effort itself, regardless of whether they are team members (partners) or not. Communications management ensures effective internal team communications and governance methods, as well as external communications in coordination with the USDOT’s COR.

· Quality and Configuration Management. This includes managing how items to be placed under configuration control are identified, when they are identified, and when they are placed into a configuration control process or system. This includes the process for managing the quality of the deliverables produced under this effort, from planning to delivery. The Contractor must have processes in place for quality planning, quality control, and quality assurance of all deliverables.

· Risk Management. This includes identifying, prioritizing, and managing project risks in a timely and efficient manner. Risks that may impact the schedule, scope, or costs of activities performed under the project should be identified, documented, and tracked. Plans for mitigating or avoiding risks should be identified and implemented.

The Contractor must prepare a Project Management Plan (PMP) that describes the activities required to perform the work, applying current Project Management Body of Knowledge (PMBOK) guidance. The PMP will explain the roles and responsibilities of all key individuals within the program/project team. At a minimum, the PMP will contain a Scope Management Plan, a Schedule Management Plan, a Communications Management Plan, a Quality Management Plan, and a Risk Management Plan.

The Contractor will deliver a draft PMP to the USDOT. After receiving USDOT comments and resolving them, the Contractor will provide a revised version of the PMP and its related documents. Within the period of performance, the Contractor may propose modifications to the PMP. Any such modifications must go through the cycle of draft submission, USDOT review and comment, comment resolution, and submission of a revised version.

The PMP will be accompanied by a detailed deployment Project Schedule, considered to be a logical component of the PMP, although it will be submitted as a separate electronic file. The Contractor has leeway in creating the project schedule that matches their vision for the Phase and will list all activities required to bring the necessary work to a successful completion. The Project Schedule will contain – at a minimum – three levels of the Work Breakdown Structure (WBS). The Project Schedule must be submitted in an electronic format identified by the Government at the time of award.

The Project Schedule will be updated monthly and will 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; and

· Percent Work Completed.

Bi-Weekly Site-Specific Coordination Teleconferences. The USDOT requires the Contractor to organize and participate in a site-specific bi-weekly deployment coordination teleconference with the COR and federal team members to review work in progress, identify issues and risks, and coordinate technical assistance. At a minimum, key personnel and other relevant team members as appropriate for topic discussions should participate in these meetings.

Task 1-1 Required Deliverables

· Phase 1 Kickoff Meeting (Draft/Final)

· Project Management Plan (Draft/Final), Revised (as required)

· Monthly Progress Reports

· Agenda/Notes from Bi-weekly Coordination Teleconferences

Task 1-2: Concept of Operations In this task, the Contractor performs an intersection safety assessment based on the needs of the public sector partner, refines specific use cases of interest where an ISS can improve intersection safety, and describes the methods and actions taken by an ISS to identify, predict, and mitigate unsafe conditions and/or individual conflicts. These considerations are documented in a Concept of Operations (ConOps), which will be used to guide both experimental planning and iterative ISS prototype development and testing. The ConOps must include, but is not limited to, the following items:

Safety Assessment. The Contractor must identify a set of proposed high priority intersection safety needs through structured interaction with the public sector partner. Evidence supporting the rationale for these high priority safety needs must be documented, using available safety data, crash and/or conflict records, detailed intersection sensor data (including camera data, where available), and feedback/insight from safety engineers or other transportation professionals associated with, employed by, or supporting the public sector partner. While there may be a diverse range of intersection safety issues, there may be specific unsafe situations and specific conflict types where an ISS has the best potential to make a meaningful impact. The assessment should focus on identifying conditions, situations, and scenarios that represent high-priority safety issues wherein an ISS has the potential to result in improved and measurable intersection safety when deployed in an operational setting. The assessment should provide a systematic tradeoff analysis of safety needs and ISS potential in the development of structured use cases, as well as the ability to practically re-create and test these use cases in a closed testbed. The safety assessment must also include a high-level assessment of potential congestion impacts resulting from an ISS deployment (e.g., a reduction in congestion from the prevention of crashes and/or improvements to dynamic signal control resulting from ISS data).

NOTE: While the development of use cases must be driven by public sector partner needs, the Government is particularly interested in ISS prototypes capable of improving safety in intersections/operational conditions informing the potential for nationwide deployment, including but not limited to:

· intersection geometrics/attributes correlated with high rates of fatal crashes nationwide

· low visibility (e.g., because of night/fog/weather/lighting conditions),

· variable and/or atypical pedestrian/other road user demand,

· variable vehicle demand (in terms of both volume and vehicle size/type), and

· variable vehicle operating speeds.

Use Case Development. The ConOps documents the specific high-priority real-world problems or challenges that the ISS prototype will address. The ConOps must describe the types of unsafe conditions and conflicts that will be the focus of the ISS prototype, and how operational practice will be altered based on the introduction of these applications (even though in Phase 1, the ISS will be deployed only in a Contractor-provided closed testbed). The ConOps must identify and detail the specific use cases relevant to the ISS prototype operations, specifically the use cases wherein unsafe conditions and/or individual conflicts are expected to be predicted and mitigated.

ISS Prototype Methods and Actions. The ConOps must include a schematic context diagram illustrating a high-level physical description of the proposed system. The ConOps must describe the proposed mechanisms and methods the prototype ISS will use to identify and predict unsafe conditions and conflicts in these use cases, as well as the complete range of proposed mitigating actions potentially taken by an ISS to improve safety. Note that these proposed methods of prediction and mitigating actions, taken by an ISS in response to the identification or prediction of unsafe conditions or individual conflicts within the prescribed use cases, will form the foundation for both Prototype Development (Task 1-4) and the Test Plan Development (Task 1-3) used to test and develop the prototype system. The ISS prototype concept and the proposed methods and actions should be placed into the context of relevant ITS architectures and standards.

NOTE: The prototype ISS, where possible, should comply with all applicable ITS standards, architectures, and protocols as defined or recognized by the USDOT. This includes, but is not limited to, adherence to the National ITS Architecture (ARC-IT), relevant Society of Automotive Engineers (SAE), Institute of Electrical and Electronics Engineers (IEEE), and National Transportation Communications for ITS (Intelligent Transportation Systems) Protocol (NTCIP) standards.

ConOps Walkthrough. The Contractor must schedule and conduct a virtual walkthrough of the draft ConOps. The Contractor must develop a walkthrough workbook to structure and expedite the walkthrough process. This walkthrough will be conducted either in-person in Washington, DC, at a USDOT-designated facility that supports a webinar function, or as a completely virtual meeting. If conducted in-person, all Contractor key personnel must attend in person, or as directed by the COR.

The Contractor must revise the ConOps in response to USDOT comments and deliver a revised ConOps and a companion comment resolution log, showing how comments were resolved. Based on COR approval of the revised ConOps and comment resolution log, the Contractor must deliver a final ConOps.

Task 1-2 Required Deliverables

· ConOps Walkthrough Workbook

· ConOps Walkthrough

· ConOps (Draft/Revised/Final)

· ConOps Comment Resolution Log (Revised and Final)

Task 1-3: Test Plan Development In this task, the Contractor must develop a Test Plan focusing on the high-priority use cases, scenarios, and operational conditions documented in the ConOps. The due date for the Test Plan will be provided by the Contractor when their PMP and corresponding deliverable schedule is submitted. Note that all experimentation must occur in a closed testbed in Phase 1. As a result, the Test Plan must describe how the closed testbed will be configured and utilized to address the high-priority use cases, scenarios and operational conditions.

The Contractor must document a set of experiments in the closed testbed wherein the ISS prototype will be tested after reaching some minimum viable/testable state. Note that the Test Plan must reflect the Phase 1 Key Research Questions (above), potentially building from simpler experiments to more complex experiments as the ISS prototype is iteratively developed and tested in Task 1-4.

NOTE: Contractors must be able to perform all tests in the designated closed testbed based on their approved detailed Test Plan. The closed testbed must have internal logging capabilities that are sufficient to collect data for conducting evaluation/analysis of key performance measures, as described in the Test Plan.

IRB Feedback. A description of the proposed experimentation is required to inform a Contractor-provided Human Use Approval (HUA)/Institutional Review Board (IRB) process to protect human subjects participating in the testing of the ISS prototype. The Contractor must document the requirements of the proposed HUA/IRB process, the description of the experiment, and the feedback/approval received from the IRB process in a HUA/IRB Summary.

NOTE: The Contractor must not perform experiments prior to HUA/IRB approval.

Test Plan. Incorporating any/all feedback from the HUA/IRB process, the Contractor shall prepare a detailed Test Plan, including a summary of how experimentation is integrated/coordinated with ISS prototype development. Note that the Test Plan must demonstrate a link to the high-value use cases documented in the ConOps and composed of a series of sequential or iterative experiments central to testing/answering the Phase 1 Key Research Questions (see above). The Test Plan must contain all required elements and follow the structured format identified in Exhibit A: ISS Prototype Test Plan Requirements, attached to this PWS.

NOTE: Additional information regarding the format of the Test Plan may be provided at or after the kickoff meeting, as required.

The Test Plan must establish a set of milestones/checkpoints to track development progress (and issues encountered), and how progress and findings to date will be documented and shared with the COR/Federal expert team at a minimum cadence of every two weeks.

The Contractor must revise the draft Test Plan in response to USDOT comments and deliver a revised Test Plan and a companion comment resolution log, showing how comments were resolved. Based on COR approval of the revised Test Plan and comment resolution log, the Contractor must deliver a final Test Plan.

Task 1-3 Required Deliverables

· Human Use Approval/Internal Review Board Summary (draft/final)

· Test Plan (draft/revised/final)

· Test Plan Comment Resolution Log (revised/final)

Task 1-4: Iterative Prototype Development and Testing In this task, the Contractor must execute the Test Plan developed in Task 1-3 of the potential iterative ISS prototype development. Experimental results and progress in prototype development are delivered every two weeks while this task is active in the period of performance in the form of Checkpoint Summary Reports, summarizing insights obtained, progress made, challenges encountered, and actions taken to overcome these challenges. The delivery of these reports must be coordinated with the cadence of the bi-weekly meetings to ensure the Government has sufficient time to review reports prior to meeting. Depending on test results, modifications to the Test Plan may be required. If so, the Contractor must update the Test Plan, as necessary, to ensure that the Checkpoint Summary Reports can be placed in an accurate experimental context.

NOTE: No activity in Task 1-4 may commence without Government acceptance of both the final ConOps document (Task 1-2) and the final Test Plan (Task 1-3).

Task 1-4 Required Deliverables

· Checkpoint Summary Reports (per Test Plan), bi-weekly

· Updated Test Plan (as required)

Task 1-5: Demonstrate Prototype In this task, the Contractor must demonstrate, in a closed testbed, the ISS prototype detecting, predicting, and mitigating unsafe conditions and/or individual conflicts consistent with one or more of the high-value use cases drawn from the ConOps (Task 1-2). This demonstration is intended to show the nature and timing of strategies used to address unsafe conditions and mitigate individual conflicts, as well as the overall progress in developing the ISS prototype.

The Contractor team is required to demonstrate the ISS operating in real-time within the Contractor-provided closed testbed for a delegation of USDOT subject matter experts (SME). The demonstration must be scheduled to take place over a maximum of two consecutive business days, including a pre-demonstration session, a series of demonstrations, and a post-mortem session where the performance of the ISS prototype in the demonstration will be discussed. The Contractor must prepare a Demonstration Summary that includes the description of intended demonstration (as briefed in the pre-demonstration session), a concise annotated timeline of the performance of the ISS in the demonstration versus the intended plan, and a summary of the post-mortem discussion. Note that the demonstration is NOT intended to be a public event showcasing the ISS, but rather a technical session wherein the capabilities of the ISS prototype are featured for the COR and Government experts.

Task 1-5 Required Deliverables

· Demonstration Summary (draft/revised/final)

· Demonstration Summary Comment Resolution Log (revised/final)

Task 1-6: Operational Readiness Summary Based on the results obtained in the experimentation testing and demonstration, the Contractor team must assess the Operational Readiness of their ISS prototype in an Operational Readiness Summary report. The summary report assesses the ISS prototype’s potential in detecting, predicting, and mitigating unsafe conditions and individual conflicts in the high-value use cases drawn from the ConOps (Task 1-2). The Contractor must provide a high-level overview of the ability of the prototype ISS to be deployed and refined in a potential Phase 2. In particular, the Contractor must note any predicted variances (additions and subtractions) from the Phase 2 vision presented in their proposal.

Task 1-6 Required Deliverables

· Operational Readiness Summary (draft/final)

· Operational Readiness Summary Comment Resolution Log (revised/final)

Task 1-7: Code/Data Sharing In this task, the Contractor must develop a Code/Data Plan (C/DP) that includes sections on Data Privacy, Code/Data Management, and Code/Data Sharing. The C/DP documents how data and code will be collected, integrated, managed, and disseminated in Phase 1. The C/DP documents the data and code intended to be shared at the completion of Phase 1. This task also includes the delivery of appropriately documented data and code for inclusion in public repositories.

NOTE: The Government acknowledges the sharing of some code and data has potential implications for revealing prior Intellectual Property (IP) brought to this effort by the Contractor. The Contractor is expected to make a best effort to provide data and code to the broader research community. The extent to which this is possible is documented in the C/DP, a document that the Contractor is responsible for delivering. The government intends to negotiate specific terms related to IP prior to award.

When developing the C/DP, Contractors must review the USDOT’s current Privacy Policy[footnoteRef:2] and Public Access Plan[footnoteRef:3] to ensure information in both reports is included where appropriate in the C/DP. [2: https://www.transportation.gov/individuals/privacy/dot-privacy-policy] [3: https://www.transportation.gov/mission/open/official-dot-public-access-plan-v11]

The Government seeks to share the software development, enhancements, alterations, or adaptations of this effort, that are developed using Federal funding, with the research community. Existing applications brought to the deployment need not be made open source. Open-source software and supporting documentation must be clearly identified within the C/DP. Publicly posting all identified open-source software and supporting documentation is a deliverable in this task.

NOTE: Details regarding limitations, extent and nature of making code open source will be negotiated prior to award.

Data Privacy. Improper handling of Personally Identifiable Information (PII) or Sensitive Personally Identifiable Information (SPII) by a Contractor could have significant adverse impacts on the privacy of individuals. For this reason, the USDOT is committed to ensuring that the Contractor institutes sufficient data privacy controls to mitigate the risk of harm to individuals that would result in the improper handing or disclosure of the PII and SPII collected from individuals in connection with a USDOT-funded deployment project. The privacy section of the C/DP should be consistent with the ConOps and the HUA/IRB approved Test Plan.

Data Management. The C/DP serves as an operational guide for managing data collectively as a strategic asset, and, subject to applicable privacy, security, and other safeguards, making data available to enable transparent system performance measurement and evaluation to fuel entrepreneurship, innovation, and economic development. The data management section must document the flow of data from generation through its use in the ISS prototype, including, but not limited to:

· Data sources and destinations,

· Volume of data flow,

· Contents of data flow,

· Communications medium involved, and

· Long term storage plans.

The data management section must include the plan for identifying, collecting, and managing data; assess the variety, volume, and velocity (frequency of collection) of data; and identify data gaps and approach for addressing the gaps. This section must also include metadata to provide appropriate context (including qualitative observations) for data collection. This section must include the plan for identifying, collecting, and managing deployment-related data. The plan must establish consistent and systematic quality control procedures.

Code/Data Sharing. Appropriately prepared system control, performance, and evaluation data, stripped of PII, are expected to be made available to the USDOT and posted in timely fashion on public-facing resources, freely available to the public and research community. Data sharing is subject to the protection of intellectual property rights and personal privacy and must be handled securely. The USDOT envisions that this data sharing capability will support the needs of ITS researchers and developers while encouraging nationwide deployment replicability by reducing costs and encouraging innovation. Hence, in this section of the plan, the Contractor must identify all appropriate data and processes (including privacy-related processes) to be utilized in enabling the progress of data from collection to processing and documentation to a public-facing repository. Note that all data made available on public-facing resources must adhere to guidelines on preparation for submission and accompanying metadata, e.g., as exemplified the following links for ITS Datahub and Code submissions:

https://its.dot.gov/data/data-submission/ and https://www.its.dot.gov/code/code-submission/.

The Contractor must deliver a draft C/DP to the USDOT for review. The Contractor must revise the plan in response to USDOT comments and deliver a revised C/DP and a companion comment resolution log, showing how comments were resolved. Based on COR approval of the revised plan and comment resolution log, the Contractor must deliver a final C/DP. The Contractor must then deliver documented data and code per the final C/DP prior to the end of the period of performance.

Task 1-7 Required Deliverables

· Code/Data Plan (draft/final)

· Code/Data Plan Comment Resolution Log (revised/final)

· Documented Data and Code, including supporting documents and metadata (per the C/DP)

PHASE 2: PROTOTYPE REFINEMENT AND ASSESSMENT (OPTIONAL)

The objective of this phase is to refine an ISS prototype by deploying tailored systems based on the prototype, in multiple real-world intersections. After installation in real-world intersections, the ISS prototype systems will be deployed for observation only and will collect data, predict conflicts, and identify/anticipate unsafe conditions. Initially, the deployed ISS will not be used to mitigate conflicts in real-time. Selected conflict scenarios, observed in the ISS observe-only deployments, will be approximated in a closed testbed to assess the practicality and potential benefit of real-time mitigation.

If convincing evidence is identified that some or all potential real-time mitigating actions can be introduced in an operational state in some or all deployed ISS locations with acceptable risk, then real-time mitigation may be introduced. The Contractor is responsible for maintaining a working memorandum describing the operational conditions, mitigation types, and deployment locations under which real-time mitigation will occur.

Based on the results obtained from both continued refinement in the closed testbed and the performance of the ISS prototype deployed in real-world intersections, the Contractor assesses the potential of the ISS for scaled deployment in a summary report. Finally, Contractor teams share data and code from their experiments according to the Test Plan. The Government may issue supplemental Test Plan Guidance for Phase 2, if deemed necessary.

In Phase 2, the Government seeks an ISS prototype with the following attributes:

· Rapidly installed and calibrated for operation in real-world intersections

· Issues warnings and mitigates unsafe conditions, enhanced through iterative testing/refinement in a closed testbed utilizing data collected from observe-only ISS prototypes deployed in real-world intersections

· Based on Phase 2 testing and the performance of the ISS prototype deployed in real-world intersections, the prototype demonstrates significant potential for scaled deployment operationalizing effective real-time mitigation strategies.

Phase 2, Key Research Questions:

· Can real-time mitigation be safely introduced at an intersection?

· Under what conditions can these be introduced?

· What kinds of mitigations can be demonstrated to improve safety?

· Is the ISS prototype potentially cost-effective?

· If so, under what conditions?

· Is broader ISS deployment feasible and/or desirable based on the performance of the ISS prototype?

PHASE 2 TASK STRUCTURE:

· Task 2-1: Project Management

· Task 2-2: Site Engagement and ISS Prototype Deployment

· Task 2-3: Operational Scenario Generation

· Task 2-4: Prototype Refinement and Testbed Validation

· Task 2-5: Field Deployment and Demonstration

· Task 2-6: Deployment Readiness Summary

· Task 2-7: Code and Data Sharing

Task 2-1: Project Management Activities under this task shall include, but are not limited to, overall project execution; scope, schedule, cost, quality, procurement, and configuration management; risk management; and coordination efforts. These activities will encompass conducting a kickoff meeting, preparing monthly progress reports, and facilitating regular status updates and coordination meetings. This task is a continuation of the Phase 1 Program Management activity, maintaining objectives, activities, and scope largely consistent with Phase 1.

Phase 2 Kickoff Meeting. Within 4 weeks of Phase 2 commencement, the Contractor must schedule and attend a Phase 2 kickoff meeting to ensure that all parties understand the contract requirements and expectations for Phase 2, and a summary of background and findings from Phase 1. The meeting may occur at the USDOT in Washington DC, or at a Contractor-identified site. If held in Washington DC, travel costs to attend the kickoff meeting must be limited to key personnel only unless otherwise approved by the CO. A virtual meeting option will be made available for remote participation by additional Contractor team members, as needed. A virtual meeting may replace the in-person kickoff, subject to COR approval.

Monthly Reporting. The Contractor must submit a monthly report detailing accomplishments and deliverables completed in the reporting period, identify key actions to be taken in the next reporting period, and assess overall project performance with respect to project schedule and cost. The monthly report must also include a description of all project risks, and actions taken to mitigate or eliminate these risks.

Bi-Weekly Site-Specific Coordination Teleconferences. The USDOT requires the Contractor to organize and participate in a site-specific bi-weekly deployment coordination teleconference with the COR and federal team members to review work in progress, identify issues and risks, and coordinate technical assistance. At a minimum, the site key personnel and other relevant team members as appropriate for topic discussions should participate in these meetings.

Task 2-1 Required Deliverables

· Phase 2 Kickoff Meeting

· Project Management Plan (revised)

· Monthly Progress Reports

· Agenda/Notes from Bi-weekly Coordination Teleconferences

Task 2-2: Site Engagement and ISS Prototype Deployment In this task, the Contractor must engage with public sector partners and other relevant authorities with jurisdiction over proposed ISS prototype deployment locations. The focus of this task is to identify, assess, and secure pilot deployment locations for the ISS prototype.

The number of deployment locations must be sufficient to demonstrate the capability of the proposed ISS concept and its potential impact on roadway safety. The number and type of deployment intersections must also illustrate the capability of the proposed system to be deployed rapidly at relatively low cost in multiple locations.

NOTE: The ISS Prototype must be deployed at a minimum of two intersection locations in Phase 2.

The Contractor shall develop a Site Engagement and Deployment Plan for integrating the ISS prototype at the selected sites. This plan must:

· Address site-specific constraints and obtain all necessary permits and approvals.

· Ensure seamless integration with existing infrastructure, including traffic control systems and public safety operations.

· Comply with all legal, ethical, and regulatory requirements, including data privacy, security, and information-sharing policies.

NOTE: USDOT reserves the right to reject proposed intersection types or request revisions based on suitability, feasibility, safety considerations, or alignment with program objectives.

Following the completion of site selection and planning, the ISS prototype systems must be deployed for observation only at the identified locations. The Contractor must document all site engagement activities, deployment plans, and progress updates. A written Deployment Report summarizing observe-only deployment activities, challenges, and resolutions shall be maintained and updated regularly. Deployment progress must be reviewed and discussed in bi-weekly status meetings until all observe-only deployments are successfully completed.

Task 2-2 Required Deliverables

· Site Engagement and Deployment Plan (draft/revised/final)

· Site Engagement and Deployment Plan Comment Resolution Log (revised/final)

· Bi-Weekly Site Engagement and Deployment Progress Summaries (bi-weekly throughout the period of performance in Phase 2 until all deployments are completed)

Task 2-3: Operational Scenario Generation Following installation, the observe-only ISS deployments will collect data on intersection activity, detecting and predicting unsafe conditions and potential conflict scenarios. At this stage, the ISS prototype will operate in a passive mode, meaning it must not actively mitigate conflicts in real time. Instead, the ISS prototype will serve as a data-gathering tool to identify recurring safety risks and evaluate the feasibility of intervention strategies.

In this task, the Contractor must analyze data from these deployments to identify, classify, and document real-world unsafe conditions and conflict scenarios. Selected scenarios will be approximated in a closed testbed to assess the conceptual feasibility, relevance, and expected benefit of potential real-time mitigation strategies. This preliminary assessment is intended to validate the operational scenario design and the rationale behind the strategies, rather than to provide a full performance evaluation of the ISS prototype. The Contractor must deliver a Closed Testbed Scenario Approximation Report documenting these preliminary assessments, including methods used, assumptions, rationale behind selected scenarios, observed outcomes, and recommendations for refinement prior to more advanced integration and testing.

To ensure comprehensive testing, the Contractor must:

· Develop a methodology for translating real-world observations into structured Operational Scenarios.

· Define key scenario parameters, including operational conditions, traffic dynamics, and risk factors.

· Develop operational scenarios involving human subjects, where applicable, and ensure full compliance with all HUA and IRB processes to safeguard the rights and well-being of participants.

· Document all findings, including lessons learned and refinements needed for future iterations.

The Contractor must deliver a portfolio of Operational Scenarios derived from ISS data collected across real-world intersections. This portfolio will serve as a foundational reference for operational scenarios for evaluating and enhancing the ISS prototype’s real-time response capabilities, including its integration with human factors considerations.

Task 2-3 Required Deliverables

· Operational Scenario Entry (draft/final), per identified scenario

· Closed Testbed Scenario Approximation Report (draft/final), per identified scenario

· Operational Scenario Portfolio Comment Resolution Log (revised/final)

· Operational Scenario Portfolio (draft/final)

Task 2-4: Prototype Refinement and Testbed Validation In this task, the Contractor utilizes the Operational Scenarios identified in Task 2-3 to evaluate and refine the real-time mitigation responses of the ISS prototype. The focus of this task is on system performance, including response effectiveness, accuracy, timing, robustness, and operational constraints. The refinement process is conducted entirely in a closed testbed, where the ISS prototype is tested against selected scenarios to assess its effectiveness in detecting and mitigating unsafe conditions before any real-world deployment.

As part of this task, the Contractor must develop a Mitigation Response Validation Plan. This plan defines the validation approach, test methodology, sequencing, pass/fail criteria, and the qualitative and quantitative performance metrics that will be applied to evaluate the ISS mitigation strategies. The plan must describe how each selected scenario will be instantiated in the closed testbed, the data collection methods, instrumentation requirements, and criteria for determining whether the system's mitigation response is correct, timely, and appropriate.

Upon completion of testing, the Contractor must provide a Mitigation Response Evaluation Report summarizing mitigation response results, measured performance outcomes, and any deviations or observed limitations. The report will also document recommendations for refinement of the ISS mitigation strategies.

The interaction between Task 2-3 (Scenario Generation) and Task 2-4 (Prototype Refinement) is expected to be iterative, as additional real-world scenarios are identified, analyzed, and incorporated into the testing and refinement process. The ISS prototype will undergo multiple rounds of testing, ensuring continuous improvements before its readiness for field deployment in a later task.

To ensure a rigorous and structured evaluation, the Contractor shall:

· Translate Operational Scenarios into closed tested experiments to systematically test ISS prototype performance.

· Assess the ISS prototype’s real-time mitigation strategies, refining system responses based on closed testbed experimental outcomes.

· Iteratively adjust prototype software, hardware, and mitigation strategies to enhance system reliability and effectiveness.

· Conduct human factors assessments, ensuring the mitigation strategies are practical, safe, and aligned with road user behavior.

· Document all experiments, refinements, and outcomes in a Prototype Refinement Result Summary, which will be appended to a Results Portfolio throughout the iterative testing and refinement process.

The Contractor must deliver a comprehensive Refinement Results Portfolio, capturing the ISS prototype’s iterative refinements based on controlled testing in the closed testbed. These findings will inform subsequent tasks, including deployment readiness assessments and field demonstration in later phases of the project.

Task 2-4 Required Deliverables

· Mitigation Response Validation Plan (draft/final)

· Mitigation Response Evaluation Report (draft/final)

· Prototype Refinement Results Portfolio (draft/final), at the completion of each experiment

· Prototype Refinement Results Portfolio Comment Resolution Log (revised/final)

· Prototype Refinement Results Portfolio (revised/final)

Task 2-5: Field Deployment and Demonstration Following the intersection deployments and site readiness activities completed under Task 2-2 and the closed testbed validation completed under Task 2-4, the Contractor must conduct field testing of the ISS prototype with real-time mitigation capabilities enabled, where appropriate. Real-time mitigation must only be activated when convincing evidence demonstrates that specific mitigation actions can be deployed with acceptable risk in one or more ISS deployment locations.

The Contractor must also prepare a Field Deployment and Demonstration Plan detailing the objectives, deployment timeline, test configurations, data collection approach, safety precautions, and success criteria for activating real-time mitigations in the field.

The Contractor is responsible for maintaining a working memorandum describing the operational conditions, mitigation types, and deployment locations under which real-time mitigation will occur. The working memorandum requires the explicit concurrence of the public sector partner with jurisdictional control of the intersections where real-time mitigation is introduced. The working memorandum must be accepted by the COR before real-time mitigation is introduced in any deployed intersection.

In this task, the Contractor must document the performance of the ISS prototype detecting, predicting, and mitigating unsafe conditions and/or individual conflicts consistent with the conditions of the Real-Time Mitigation Working memorandum.

The Contractor must monitor and maintain the operational prototype, providing detailed documentation of:

· pre-mitigation operational conditions,

· system state and logic leading up to the mitigation action,

· the sequence of events during and after mitigation, and

· any anomalies, deviations, or unexpected behaviors.

The Contractor must prepare an Operational Impact Summary that provides:

· a concise annotated timeline of ISS performance in operational conditions,

· deviations from expected behaviors,

· an assessment of the safety impact of ISS mitigation actions, and

· after-action recommendations for further improvement of the ISS prototype.

Task 2-5 Required Deliverables

· Field Deployment and Demonstration Plan (draft/revised/final)

· Real-Time Mitigation Working Memorandum (draft/revised/final)

· Operational Impact Summary (draft) at the completion of each implementation

· Operational Impact Report (draft/revised/final)

· Operational Impact Report Comment Resolution Log (revised/final)

Task 2-6: Deployment Readiness and Transition Planning Based on the results obtained in testing in the closed testbed and field deployment, the Contractor must assess the deployment readiness of the ISS prototype. This assessment will be documented in a Deployment Readiness Summary Report, which will evaluate the ISS prototype’s effectiveness and potential for broader deployment. The report will specifically focus on the prototype’s ability to detect, predict, and mitigate unsafe conditions and/or individual conflicts in real-world intersections.

In this task, the Contractor must:

· Analyze the results from conducted tests to determine the ISS prototype’s readiness for full-scale deployment in diverse real-world conditions.

· Evaluate the system’s readiness in key areas, such as its accuracy in detecting unsafe conditions, the effectiveness of its predictive algorithms, and the reliability of its mitigation strategies.

· Assess the feasibility and potential of the prototype to be deployed at-scale in intersections across the nation, including integration considerations with existing intersection control infrastructure.

· Identify any outstanding gaps or limitations in the prototype’s capabilities and recommend further refinements or testing necessary to achieve full…