request for letters of intent v2i queue advisory/warning ......2018/10/02 · request for letters...

Request for Letters of Intent

V2I Queue Advisory/Warning Applications: Concept and Design

October 9, 2018

Issued by

University of Virginia Center for Transportation Studies Charlottesville, Virginia

On Behalf of

Connected Vehicle Pooled Fund Study

1

I. GENERAL INFORMATION REQUEST FOR LETTERS OF INTENT (RFLI) NAME V2I Queue Advisory/Warning Applications: Concept and Design The RFLI along with the Appendixes have been posted on the Connected Vehicle Pooled Fund Study (CV PFS) website (http://www.cts.virginia.edu/cvpfs/) for your information. Addenda will be posted on this website if issued. It is the responsibility of interested parties to ensure that the latest version of the entire RFLI and related links are reviewed prior to submission of a letter of intent. We encourage you to check the website frequently for any changes prior to the due date. For ease of reference, each firm or individual receiving this RFLI is referred to as an “interested party” and the firm or individual selected as a potential partner of the University of Virginia Center for Transportation Studies (UVA CTS) and the CV PFS is referred to as the “preferred subcontractor”. This RFLI states the instructions for submitting letters of intent, and the procedure and criteria by which a preferred subcontractor may be selected. RFLI SCHEDULE

• Issue Date: October 9, 2018

• RFLI Questions: Any questions or requests for necessary additional information concerning this RFLI must be emailed to the UVA CTS listed below no later than 3:00 p.m. ET on October 19, 2018 in order to guarantee a timely response prior to the letter of intent due date.

• Letters of Intent Due Date: 3:00 p.m. ET on November 6, 2018. One electronic file

(up to 10MB), including a Letter of Intent and all supporting material, must be sent to the UVA CTS via email using the contact information in the box below. The UVA CTS reserves the right to reject letters of intent received after the stated due date and time.

• Expected Subcontract Start Date: January 2019 o Term: For eighteen months o Level of Effort: $400,000 o The contract will be a firm fixed price agreement.

REFER ALL QUESTIONS TO: University of Virginia Center for Transportation Studies

Attention: Hyungjun Park Phone: 434-924-1651

Email: [email protected]

2

PROCEDURE It is important to note that preparation and submission of a letter of intent (for detailed contents, see Section IV. Contents of the Letter of Intent), in response to this RFLI, is completely voluntary, without any bearing on contractual obligations. In case none of the submitted letters of intent is satisfactory to CV PFS team’s expectation, the CV PFS team may opt not to establish a subcontract. The purpose of this RFLI is to identify a potential partner that may work, as a subcontractor, with the CV PFS and the UVA CTS on the project outlined in this RFLI. Once all the letters of intent are received, the below procedure will be followed:

1. The CV PFS team members will evaluate the letters of intent (including a signed cover letter, a proposal, and a budget) submitted in response to the RFLI to identify an interested party that best meets CV PFS’s needs as a preferred subcontractor;

2. Once a preferred subcontractor is identified, the CV PFS and the selected preferred subcontractor will conduct negotiations to come to an agreement on the scope and budget of a subcontract; and

3. Finally, a formal subcontract will be established through the University of Virginia Office of Sponsored Programs and the preferred subcontractor officially becomes the subcontractor. Note that the total duration, during which the contractual documents stay within the subcontractor for review and negotiation, shall not exceed 30 business days. If the process conducted by the subcontractor takes longer than 30 business days, the CV PFS may cancel the project and/or move to the next best interested party for negotiation.

II. BACKGROUND INFORMATION CONNECTED VEHICLE POOLED FUND STUDY The project detailed in this RFLI is intended to investigate “V2I Queue Advisory/Warning Applications: Concept and Design” for the CV PFS entitled “Program to Support the Development and Deployment of Connected Vehicle Applications.” This CV PFS was created by a group of state, local, and international transportation agencies and the Federal Highway Administration (FHWA), with the Virginia Department of Transportation (VDOT) serving as the lead agency. The UVA CTS is supporting VDOT on the pooled fund study, serving as the technical and administrative lead for the effort. For more information about the pooled fund study, please visit http://www.cts.virginia.edu/cvpfs/. Since 2011, CV PFS and the United States Department of Transportation (USDOT) have been collaborating to develop and demonstrate the Multi-Modal Intelligent Traffic Signal Systems (MMITSS) under the Dynamic Mobility Application Program of USDOT. The Phase 1 (Development of Concept of Operations, System Requirements, System Design and a Test Plan) and the Phase 2 (System Development, Deployment and Field Test) of the MMITSS projects were completed. Currently, the MMITSS Phase 3 (Deployment Readiness Enhancement) is under way. Also, as an extension to these MMITSS efforts, CV PFS and USDOT is sponsoring the “Connected Traffic Control System: Research Planning and Concept Development” project

3

together to conduct the foundational research for the future traffic control systems under the upcoming connected vehicle environment. For all these projects, USDOT provides CV PFS with funds and the CV PFS team provides additional matching funds. Finally, UVA CTS manages all these projects on behalf of CV PFS and USDOT. The “V2I Queue Advisory/Warning Applications: Concept and Design” project outlined in this RFLI is another collaboration effort between CV PFS and USDOT. BACKGROUND The USDOT Intelligent Transportation Systems Joint Program Office (ITS JO) Vehicle-Infrastructure (V2I) Program has been engaged in research to integrate infrastructure-based technologies into connected systems to optimize the safety and mobility performance of the transportation network. Part of this effort focuses on application research and prototyping to explore feasibility and performance, as well as cross-cutting design considerations such as communications and standards. Under cooperative agreement with FHWA, the Crash Avoidance Metrics Partners, LLC (CAMP) V2I Consortium is developing and testing a prototype mechanism to enable Event-Driven Configurable Messaging (EDCM) that allows vehicle-based systems to provide selective real-time data reports to infrastructure systems (traffic management centers), which can request enhanced details based on dynamic conditions and needs. EDCM may include dynamically adjusting rate, frequency, content of vehicle-based data provision to infrastructure. The current phase of CAMP’s effort, referred to here as the “CAMP EDCM Project”, will develop architecture and prototype the application of EDCM initially in contexts such as Work Zones, Road Weather Hazards and with respect to V2I Queue Advisory/Warning applications. The project outlined in this RFLI is intended to complement and interact significantly with portions of the CAMP EDCM Project, particularly in the application of EDCM concepts to the V2I Queue Advisory/Warning topic area, and there is the expectation that the CAMP EDCM project will also provide substantive input for this project from the vehicle perspective. Queue Advisory/Warning System Review This section provides an overview of queue advisory/warning, largely with respect to prior work conducted as part of the INFLO (Intelligent Network Flow Optimization) project conducted by USDOT (See https://www.its.dot.gov/research_archives/dma/bundle/inflo_plan.htm and https://www.its.dot.gov/research_archives/dma/dma_pubs.htm). This project is intended to utilize the queue warning research and findings from INFLO as a starting point; however, this project is not limited to the scope or approach in INFLO. The objective of queue warning is to provide a vehicle operator sufficient warning of impending queue backup in order to brake safely, change lanes, adjust speed or modify route such that secondary collisions can be minimized or even eliminated. Additionally, it will improve mobility and reduce vehicle idling. A queue backup can occur due to a number of conditions, including:

• Daily recurring congestion caused by bottlenecks • Work zones, especially the ones which cause bottlenecks • Incidents, which, depending on traffic flow, lead to bottlenecks

4

• Weather conditions, including icing, low visibility, sun angles, and high wind • Exit ramp spillovers onto freeways due to surface street traffic conditions • At traffic signals

In all cases, queuing is a result of significant downstream speed reductions or stopped traffic and can occur with freeways, arterials, and rural roads. Queuing conditions present significant safety concerns; in particular, the increased potential for rear-end collisions. They also present disruptions to traffic throughput by introducing shockwaves into the upstream traffic flow. A queue warning (referred to as “Q-WARN” in INFLO) application will be successful at minimizing both primary and secondary rear-end collisions and the resulting traffic flow shockwaves by being able to:

• rapidly detect the location, elapsed time/expected dissipation time, and length of a queue propagation,

• formulate an appropriate response plan for approaching vehicles, and • disseminate such information to the approaching vehicles readily and in an actionable

manner. Queue Warning applications have been in place for some time both nationally and internationally. The distinction between different queue warning applications does not only come from the use case but also in terms of data sources and types, logic for determining queues, and how queue information is disseminated. The key approaches for designing queue warning applications are briefly discussed below. Infrastructure-Based Queue Warning Application These are queue warning applications that are developed using aggregated data from infrastructure/road sensors installed by a transportation agency along the roadside. These sensors could be intrusive or non-intrusive. Intrusive roadway sensors are those that are embedded in the pavement, embedded in the subgrade of the pavement, or adhered to the surface of the roadway. Vehicles are detected by passing over the sensor. Examples of these sensors include loop detectors and magnetometers. Non-intrusive sensors are those which are mounted either above or adjacent to the roadway. Examples of these types of sensors include video image processors, microwave radar, ultrasonic, and passive infrared sensors. Data elements such as aggregated speed, occupancy, and volume (i.e., traffic flow measures) are generated by these sensors and transmitted in near-real time to a Traffic Management Center (TMC) for processing. Based on these traffic flow measures (especially speed and occupancy), algorithms are developed to determine the presence of a queue, the length of queue, and the back of queue. Depending on local traffic conditions, user-defined speed and occupancy thresholds are established to allow for automatic generation of queue warning alerts/messages when these thresholds are exceeded. Queue Warning alerts/messages are typically sent to drivers/motorists 1-2 miles upstream of the back of queue through Variables Message Signs (VMS)/Dynamic Message Signs (DMS) and flashers mounted on static signs. An important feature of infrastructure-based queue warning application is that it can be proactive—utilizing its broader visibility into the traffic state to predict likely queue formations. A TMC can predict, using data collected over a period of time and over a geographical area, the

5

location, length, duration, and likelihood of a queue forming. This allows for preemptive actions to be taken to either minimize the impact or prevent the formation of a vehicle queue. However, infrastructure-based queue warning applications are fundamentally limited in their potential range, scope, and precision of queue detection due to many factors such as large spacing between detectors/sensors, limited distribution of sensors/detectors (i.e., lack of continuous coverage) and others. Additionally, locating queue warning signs at positions sufficiently upstream of the queue condition is critical to allow drivers enough time to react safely. However, because the queue warning signs are fixed infrastructure and because queue conditions can shift along a road facility, the effectiveness of any queue warning program is constrained by how well queue conditions align with the positioning and distribution of queue warning signs. The infrastructure-based queue warning application is the most widely used approach in the United States and around the world. A review of past and most recent deployments can be found at https://rosap.ntl.bts.gov/view/dot/3380 and http://enterprise.prog.org/Projects/2010_Present/iwz/QueueWarning_Summary_FINAL_June2014.pdf. Vehicle-Based Queue Warning Application (mostly based on INFLO Q-WARN concepts) A vehicle-based queue warning algorithm uses Connected/Autonomous Vehicle (CAV) data only. In this approach, a CAV is able to determine whether or not it is in a queued state based on its own Basic Safety Message (BSM) and pre-determined thresholds. For example, the 2010 Highway Capacity Manual defined a queued state as a condition when a vehicle is within one car length (20 ft.) of a stopped vehicle and is itself in a stopped state (i.e., has slowed to speed of less than 5 mph). Using this definition, two conditions in the HCM must be satisfied in order for the CAV to declare itself to be in a queued state:

• The instantaneous speed of the vehicle must be measured to below a predefined queued state speed threshold, and

• The separation distance (or gap) between itself and the vehicle immediately downstream must be less than a predefined separation distance threshold.

The CAV can send its BSM, queued state information, and mile marker location to upstream vehicles or to Roadside Equipment (RSE) which are within its communication range (conceptually, future variations beyond INFLO may explore a variety of communications). An algorithm developed based on the CAV data then places the CAV into the appropriate road section and determines the queued state of the road section. The queued state of the road section is determined based on the percentage of queued CAVs to non-queued CAVs in a road section which can be user defined. Based on the queued state of the road section, the front of queue and the back of queue are determined for every queue that is detected in the segment. Based on the location of the back of queue, the speed in queue, length of queue, as well as rate of growth of queue can be calculated. This information is then transmitted to the CAVs upstream of the back of queue via cellular communication or DSRC communication as Infrastructure to Vehicle (I2V) or Vehicle to Vehicle (V2V) messages/alerts. One advantage of queue information dissemination through vehicles over fixed infrastructure-based queue information dissemination is the ability to address the issue of dynamic queue conditions which can shift along a road facility. However, vehicles not equipped with cellular and DSRC communication abilities will not receive such

6

queue warning information. This implies a higher market penetration of CAVs will be needed for this approach to be beneficial. Also, a strictly vehicle-based queue warning application is necessarily reactive, in that it can only detect and respond to an already-formed queue because it has visibility only into the immediate local traffic. Vehicle-based queue warning is not capable of predicting potential queue formation because it does not have a comprehensive picture of the traffic state, in terms of historical patterns and the wider traffic conditions. It should be noted that the vehicle-based queue warning experience in INFLO did not explore integration with data providers (see below, Probe-Based/Third-Party Based Queue Warning Application). Though promising, the approach developed in INFLO is not widely used and the only known implementation was the INFLO prototype demonstration in Seattle, Washington. In this Small-Scale Demonstration, the Project Team worked with Washington State Department of Transportation (WSDOT) to deploy connected vehicle systems at three Variable Speed Limit (VSL) gantries, and in twenty-one vehicles, in a scripted driving scenario circuiting a corridor on I-5 from Tukwila to Edmonds through downtown Seattle, during morning rush hour the week of January 12, 2015. The INFLO Prototype System collected vehicle speed data from both the WSDOT infrastructure-based speed detectors and the connected vehicles during the driving scenario. The System processed the data in real time and delivered queue warning and speed harmonization messages to drivers. The INFLO demonstration proved connected vehicle data capture and dissemination functionality in an operating environment using both cellular communications and DSRC communications. Secondly, the Small-Scale Demonstration showed that the INFLO Prototype System may have the latency and processing speed to support INFLO application functionality in an operational traffic environment. Thirdly, the Small-Scale Demonstration developed data that helped confirm that the INFLO Prototype System can deliver more precise estimates of the location of the back of the queue and the length of the queue faster than an infrastructure-based system. Additional information on the INFLO bundle can be found at https://www.its.dot.gov/pilots/pilots_mobility.htm. Probe-Based/Third-Party Based Queue Warning Application With the advent of technology and proliferation of third party traffic data sources such as INRIX, HERE (formerly NAVTEQ Maps), WAZE, TomTom, and others, queue warning systems can be developed using only these data types or in combination with other data sources such as vehicle data and traditional infrastructure data. Many DOTs have subscriptions to use traffic mobility data from third party sources for varying purposes. Such data can fill the void for road facilities where traditional infrastructure/sensors have not been deployed to monitor traffic flow conditions and eventually used to develop queue warning applications. Some of these third-party data sources (e.g., HERE, INRIX) provide both real-time and historic processed travel times and speed. For such data, further analysis needs to be conducted by a transportation agency to generate queue information (i.e., back of queue, length of queue, etc.) for dissemination. However, other third-party data providers such as WAZE may be able to show approximate queue locations and amount of time to be spent in queue; such data sources will require relatively minor refinement by transportation agencies for queue warning purposes. While there is no published record of queue warning applications based on third-party data, its likely to be implemented soon.

7

Hybrid/Modular-Based Queue Warning Application This modular approach requires the development of the queue warning applications where input data from multiple sources (infrastructure, CAVs, third-party, etc.) will be fused together to generate proper queue warning recommendations. However, the queue warning application must continue to function in the absence of either infrastructure, CAV, or third-party information. The queue warning application should produce a recommendation even if one of the sources of data is not available. This queue warning approach is intended to support a traffic mix of CAVs and regular vehicles. An important example of this approach for developing queue warning applications is the INFLO bundle. In addition to generating queue warning messages/alerts based on only connected vehicle data, infrastructure sensor data was fused with connected vehicle data to generate queue warning messages/alerts. In the INFLO queue warning algorithm, data from infrastructure sensors are used to determine which links are operating in a queued, congested or in a free flow state. Using this information, the back of queue is determined and located at the mile marker reference point of the detector station where the state of the link transitions from a free-flow or congested state, to a queued state. The back of queue based on the connected vehicle data is defined as the farthest upstream sublink operating in a queued state. The final back of queue is then determined by comparing the back of queue from the infrastructure data and connected vehicles data and selecting the back of queue that is furthest upstream as the back of queue location. During the small scale INFLO demonstration in Seattle, the queue warning application generated queue warning messages/alerts based on

• WSDOT infrastructure data only, • Connected vehicle data only, and • Integrated WSDOT infrastructure and connected vehicle data.

The messages delivered to drivers were generated from integrated WSDOT Infrastructure and connected vehicle data. The infrastructure only and vehicle only messages were captured in the database for subsequent comparison and analysis. Additional information on the INFLO program can be found at https://www.its.dot.gov/pilots/pilots_mobility.htm. Distinction from INFLO Bundle The INFLO bundle provides a good starting point for the development of queue warning applications and it is required that the subcontractor consult the queue related content from INFLO publications. However, this project is not intended to replicate what was done in INFLO but to build on it as needed. The below table lists some of the differences between INFLO and this project.

ID INFLO THIS PROJECT

1. Made up of three applications – Queue Warning, Speed Harmonization, CACC

Consists of only one application – Queue Warning

2. Queue Warning application developed with only two data sources – connected vehicle and infrastructure sensor data

Queue Warning application developed with more than two data sources –

8

CAV data, infrastructure sensor data, third-party data

3. Queue Warning application never identified front of queue. It was always a known location (recurring congestion).

Queue Warning application should be able to determine front of queue

4. Queue Warning application not compatible with EDCM approach

Queue Warning application should be compatible with EDCM

INFLO-related (including Q-WARN components) documents are available at: https://www.its.dot.gov/research_archives/dma/dma_pubs.htm while EDCM background information is provided in Appendix A. III. SCOPE OF SERVICES The UVA CTS, on behalf of CV PFS, seeks a qualified organization (the “Selected Subcontractor”) to conduct systems engineering services for development of V2I Queue Advisory/Warning Applications: Concept and Design (the “Services”). A. GOAL AND OBJECTIVES The goal of this project is to perform systems engineering to result in a high-level design for V2I Queue Advisory/Warning Applications using a variety of approaches for both the vehicle side and infrastructure agency (Infrastructure Owner/Operator, “IOO”) side. This high-level design is intended to enable future development and testing efforts beyond this project. This project builds upon and is related to other prior (i.e., INFLO Q-WARN) and current (i.e., CAMP EDCM) efforts; and is not intended to duplicate, but rather to broaden and update the V2I Queue Advisory/Warning concept to reflect both EDCM variants as well as the rapidly evolving state of vehicle automation and connectivity. The objectives of this project are:

• To gather foundational stakeholder input and assess prior work to identify additional gaps and needs

• To develop Concept of Operations and Use Cases that reflect the variations for both infrastructure-side and vehicle-side components

• In conjunction with CAMP EDCM project (which will identify vehicle-side requirements), to develop system requirements for V2I Queue Advisory / Warning systems, and an integrated and validated complete set of requirements

• To develop high-level design that enables other efforts to conduct prototyping and testing activities

• To coordinate with and review content from the CAMP EDCM project to maximize mutual understanding of vehicle and infrastructure perspectives and needs

9

Note that the project outlined in this RFLI is intended to complement and interact significantly with portions of the CAMP EDCM Project, particularly in the application of EDCM concepts to the V2I Queue Advisory/Warning topic area, and there is the expectation that the CAMP EDCM project will also provide substantive input for this project from the vehicle perspective. B. TASKS This project will consist of the following tasks:

• Task 1: Project and Systems Engineering Management • Task 2: Assessment of Prior Work & Stakeholder Input • Task 3: Concept Development • Task 4: System Requirements • Task 5: High Level Design • Task 6: Coordination with and Review for CAMP EDCM Project

Task 1: Project and Systems Engineering Management The purpose of this task is for the Subcontractor to provide project management support for all tasks described in this scope of services. The followings are the specific task items to be conducted:

• Participate in a project kick-off meeting within three weeks of contract award. • Based on discussions at the kick-off meeting, develop a Project Management Plan (PMP)

that guides the execution of Work Task Activities identified in this scope of services. The PMP shall include plans for: Scope Management, Cost Management, Quality Management, Human Resources Management, Communications Management and Risk Management.

• Prepare a detailed project schedule that lists all planned tasks and milestones for the project and submit an electronic project file in the format of Microsoft Project 2010 or higher and Adobe PDF.

• Once the PMP and project schedule are ready, schedule a coordination meeting with the Pooled Fund Study members/USDOT coordinator and support to review each document and ensure consensus on the overall approach for project execution. The Pooled Fund Study team will issue an authorization to proceed with the activities described in the approved PMP and project schedule.

• Participate in a series of monthly project status conference calls from the contract award. Also submit agendas, presentation materials, and meeting minutes for these calls.

• Submit a monthly progress report by the 15th of each month. This includes cost, schedule, and performance information necessary for monthly USDOT ITS JPO Program Management Office (PMO) reporting. The performance information includes deliverable status (not initiated, in progress X% complete, draft delivered, in revision X% complete, final delivered, accepted), accomplishments, current risk registry, and the planned activities for the next month. ITS JPO PMO templates are available at http://www.its.dot.gov/project_mang/index.htm

• Attend team meetings or teleconferences as requested (for proposal purposes, assume monthly); prepare a report on progress, schedule, scope issues, budget, and results of

10

tasks at team meetings; and prepare team meeting summaries, which will, at a minimum, track the status of action items.

• Attend a project closeout meeting in the last week of the project. At this meeting, prepare and present a project closeout summary including the summary of work performed under each task, the status of each deliverable, and identify pending or incomplete deliverables, and the total funds expended.

To ensure that there is a common understanding of the system engineering process being used, and artifacts being produced, the Subcontractor shall develop a draft Systems Engineering Management Plan (SEMP), guided by IEEE 1220 or successors, that covers the approach being used. Consideration should be given to how Systems Engineering best practices for Systems of Systems may be applied in this project. Based on CV PFS and USDOT comments, the Subcontractor shall revise the SEMP to address the feedback.

Task 1 Deliverables: • Kick-Off Meeting, Briefing Materials • Draft PMP • Final PMP and the Comment Resolution Report • Draft Project Schedule • Final Baseline Project Schedule (Microsoft Project 2010 or higher Format and PDF) • Draft SEMP • Revised SEMP and the Comment Resolution Report • Monthly Update Conference Calls and associated Agendas, Presentation Materials, and

Minutes • Monthly Progress Reports • Team Meetings Summaries • Briefing Materials, Closeout Meeting • Project Closeout Meeting, Project Closeout Summary

Task 2: Assessment of Prior Work & Stakeholder Input The purposes of this task are for the Subcontractor to conduct a technical review and assessment of the prior work (primarily INFLO Q-WARN) and gather stakeholder input in order to identify gaps, constraints, and developing areas (such as vehicle automation) that need to be considered in the systems engineering activities in Tasks 3-5. This task will identify how INFLO Q-WARN and other prior work can be used as a building block and guide Tasks 3-5. The Subcontractor shall research and review documentation related to INFLO Q-WARN, current practices and capabilities relating to V2I Queue Advisory/Warning by State/Local DOTs, particularly those including utilization of, or data exchange with, third-party entities. This review shall include both technical aspects such as communications flows, performance, and standards; as well as institutional factors such as privacy and data rights. The Subcontractor shall document the results of the review in a draft technical paper. In addition to reviewing documentation, the Subcontractor shall gather stakeholder input, in consultation and coordination with the CV PFS, to supplement the information in the draft

11

technical paper. The Subcontractor shall revise the technical paper to reflect the information gained from stakeholders as well as feedback on the draft version. Stakeholder input may relate to (not limited to) the following:

• Engage with representatives from entities that are actively operating or deploying elements relating to V2I Queue Advisory/Warning.

• Engage with other groups, such as the CAT Coalition working groups, to inform systems engineering activities so that applications interfaces are consistent (and/or bring results for dialogue) with the latest versions of the national ITS architecture, standards, and other cross-cutting efforts.

• Coordinate with other related efforts such as standards working groups. • Coordinate for planned interactions with stakeholders in later tasks (e.g., stakeholder

input to systems engineering reviews).

Task 2 Deliverables: • Draft Technical Paper – Review of Prior/Current Work • Revised Technical Paper – Review of Prior/Current Work and the Comment Resolution

Report Task 3: Concept Development The purpose of this task is for the Subcontractor to build upon prior work and the results/technical paper from Task 2 and develop a Concept of Operations (ConOps) document for V2I Queue Advisory/Warning Applications (overall, including both vehicle/mobile and infrastructure and data providers), using the approach identified in the Revised SEMP from Task 1. As this project aims to reflect an environment where more than one approach may be used, the V2I Queue Advisory/Warning ConOps should be compatible with, but not reliant on, the EDCM architecture, and existing infrastructure-based systems. The V2I Queue Advisory/Warning ConOps, (and other Systems Engineering artifacts in later tasks) should ultimately allow for some local customization in deployment options related to data collection and data dissemination to/from vehicles, mobile devices, infrastructure elements, TMCs, and third party providers. The EDCM architecture would be one specific implementation of this overall ConOps. The Subcontractor shall develop a draft ConOps document, guided by IEEE 1362 or successors, covering V2I Queue Advisory/Warning (Note, the CAMP EDCM project will be providing substantial input from vehicle perspective, however the Subcontractor is responsible for the complete, well-integrated deliverable), and revise based on initial CV PFS and USDOT comments. A high-level ConOps document shall include at a minimum the user needs, constraints, and context diagram(s). Use cases (also called scenarios) are a subsection of the ConOps. Use cases provide a description of the operational concepts, constraints on the operation, and information needed as a minimum. There can be multiple use cases (and typically are) to meet multiple operations occurring within an organization. Use cases are typically used to derive and validate user needs. Use cases and user needs development is an iterative process to help identify holes and gaps in the user needs until the system owner is satisfied. See A Well Written Need and Well-Formed Requirement in Appendix B.

12

The Subcontractor shall coordinate with the CV PFS and USDOT to conduct an in-person walkthrough (for proposal purposes, assume two days) plus webinar capability to gather stakeholder input and feedback. The purpose of the ConOps Walkthrough is to gain specific feedback from stakeholders. This can be attained when stakeholders have read the ConOps ahead of time and are not seeing the content for the first time. Based on the feedback received, the Subcontractor shall develop a Revised ConOps document. The proposed budget shall include the fund to support this in-person walkthrough meeting. Note that the CV PFS will fund the travels made by the CV PFS members. Also, the Subcontractor shall develop a draft technical memo detailing expected Methods (including modeling development) and Metrics for Performance Measurement, both for the functionality of V2I Queue Advisory/Warning Applications and components affecting application (e.g., latency, reliability, etc.) and system performance, as well as for future impacts assessments. The Subcontractor shall revise these draft documents based on initial CV PFS and USDOT comments. NOTE: there is the expectation that the CAMP EDCM project will also provide substantive input for this project from the vehicle perspective. However, responsibility for the complete deliverable rests with the Subcontractor.

Task 3 Deliverables: • Draft Concept of Operations • ConOps Walkthrough (including Supporting Materials) • Revised Concept of Operations and the Comment Resolution Report • Draft Tech Memo – Methods and Metrics for Performance Measurement • Revised Tech Memo – Methods and Metrics for Performance Measurement and the

Comment Resolution Report Task 4: System Requirements The purpose of this task is to build upon prior and related work to develop system requirements for V2I Queue Advisory/Warning Applications, which trace to the ConOps from Task 3, using the approach defined in the Revised SEMP from Task 1. As the CAMP EDCM effort will be developing requirements from the vehicle point-of-view, this task shall include review and incorporation of content from the CAMP EDCM project. The Subcontractor shall engage with the CAMP EDCM activity and ensure that the overall system requirements are consistent with the ConOps and compatible to, but not reliant on, the EDCM architecture. The Subcontractor shall develop a draft System Requirements Document, guided by IEEE 1233 or successors, including functional, non-functional, interface, performance, and data requirements, for V2I Queue Advisory/Warning Applications. The System Requirements document shall include traceability to user needs in the ConOps using a Needs to Requirements (NTR) matrix. See A Well Written Need and Well-Formed Requirement in Appendix B. The Subcontractor shall revise the draft System Requirements document based on CV PFS and USDOT comments.

13

The Subcontractor shall conduct an in-person walkthrough (for proposal purposes, assume two days) plus webinar capability, guided by IEEE 1028 or successors, of the system requirements. The purpose of this walkthrough is to review the completeness and correctness of the system requirements. The Subcontractor shall develop a system requirements walkthrough plan and workbook. A template for the Plan and Workbook can be provided by USDOT. Based on feedback received and documented at the walkthrough, the Subcontractor shall update the draft system requirements and deliver an accompanying walkthrough comment resolution report. The proposed budget shall include the fund to support this in-person walkthrough meeting. Note that the CV PFS will fund the travels made by the CV PFS members. NOTE: there is the expectation that the CAMP EDCM project will also provide substantive input for this project from the vehicle perspective. However, responsibility for the complete deliverable rests with the Subcontractor.

Task 4 Deliverables: • Draft System Requirements Document • Requirements Walkthrough (including supporting materials/workbooks) • Revised System Requirements Document and the Comment Resolution Report

Task 5: High Level Design The purpose of this task is to develop the High Level Design for V2I Queue Advisory/Warning Applications, using the approach defined in the Revised SEMP from Task 1. The resulting High Level Design is intended to enable future development and testing efforts, which may include efforts from various entities. Particular emphasis should be given to interfaces across vehicle, infrastructure, and third-party subsystems, including use of standards or development of pre-standards design content. The Subcontractor shall develop the draft High Level Design document, guided by ISO/IEC/IEEE Standard 42010-2011 (IEEE Recommended Practice for Software Architecture Descriptions) includes guidelines for format and content to develop a System Architecture Document (SAD) and check against the Concept of Operations and System Requirements documents from Tasks 3 and 4 to ensure that traceability is maintained and that the design satisfies the requirements and fulfills the user needs. The Subcontractor shall document the results from this step in a Design Verification technical memo, and revise the High Level Design document to reflect feedback received and to address any inconsistencies or other issues identified in this process. If necessary, the Subcontractor shall also revise other project documents that are affected by this review. The Subcontractor shall conduct an in-person walkthrough (for proposal purposes, assume two days) plus webinar capability, guided by IEEE 1028 or successors, of the system architecture/system design. The purpose of this walkthrough is to demonstrate the completeness and technical soundness of the architectural approach. The Subcontractor shall develop an architecture/design walkthrough plan and workbook. A template for the Plan and Workbook can be provided by USDOT. Based on feedback received and documented at the walkthrough, the Subcontractor shall update the draft system architecture/system design and deliver an

14

accompanying walkthrough comment resolution report. The proposed budget shall include the fund to support this in-person walkthrough meeting. Note that the CV PFS will fund the travels made by the CV PFS members. NOTE: there is the expectation that the CAMP EDCM project will also provide substantive input for this project from the vehicle perspective. However, responsibility for the complete deliverable rests with the Subcontractor.

Task 5 Deliverables: • Draft High-Level Design Document • Architecture/Design Walkthrough (including supporting materials/workbooks) • Revised High-Level Design Document and the Comment Resolution Report • Tech Memo – Design Verification

Task 6: Coordination with and Review for CAMP EDCM Project The purpose of this task is to ensure that CAMP EDCM documents are reviewed by this project so that efforts are aligned. Along with project initiation activities in Task 1, the Subcontractor shall meet with CAMP EDCM project representatives to discuss the projects’ timelines and planned activities. Since there may be factors that result in variation from planned schedules, the Subcontractor shall develop a project coordination document that identifies upcoming planned interactions between the projects and regularly update as needed to ensure that both projects have a common understanding of timelines. The Subcontractor shall participate in joint meetings and workshops with the CAMP EDCM project for discussion and presentation of the interrelated portions of both projects. In addition to the systems engineering walkthroughs in Tasks 3-5 (locations TBD), it is anticipated that over the period of performance, 3 in-person meetings at CAMP (in Metro Detroit Area – Novi, Michigan), 1 in-person meeting in Washington, DC, and 3 in-person meetings at CV PFS regular meetings will be required. In addition to these meetings, discussions via teleconference/web conference will be required during specific project phases. The Subcontractor shall review CAMP EDCM Project draft deliverables that relate to V2I Queue Advisory/Warning (i.e., EDCM Architecture and Data Framework) and develop a set of written comments (non-editorial). The Subcontractor shall participate in discussions relating to the comments as necessary.

Task 6 Deliverables: • Project coordination document – regularly updated • Tech Memo – Review of CAMP EDCM Architecture and Data Framework

15

C. SCHEDULE FOR DELIVERABLES The Period of Performance (POP) of this project is 18 months. The Subcontractor shall submit a proposed schedule with major milestones for deliverables. The UVA CTS’s proposed timeframe is outlined in the table below:

TASK NAME AND DELIVERABLE DUE DATE Task 1 – Project and Systems Engineering Management

Kick-Off Meeting, Briefing Materials Within 3 weeks from Contract Award Draft PMP 5 weeks from Contract Award Draft Project Schedule 5 weeks from Contract Award Final PMP and Comment Resolution Report 10 weeks from Contract Award Final Baseline Project Schedule and Comment Resolution Report

10 weeks from Contract Award

Draft SEMP 7 weeks from Contract Award Revised SEMP and Comment Resolution Report 13 weeks from Contract Award Monthly Update Conference Calls and associated Agendas, Presentation Materials, and Minutes

Every month from Contract Award

Monthly Progress Reports Every month from Contract Award Team Meetings Summaries Within 1 week after each meeting Closeout Meeting, Project Closeout Summary 78 weeks from Contract Award

Task 2 – Assessment of Prior Work & Stakeholder Input Draft Technical Paper – Review of Prior/Current Work 16 weeks from Contract Award Revised Technical Paper – Review of Prior/Current Work and Comment Resolution Report


Task 3 – Concept Development Draft Concept of Operations 27 weeks from Contract Award ConOps Walkthrough (including Supporting Materials) 31 weeks from Contract Award Revised Concept of Operations and Comment Resolution Report


Draft Tech Memo – Methods and Metrics for Performance Measurement


Revised Tech Memo – Methods and Metrics for Performance Measurement and Comment Resolution Report


Task 4 – System Requirements Draft System Requirements Document 49 weeks from Contract Award Requirements Walkthrough (Supporting Materials) 53 weeks from Contract Award Revised System Requirements Document and Comment Resolution Report


Task 5 – High Level Design Draft High-Level Design Document 64 weeks from Contract Award Architecture/Design Walkthrough (Supporting Material) 68 weeks from Contract Award Revised High-Level Design Document and Comment Resolution Report


Tech Memo – Design Verification 75 weeks from Contract Award Task 6 – Coordination and Review for CAMP EDCM project

Project coordination document – regularly updated As required Tech Memo – Review of CAMP EDCM Architecture and Data Framework

TBD

16

IV. CONTENTS OF THE LETTER OF INTENT Letters of Intent are to provide a concise description of the research plan and capabilities of the interested party to satisfy the requirements of the RFLI. Emphasis will be on completeness and clarity of content. The letter of intent should include a signed cover letter, a title page, a proposal, a proposed budget and appendixes. The interested party shall submit the following in the letter of intent as one electronic file up to 10MB:

1. A signed cover letter (2 pages or less) 2. A title page (1 page) 3. A proposal (20 pages or less)

a. Technical Approach i. A detailed description and the full plan, to include a timeline, to

accomplish the project proposed b. Qualifications

i. A brief history of the interested party and its experience, qualifications and success in providing the type of service requested

ii. Brief introductory qualifications of the proposed staff 4. The interested party’s proposed price / fee for providing the Services (no page limit) 5. Appendix (no page limit)

a. Resumes of proposed staff b. Any other material that the submitter would like to include

V. BASIS OF SELECTION OF PREFERRED SUBCONTRACTOR Letters of intent will be evaluated based upon the overall merits/value including, but not limited to, price. All letters received will be carefully evaluated by the CV PFS based on the following criteria:

1. The interested party’s technical plan to provide the CV PFS with the products as described in the Scope of Services section;

2. The interested party’s qualification and experience in providing Services similar to those described in this RFLI; and

3. The interested party’s price/fee for providing the Services.

Appendix A: Event-Driven Configurable Messages (EDCM) Background

DRAFT – Internal Use Only. Do Not Distribute.

Event-Driven Configurable Messages Final Report

The purpose of this document is to outline the existing projects that are applicable to the maturity of I2V/V2I operator use cases in support of the event-driven configurable messaging (EDCM) research project.

The original task was to develop a comprehensive list of all potential I2V/V2I operator use cases. These use cases would include any already identified use cases from USDOT-supported Programs, or projects, as well as any other potential use cases from outside of the USDOT (e.g. State operator use cases). Since this task is the first step of a six-month effort to identify use cases that are deployment ready and have a near-term need for early deployers, it was decided that the best approach was to focus on a select group of mature use cases, rather than identifying all possible use cases.

EDCM General Process The general process of event-driven configurable messaging is illustrated in Figure 1.

Figure 1: EDCM General Process

The vehicle detects a potential event using data elements such as yaw rate, brake status, or windshield wiper status. Those data elements are packaged and sent to the TMC (via roadside unit). The TMC responds to the potential event by sending a control message as a predetermined package for that event to a geo-fenced area that could be impacted by the event. Vehicles continue to transmit requested information back to the TMC for real-time updates of the event.


The use cases defined in this document follow the general process defined above. The use cases are differentiated by the event trigger.


Configurable Message Event Triggers The purpose of the configurable message concept is to enable transportation operators to react in real-time to specific events. This section defines the events that would trigger the need for a configurable message. Each trigger event represents a unique use case.

Use Case 1: Weather Events There are several weather-specific events that could trigger the need for a configurable message. For example, the curve speed warning application could require a different speed threshold under icy road conditions.

1. Vehicle data triggers that a roadway hazard exists. 2. Vehicle sends “hazard” data to TMC. 3. TMC sends additional EDCM data to geo-fenced area where hazard was identified.

Use Case 2: Roadway Incident Roadway incidents are situations when an accident, or unforeseen incident occurs along the roadway, such as a broken down vehicle, or foreign object in the roadway.

1. Vehicle data triggers roadway incident has occurred. 2. Vehicle sends “incident” data to TMC. 3. TMC sends additional EDCM data to geo-fenced area where incident was identified.

Use Case 3: Work Zones Situations when a roadway is temporarily closed or reduced in capacity (i.e. lane closures) for maintenance. Unscheduled maintenance presents a specific EDCM need.

1. Maintenance is required along a dynamic stretch of roadway 2. Vehicles send “location and event” data to TMC. 3. TMC sends additional EDCM data to geo-fenced area where event was identified.

Use Case 4: Traffic Behavior Situations when queues, dynamic wait times, bottlenecks, or known traffic pattern changes occur due to specific non-incident related events, such as concerts, or rush hour. This use case is closely related to queue warning applications.

1. Vehicle data triggers change in traffic behavior due to road bottleneck 2. Vehicles send “traffic behavior” data to TMC. 3. TMC sends additional EDCM data to geo-fenced area where event was identified.


EDCM Maturity to Rapid Prototype The maturity of each EDCM use case (weather events, roadway incident, work zones, and traffic behavior) will be evaluated based on the maturity of its individual EDCM general process step. For each step, a maturity rating (High, Medium, Low) will be given based on criteria that aligns with the systems engineering process. The use case that is evaluated to be most mature will be recommended for rapid prototype development in FY18.

The individual EDCM general process steps are as follows:

1. Trigger Message Definition. What are the data elements needed to identify events that trigger the need for a configurable message?

2. Message Communication to TMC. What is the communication protocol for sending event-specific information from the vehicle to the TMC?

3. TMC Message Definition. What is the message protocol for sending ad-hoc information from a TMC to a geo-fenced area based on a specific event?

4. Message Communication from TMC to Vehicle. What is the communication protocol for sending ad-hoc information from the TMC back to the vehicle in a geo-fenced area?

The criteria for evaluating the maturity of each EDCM general process step is as follows:

Foundational Concept and Definition An EDCM use case element (general process step) has been defined though previous research.

Concept of Operations A concept of operations document has been developed. A concept of operations document describes the characteristics of a proposed system from the user perspective.

Prototyped An EDCM use case element (general process step) has been developed as a prototype.

Field Tested An EDCM use case element (general process step) has been field tested.

SAE J2735/J2945 standards coordination An EDCM use case message element aligns to existing standards.

Message Communication to TMC The message protocol of sending information from the roadside unit to the transportation management center has been defined, and for additional maturity, tested.

Message Communication from TMC to Vehicle The message protocol of sending information from the transportation management center back to the vehicle has been defined, and for additional maturity, tested.

TMC Geo-fencing The message protocol for sending messages from the TMC to a geo-fenced (geographic specific) location has been defined, and for additional maturity, tested.


What has been done? There are several USDOT-related projects that have been completed, are underway, or will begin in the near future that address various elements of the EDCM concept. These projects form the basis of understanding which EDCM general process steps are most mature within the four EDCM use cases considered in this document.

Project

Relevant Research Components Dynamic Message

Configurability

Use Cases and Messaging

Requirements

Data Message

Sets Accessible Transportation Technologies Initiative X Basic Information Message (CAMP) X Basic Infrastructure Message (Connected Vehicle Pooled Fund Study) X

Basic Mobility Message Development X Basic Safety Message Emulator X CAMP Advanced Messaging Concept Development X Communications Congestion X Connected Vehicle Pilots, Smart City Columbus, ATCMTD and MOD grant recipients X

Coordination of Mobile Devices for CV Applications X Data Capture and Management Standards Analysis X Dynamic Interrogative Data Capture X Infrastructure and V2X Mapping Needs Assessment X Integrating Emerging Data Sources into Operational Practice X Intelligent Transportation Systems Standards Program X Intelligent Transportation Systems Architecture Program X (?) X Personal Safety Message (Mobile Devices Project) X Traveler Information Message (TIM) X Weather Application Messages X V2I Hub X Vehicle Positioning and Communications X


Foundational Projects The EDCM concept relies on message elements beyond what is included in the basic safety message (BSM). Development of a basic infrastructure message (BIM) is critical to all of the EDCM use cases defined in this document. The following projects were critical in researching and testing some of the foundational aspects of the EDCM general process, focusing mostly on message definition and Vehicle to TMC communication.

BIM Development and Standards Support for CV Applications This project is documenting the relevant connected vehicle standards in advance of developing a basic infrastructure message (BIM). Once a standard (or near standard) BIM is developed, the next step would be to work with the appropriate standards development organization and committee to get the BIM standard message under consideration as a standard.

Advanced Messaging Concept Development Project This project was completed in 2017, but forms the baseline to the EDCM concept. This project evaluated the ability of connected vehicles to generate and infrastructure to collect Basic Safety message (BSM), Probe Data Message (PDM), and Basic Mobility Message (BMM) alternatives using cellular and DSRC communications under simulated data message control schemes, including emulating elements of Dynamic Interrogative Data Collection (DIDC) control where applicable, in real-world driving conditions for non-safety critical applications.

Dynamic Mobility Applications The objective of the DMA research program was to foster the release of high-value, open-source applications that use synthesized, multisource ITS data to transform transportation management and information. Much of the research conducted under this program forms the foundation for several other relevant projects that are exploring elements of the EDCM concept.

Anthem Test Bed MCDOT constructed a test bed in Anthem, Arizona to test the MCDOT SMARTDriveSM Program's vehicle prioritization technology in 2011. It was one of the first seven test beds in the country. Currently in phase two of the pilot, the Anthem Test Bed leverages V2X sensors based on DSRC technology, using RSUs fixed to light poles in conjunction with aftermarket OBUs mounted in buses and emergency vehicles. The Arizona CV program has now expanded its testing to include new applications such as a pedestrian traffic signal crosswalk application, transit priority application and a trucking priority application. In the future, the AZ CV Consortium hopes to expand its program even further by testing these applications in "real world" scenarios where residents and businesses in Maricopa County can participate.1

Nevada Intelligent Mobile Observations Project The Nevada Intelligent Mobile Observations (NIMO) project began in 2011 with Phase 1. The core aim of the NIMO program at this time was to demonstrate data telemetry capability from vehicles across all areas of NV, using the Interstate-80 corridor as the test bed. Starting in 2013, Phase 2 of the NIMO system was developed and installed into approximately 25 NDOT vehicles. Phase 2 was almost a

1 As identified by Basic Infrastructure Message Development and Standards Support for Connected Vehicles Applications C-V2X/DSRC White Paper (DRAFT). November 3, 2017


complete redesign of the in-vehicle hardware used in Phase 1. Phase 2 focused on vehicles within the Reno-Carson vicinity with cellular service. Most of the hardware and software for the system was replaced with different devices and applications to use cellular communications instead of EDACS. In early 2014, NDOT developed a prototype version of the NIMO system, which combined multiple modes of radio connectivity in order to maximize the strengths provided by each (EDACS and cellular) while minimizing their weaknesses. The network modes that were tested within this prototype include cellular, EDACS, and Wi-Fi. This multi-modal telemetry system was conceived to also work with Vehicular Satellite (using the Iridium network) or other radio-based systems such as P-25 or DSRC (Dedicated Short-Range Communications), which would eventually become a focus of Phase 3 of the NIMO project. The multi-modal approach to data telemetry provides coverage, even in rural areas, while fully utilizing the high-bandwidth cellular network found along interstate highway corridors and DSRC within urban areas such as Reno and Carson City.


Projects by EDCM Use Case The following projects are in progress, recently completed, or planned in the near-future. These projects are separated by EDCM use case. Of the projects identified as most mature for EDCM consideration, two use cases proved the most prevalent: work zones and weather events.

Work Zones CAMP – Reduced Speed Zone / Lane Closure Warning The Reduced Speed Zone / Lane Closure Warning (RSZW/LC) application informs the driver of an approaching work zone and warns the driver: a) when a lane closure requires a lane change, b) when vehicle speed is higher than the speed limit within a work zone. In order to provide lane closure or vehicle speed warnings, a mapping technique must be developed to generate a work zone map in real-time. As part of this project, CAMP is exploring two different methods to generate a work zone map.

1. Generate automatically by driving actual work zone (Michigan) 2. Generate from IOOs work zone map database (Texas)

Both of these efforts are relevant to the EDCM concept.

Automated Work Zone Map and Associated DSRC Message This project’s objective is to develop the means for IOOs to create and update work zone map and DSRC message in near real-time for transmitting from RSU for connected work zone deployment. Deployment in active work zones needs to comprehend dynamic changes in work zone configurations and generate/modify work zone maps and associated DSRC messages for transmitting it to approaching vehicles. The project aims to develop an effective mapping technique to rapidly generate work zone map and DSRC message, and to evaluate the efficacy of the technique in active work zones with Michigan Department of Transportation (MDOT) in Southeast Michigan.

V2I Based Connected Work Zone on TxDOT I-35 The objectives of this project is to evaluate work zone map and necessary information developed by the local agency against the in-vehicle warning application, and to adapt the application to variations in map generation capabilities and work zone configurations. V2I based in-vehicle work zone warning functionality has been developed and demonstrated under controlled conditions using DSRC, GPS, and custom work zone map. This project examines deployment in active work zones and the necessary information that needs to be generated and transmitted to warn approaching vehicles.

Virginia Connected Corridors (VCC) Virginia Connected Corridors (VCC) is a partnership between Virginia DOT and Virginia Tech Transportation Institute (VTTI), comprised of connected and automated vehicle (CAV) test beds located primarily in Fairfax County and Blacksburg, Virginia. The VCC provides an open CAV application development environment where researchers and developers can utilize existing infrastructure resources and systems to minimize time to demonstration and deployment.

Currently, the VCC is serving as a proving ground for CV application development, testing, and validation efforts which may benefit EDCM projects. For example, VTTI is partnering with VDOT to develop a work zone setup-assist and mapping tool that can be used by work zone deployers, inspectors and/or contractors to easily map out and verify the accuracy of important work zone features including start/stop location, lane shift and closure points, speed limit changes, activity areas, and more. The


application will forward the digitized map information to a server application which converts the data to industry standard messages that may then be distributed out to, and consumed by CAVs; providing more complete and accurate information about work zones than previously available.

Arizona Connected Vehicle Work Zone System The goal of the Arizona connected vehicle Work Zone System is to improve safety and productivity of commercial vehicles that are approaching freeway and arterial work zones. The project aims to enhance the work zone notifications. In advance of the work zone the commercial vehicle can be informed though the Fleet Management System which provides routing and dispatching information. This information helps them in choosing a route that could avoid work zones or other existing events. If re-routing is not an option, as the commercial vehicle approaches the event location, through backhaul it will receive situational awareness information, such as lane closure, real-time traffic condition information, and speed limit information that will make them aware of the hazard.

The project will leverage the connected vehicle technology broadcast to the approaching vehicles through the connected vehicle system using the SAE J2735 Traffic Information Message(s) (TIM). As the commercial vehicle enters the range of the work zone event, it will receive a Roadside Alert Message (RSA) through the DSRC communication channel between roadside units (RSU) and on-board vehicle units (OBU) that contains additional information about the event such as travel time going through the work zone. The system will integrate the connected vehicle system with Traffic Management System to augment information backhaul through the Fleet Management System. Figure below represents the concept:


A pilot system will be implemented in conjunction with Maricopa County MC-85 construction project and along a freeway location (to be determined).

In addition to the RSA and TIM messages, infrastructure based dynamic mobility, safety and environmental applications can be implemented. For example, variable speed limits can be used to slow vehicles before they reach the congested area and to smooth traffic flow. Queue warning can be used to notify the commercial, and other, vehicles of a traffic queue that might be out of visual range. Both of these apps are part of the USDOT INFLO dynamic mobility application suite.

The project is funded by Federal Motor Carrier Safety Administration (FMCSA) Commercial Vehicle Information Systems and Networks (CVISN) Program. ADOT and MCDOT are contributing matching funds.

Utah DOT V2I Corridor Implementation This project consists of 24 intersections that are broadcasting SPaT and MAP messages along an arterial, Redwood Road. In addition, transit buses have been outfitted with OBUs, which are sending a subset of the BSM message. When the bus is behind schedule, it sends a SRM message to request additional green time, with the goal of helping the bus get back on schedule. This system has been operational since November ’17. Utah DOT is collecting data from the corridor, including the bSM, SPaT, and SRM messages, as well as high-resolution signal data (ATSPM) and detector data. While the current focus is on transit scheduling, there is potential for use cases related to incident management and work zones.

Queue Advisory The following projects will begin in Fiscal Year 18. They are closely related to the EDCM Work Zone use case.

Develop prototype V2I / I2V queue advisory application (FY18) This project will provide for the activities to develop the functional description and application requirements for a V2I / I2V queue advisory application. It is expected that this work will be led by Infrastructure Owners/Operators (IOOs) through the Connected Vehicle Pooled Fund Study (CV PFS) and conducted in partnership with the Crash Avoidance Metrics Partners, LLC (CAMP). The first task is to develop appropriate use cases and concepts of operations, and to initiate required standards support for appropriate data flows. Successful completion of this work, and related work by CAMP, will be that basis for developing systems architecture and application algorithms (infrastructure based and in-vehicle) in FY2019, completing application development, and initial testing, develop and conclude objective testing, and demonstrating the application in FY2020.

This work builds on previous work conducted under the DMA INFLO Q-Warning and CAMP V2I safety applications projects.

Note that a separate project is required to support the parallel CAMP activities for this application development.

Develop prototype in-vehicle V2I queue warning safety application (FY18) This project will provide for the activities to develop the functional description and application requirements for an in-vehicle V2I queue warning safety application. It is expected that this work will be led by the Crash Avoidance Metrics Partners, LLC (CAMP) and conducted in partnership with


infrastructure owners/operators (IOOs), possibly through the Connected Vehicle Pooled Fund Study (CVPFS). The first task is to develop appropriate use cases and concepts of operations, and to initiate required standards support for appropriate data flows. Successful completion of this work, and related work by IOOs, will be that basis for developing systems architecture and application algorithms (infrastructure based and in-vehicle) in FY2019, building prototype vehicles, completing application development, and initial testing, develop and conclude objective testing, and demonstrating the application in FY2020.

This work builds on previous work conducted under the DMA INFLO Q-Warning and CAMP V2I safety applications projects.

Note that a separate project is required to support the IOO partner(s) for this application development.

Weather Events Connected Vehicle Pilot: Wyoming DOT Spot Weather Impact Warning In the Connected Vehicle Pilot, WYDOT will use vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and infrastructure-to-vehicle (I2V) connectivity to improve monitoring and reporting of road conditions to vehicles on I-80. The spot weather impact warning application is relevant to the EDCM concept in that it enables localized road condition information, such as fog or icy roads, to be broadcast from a roadside unit and received by a connected vehicle.

Develop prototype in-vehicle V2I / I2V road weather hazard advisory application (FY18) This project will provide for the activities to develop and field test a functional prototype for a V2I/I2V Road Weather Hazards Advisory application. It is expected that this work will be led by FHWA in partnership with Infrastructure Owners/Operators (IOOs), possibly through the Connected Vehicle Pooled Fund Study (CV PFS) and further conducted in partnership with the Crash Avoidance Metrics Partners, LLC (CAMP). The contractor will be required to develop this prototype application following the Systems Engineering process. The first task will be to identify appropriate stakeholder representation to shepherd the project and to initiate required standards support for appropriate data flows. Particularly, this project will stay abreast of ongoing NTCIP 1204 and SAE J2945/3 standard development activities. The architecture and algorithms developed under this task will leverage, to the maximum extent possible, the lessons learned from the RWMP/CAMP project titled "Dynamic Road Surface Mapping"; the RWMP's CV Application ConOps; the CV Pool Fund Study project that developed a DSRC CV application; the RWMP-developed Pikalert tool, and any other related work by CAMP. The POP for this effort is 36 months, including a field deployment phase of no less than six (6) months.

While this effort will leverage previous Dynamic Mobility Applications program efforts such as INFLO and Spot Weather Impact Warning, the architecture for this project is for system-wide applicability (not spot-specific.)

Note that a separate project is required to support the parallel CAMP activities for this application development.


Recommendations The purpose of this project was to identify use cases for the EDCM concept; identify relevant projects that have worked on, are currently working on, or plan to work on functionality critical to EDCM; and to assess the maturity of the different use cases across each essential functionality point (as described in the section EDCM Maturity to Rapid Prototype).

The maturity of each use case was evaluated based on the maturity of each functionality point along the EDCM general process. The table below highlights the fifteen relevant projects that were evaluated for EDCM maturity and separates the projects into three broad areas: foundational, current, and FY18/FY19 projects. Since each project focused on various functionality elements within the EDCM concept, a maturity assessment was made relative to the functionality point rather than the entire use case. However, when a project focused on a specific EDCM use case, it was noted, and considered in evaluating overall maturity.

Based on the maturity assessment, the EDCM concept is most mature in defining the trigger message (i.e. that icy road conditions exist) and transmitting that information from the vehicle to the TMC (i.e. using DSRC communication). The process by which the TMC dynamically defines a message in response to a trigger event, and then sends it back to the vehicle, is less mature. The specific EDCM use case that is most mature, based on the maturity of relevant project work, is work zones.

The purpose of this project was to identify the most mature EDCM elements in order to develop a rapid prototype in partnership with an existing or near-future project.

The following FY18 projects could be leveraged to introduce a rapid prototype of the EDCM concept:

• V2I/I2V queue advisory application • In-vehicle V2I queue warning safety application • In-vehicle V2I/I2V road weather hazard advisory application

There are also several projects already underway that present an opportunity for partnership:

• CAMP Safety Applications • Virginia Connected Corridor (VCC) Work Zone Setup-Assist


• Arizona Connected Vehicle Work Zone System • Utah DOT V2I Corridor Management

There are two recommended funding opportunities to for the EDCM concept:

1. Provide funding in FY18 to develop a Concept of Operations for the most mature use case (Work Zones) that can later be leveraged into an FY19 rapid prototype development project.

2. Provide funding in FY18 for a rapid prototype of the most mature use case (Work Zones) in partnership with an FY18 project (or relevant partner, such as Utah DOT).

Noblis Well-written need and Well-formed requirement April 2, 2008

Appendix B: Well-Written Need and Well-Formed Requirement

Well-written need A well-written need is uniquely identifiable, has a major desired capability, is solution free and contains the rationale for the need.

The following criteria are used to determine if a need is well written: Noblis, 2007 1. Uniquely Identifiable: Each need must be uniquely identified i.e., each need shall be

assigned a unique number and title. 2. Major Desired Capability (MDC): Each need shall express a major desired capability in the

system, regardless of whether the capability exists in the current system or situation or is a gap.

3. Solution Free: Each need shall be solution free, thus giving designers flexibility and latitude to produce the best feasible solution.

4. Capture Rationale: Each need shall capture the rationale or intent as to why the capability is needed in the system.

Well-formed requirement Below is a definition of a well-formed requirement found in IEEE 1233. Also, a simple grammar for writing requirements is provided. The grammar is based on a NASA document entitled, “Writing Effective Requirements Specifications.”

Well-formed Requirement definition from IEEE 1233, 1998 Edition(R2002): A well-formed requirement is a statement of system functionality (a capability) that can be validated, and that must be met or possessed by a system to solve a customer problem or to achieve a customer objective, and is qualified by measurable conditions and bounded by constraints.

NASA Grammar for a requirement: Requirements have a simple grammar:

• Actor [The System] • Action [shall do/not do something to] • Target [the object of the action] • Constraint [how, how often, how many, how fast] • Condition/Localization [if, when, where]

Example Requirement Form:

• [Actor] [Action] [Target] [Localization] [The System] [shall get] [traffic information] [from the DOT ATMS].

request for letters of intent v2i queue advisory/warning ......2018/10/02 · request for letters...

Documents