33

V2I Queue Advisory/Warning Applications: Concept and Design

SYSTEMS ENGINEERING MANAGEMENT PLAN

Geza Pesti, Ph.D., P.E.—Principal Investigator Kevin Balke, Ph.D., P.E., PMP—Co-Principal Investigator

Contract #: VTCR 114420

TTI Maestro Project #: M1901702

Submitted by: Texas A&M Transportation Institute

400 Harvey Mitchell Parkway South, Suite 300 College Station, TX 77845-4375

Submitted to:

University of Virginia Center for Transportation Studies Connected Vehicle Pooled Fund Study

Date Submitted:

July 31, 2019

Notice

This document is disseminated under the sponsorship of the U.S. Department of Transportation in the interest of information exchange. The U.S. Government assumes no liability for the use of the information contained in this document.

The U.S. Government does not endorse products or manufacturers. Trademarks or manufacturers’ names appear in this report only because they are considered essential to the objective of the document.

Quality Assurance Statement The Federal Highway Administration (FHWA) provides high-quality information to serve Government, industry, and the public in a manner that promotes public understanding. Standards and policies are used to ensure and maximize the quality, objectivity, utility, and integrity of its information. FHWA periodically reviews quality issues and adjusts its programs and processes to ensure continuous quality improvement.

iii

Contract #: VTCR 114420

TTI Project #: 612141-00001

WBS #: 1.4

Title: Systems Engineering Management Plan (Final) Document Date/revision Date: 7/31/2019

Contract Start Date: 4/3/2019

Contract End Date: 10/2/2020

Appropriation:

Key TTI Contacts Geza Pesti, Ph.D., PE. Researcher Engineer System Reliability Division Texas A&M Transportation Institute 3135 TAMU College Station, TX 77843-3135 P: 979-317-2829 E: g-pesti@tti.tamu.edu

TTI Contract Administration Pre-award Administrator: Tim Hein Research Development Office Texas A&M Transportation Institute P: 979-317-2046 E: T-Hein@tti.tamu.edu Post-Award Administrator: Natalie Johnson Sponsored Research Services Texas A&M University P: 979-845-9852 E: ndjohnson@tamu.edu

Customer Organization: University of Virginia Center for Transportation Studies

Key Customer Contacts: Brian Smith, Ph.D., P.E.

DOCUMENT REVISION HISTORY

Document Version

Document Sections Description of Changes Date Approval

1 All Initial draft 6/13/2019 2 All Revised draft 7/18/2019 3 All Final 7/31/2019

Prepared by: Geza Pesti 7/31/2019 Principal Investigator Date

iv

TABLE OF CONTENTS Introduction ................................................................................................................................... 1

The Systems Engineering Process .............................................................................................. 1 Scope and Objectives of SEMP .................................................................................................. 2 SEMP Update Process ................................................................................................................ 3 Intended Audience ...................................................................................................................... 3

Scope of Project ............................................................................................................................. 4 Background ................................................................................................................................. 4 Problem definition ...................................................................................................................... 4 Project Goals and Objectives ...................................................................................................... 8 Stakeholder Engagement ............................................................................................................ 9

Technical Planning and Control ................................................................................................ 10 Work Breakdown Structure ...................................................................................................... 10 Project Schedule ....................................................................................................................... 11 Systems Engineering Deliverables ........................................................................................... 11 Decision Gates .......................................................................................................................... 13 Validation and Verification Plans ............................................................................................. 14 Deliverable Review and Approval Process .............................................................................. 14 Configuration Control ............................................................................................................... 16 Roles and Responsibilities ........................................................................................................ 16 Risk Management ..................................................................................................................... 17

Application of Systems Engineering Process ............................................................................ 18 Project and Systems Engineering Management ........................................................................ 18 Assessment of Prior Work & Stakeholder Input ...................................................................... 18 Concept Development ............................................................................................................... 20 System Requirements ............................................................................................................... 22 High Level Design .................................................................................................................... 23 Coordination with CAMP EDCM Project ................................................................................ 25

References .................................................................................................................................... 26

1

INTRODUCTION This document presents the Systems Engineering Management Plan (SEMP) intended to provide guidance on how to manage the technical development of the systems engineering effort in the “V2I Queue Advisory/Warning Applications: Concept and Design” project. As a top level planning document and an extension of the project management plan (PMP), the SEMP defines how the systems engineering portion of the project will be organized, structured, conducted and controlled. It includes high-level technical details with references to other documents and standards [1-7].

The SEMP document is organized as follows: • Introduction - brief overview of the systems engineering process and the SEMP’s role and

place in it. • Scope of Project - general information about the V2I Queue Advisory/Warning Applications

project for which this SEMP was developed. • Technical Planning and Control Plan - discusses the technical plans, documents, and decision

gates that will be used to manage the project. • Systems Engineering Process Application – describes the SE processes that will guide the

activities through the entire project.

THE SYSTEMS ENGINEERING PROCESS Systems engineering is an interdisciplinary approach to the successful management and completion of the planning, development, operations and maintenance of complex systems. According to the Final Rule on Architecture and Standards Conformity [2], systems engineering analysis is required for all federally funded Intelligent Transportation Systems (ITS) projects. There are several standards and guides to the systems engineering process [3,4,5,6,7]. The main steps of the process are illustrated by the V-diagram shown in Figure 1. The left side of the V-diagram represents the project phases that are related to the decomposition and definition of the system. The bottom part of the diagram corresponds to the development, building and installation activities of the system components. The right side of the diagram represents the integration, testing, verification and validation of system components, and the acceptance, operation and maintenance of the system. The horizontal dashed lines connecting the left and right sides of the V-diagram represent the verification and validation processes that are performed to ensure that the system components and the entire integrated system satisfy all stakeholder needs and requirements. The verification and validation plans are developed during the decomposition of the system in the steps shown on the left branch of the V-diagram. The orange boundaries separating the various systems engineering activities are “decision gates” (or exit/entrance criteria). Their function is to determine if a particular activity has been successfully completed, its deliverables are accepted and approved, and work on the next step can start. The scope of this project includes only a subset of the entire systems engineering process, mainly the activities that are delineated by the red box in Figure 1. They include the following: • Project and Systems Engineering Management • Concept of Operations • System Requirements • High-Level Design

2

Figure 1. Project Scope within the Systems Engineering Process

The systems engineering process will produce several documents that provide details on how the project will be managed and the specific tasks executed. The systems engineering documents to be developed in this project include:

• Project and Systems Engineering Management Plans • Concept of Operations • Requirements specifications • High-Level Design Document SCOPE AND OBJECTIVES OF SEMP Figure 2 shows the SEMP’s position in the V-diagram and illustrates how it is expected to evolve though the various phases of the decomposition of the systems engineering process. An initial version of the SEMP document is developed early in the process as a supplement to the Project Management Plan (PMP). While the PMP provides general project management details, the SEMP focuses on the technical plans and systems engineering activities. Its purpose is to describe in detail the activities and technical tasks of the systems engineering processes within the project scope.

RetirementReplacement

SystemValidation

SystemVerification &Deployment

SubsystemVerification

Unit/DeviceTesting

Operations &Maintenance

ChangesUpgrades

Concept ofOperation

SystemRequirements

High-LevelDesign

DetailedDesign

Software / HardwareDevelopment

Field Installation

RegionalArchitecture

ConceptExploration

Life Cycle Time Line

Decision Gate(DocumentApproval)

ProjectPlanning

SEMP

Scope of this Project

3

Figure 2. SEMP in the Systems Engineering Process

SEMP UPDATE PROCESS The SEMP will be a living document. As the project progresses, the document may need to be updated by revising and refining existing elements or adding new sections. These updates will ensure that the SE processes that the research needs to follow will result in successful project outcomes. The SEMP will be reviewed at the completion of major milestones, such as the development of Concept of Operations, System Requirements and High-Level Design, and the document will be updated if needed. As a result, multiple revised versions of the SEMP may be prepared during the project. INTENDED AUDIENCE The intended audience for the SEMP includes individuals from the USDOT, CV PFS member states, the University of Virginia Center for Transportation Studies and the Texas A&M Transportation Institute. It is envisioned that the plan will also be shared with the CAMP team to help coordinate activities between the EDCM and this project.

RetirementReplacement

SystemValidation

SystemVerification &Deployment

SubsystemVerification

Unit/DeviceTesting

Operations &Maintenance

ChangesUpgrades

Concept ofOperation

SystemRequirements

High-LevelDesign

DetailedDesign

Software / HardwareDevelopment

Field Installation

RegionalArchitecture

ConceptExploration

Life Cycle Time Line

Decision Gate(DocumentApproval)

SEMPFrameworkPMP

ProjectPlanning

SEMP

Final SEMP

4

SCOPE OF PROJECT

BACKGROUND

The USDOT Intelligent Transportation Systems Joint Program Office (ITS JPO) Vehicle-Infrastructure Program has been engaged in research of connected transportation systems. Part of this effort has focused on researching and prototyping applications to optimize the safety and mobility performance of the transportation network by integrating infrastructure-based technologies into connected systems. 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 Configuration Messaging (EDCM) that allows vehicle-based system to provide selective real-time data reports to infrastructure systems (traffic management centers), which can request enhanced details based on dynamic conditions and needs. In the current phase, CAMP is developing and prototyping EDCM applications for work zones, road weather hazards, and queue warning and advisories. USDOT expects this project to complement and interact with the CAMP EDCM project, particularly when dealing with queue warning and advisories. The CAMP EDCM Project is expected to provide substantive input for this project from the vehicle perspective. This project is intended to investigate Vehicle to Infrastructure (V2I) Queue Advisory /Warning Applications: Concept and Design for the Connected Vehicle Pooled Fund Study (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 University of Virginia Center for Transportation Studies (UVA CTS) supports VDOT on the pooled fund study, serving as the technical and administrative lead for the effort, and manages all the projects on behalf of the CV PFS and the United States Department of Transportation (USDOT). The V2I Queue Advisory/Warning Applications: Concept and Design project is another collaborative effort between the CV PFS and USDOT.

PROBLEM DEFINITION Vehicle queues frequently occur at locations where available roadway capacity cannot serve traffic demand. They commonly form upstream of bottlenecks caused by incidents, work zones, weaving traffic at freeway junctions, exit ramps that overspill onto freeway lanes, and on arterials upstream of traffic signals. In addition, they can be caused by adverse weather and poor visibility conditions that may significantly reduce vehicle speeds and roadway capacity. Drivers approaching the end of queues without receiving any warning often have poor perception of the time and distance needed to safely slow down or stop to avoid rear-end collisions with slower or stopped vehicles in front of them. Thus, vehicle queues present significant safety concerns. This situation is illustrated in the upper part of Figure 3. Queue warning systems that constantly monitor vehicle speeds and/or occupancy upstream of potential bottleneck locations and provide near real-time warning messages to drivers when queues are detected can significantly reduce the potential of both primary and secondary rear-end collisions. A queue warning system using speed sensors and a changeable message sign is illustrated in the lower part of Figure 3.

5

Figure 3. Vehicle Stream with and without Queue Warning System

Queue Warning System Design Considerations Queues form and dissipate differently depending on variations in volume capacity ratios and the type of bottlenecks. There are cases when vehicle queues only affect one or two lanes (e.g. exit ramp overspill to freeway) while traffic in adjacent lanes can move at near free-flow speeds. This imbalance in queues requires lane-by-lane queue detection and appropriate queue warning. In other cases when all lanes are equally affected by vehicle queues, lane-by-lane queue detection may not be needed.

Another important variable that needs to be considered in queue warning systems design is shockwave speed (i.e., the speed of queue propagation upstream). Higher shockwave speeds (fast queue propagation) require shorter update intervals of queue warning messages and shorter speed aggregation intervals in the queue detection algorithm.

It is also important to consider how vehicle queues dissipate. Vehicle queue dissipation starts when there is a reduction in traffic demand (flow rate) or increase in capacity, or both at the same time. For example, capacity can increase when a work zone lane closure is opened, or when an incident is cleared and vehicle(s) blocking the lane(s) are removed. The following three basic cases of queue dissipation can be distinguished:

• IF traffic demand decreases & capacity remains the same THEN queue starts to dissipate from the back-of-queue

• IF traffic demand does NOT decrease & capacity increases THEN queue starts to dissipate from the front-of-queue

• IF traffic demand decreases & capacity increases THEN queue starts to dissipate from both the front- and back-of-queue

6

Thus, to determine if a roadway segment is in a queued state, the queue detection algorithm of a queue warning system should be able to determine the location of both the back-of-queue and front-of-queue in near real-time.

Queue Warning System Types by Data Sources Three types of queue detection and warning systems will be considered in this project:

• Infrastructure/sensor-based • Connected vehicle-based • Probe vehicle/Third-party data-based There are significant differences between these systems based on the data sources, data types and queue detection logic that they use, their expected accuracy, prediction ability and spatial coverage, and their way of disseminating queue information/warning. Table 1 provides a comparison of some key characteristics of the three queue detection and warning systems.

Table 1. Comparison of Key Characteristics of Queue Detection and Warning Systems

System Characteristics

Queue Warning Systems

Infrastructure/Sensor Based

Connected Vehicles Based

Probe Vehicle/Third Party Data Based

Implementations

Has been widely used INFLO Prototype Demonstration Project

None, except some on-going research efforts.

Data sources Sensors deployed along the roadway (e.g., loop detector, microwave radar, video cameras & image processor)

The Connected vehicle itself.

INRIX, HERE, WAZE, TomTom and other third-party traffic data providers

Data types Spot speed, Volume, Occupancy aggregated over selected time intervals (e.g., 20 seconds, 1 min, 5 min)

Basic Safety Message (BSM) and connected vehicle queued state

• Segment travel times and speeds (INRIX, HERE)

• Approximate queue locations and estimated time in queue (Waze)

Lane-by-lane queue detection

Possible using high-definition microwave radars, loop detectors, video image processing.

Possible in case of sufficiently high market penetration of CAV

Most likely not possible (at least currently)

7

System Characteristics

Queue Warning Systems

Infrastructure/Sensor Based

Connected Vehicles Based

Probe Vehicle/Third Party Data Based

Queue detection logic

• Queued state of a sensor location is determined using pre-defined speed or occupancy thresholds.

• Back of queue is detected by comparing queued states of consecutive sensor locations thresholds

• Queued state of a connected vehicle is determined comparing its speed and separation distance from its lead vehicle to pre-defined thresholds.

• Queued state of a road section is determined based on percentage of queued connected vehicles

• Back-of-queue and front-of-queue locations are found at the upstream and downstream boundaries between queued and non-queued sections.

• Proprietary Queue Detection logic developed by the third-party data provider

• Agencies can develop their own queue detection logic that uses the segment speeds obtained from a third-party data provider

Queue detection accuracy

Accuracy depends on • sensor spacing • data aggregation

interval If shockwave speed is known, accuracy can be improved

Accuracy depends on • CAV percentage in

traffic stream • Length of road

sections used in determining queued states

Higher CAV market penetration and shorter section length improves accuracy

Can provide approximate locations of traffic slow-downs but cannot detect the real-time locations of back-of-queue and front-of-queue.

Queue information up-to-datedness

Near real-time - depends on length of time intervals for data aggregation and warning message update.

Real-time Near real-time

8

System Characteristics

Queue Warning Systems

Infrastructure/Sensor Based

Connected Vehicles Based

Probe Vehicle/Third Party Data Based

Queue prediction ability

Locations, times and length of queues under recurring congestion can be predicted using historical data archived by TMC

Very short-term prediction of back-of-queue and front-of-queue location may be possible based on shockwave speed observed during queue formation.

Locations, times and length of queues under recurring congestion can be predicted using historical data archived by the third-party data provider or TMC

Spatial coverage

Covers only few miles of selected roadway segments

Can cover those roadways where percent of CAV is sufficiently high. Spatial coverage is expected to improve significantly with increasing market penetration of CAV.

Covers the entire roadway network where third-party provides service and collects traffic related data

Queue information dissemination

• DMS: Dynamic Message Signs

• VMS: Variable Message Signs

• In-vehicle queue warning messages

• DMS or VMS through RSU and TMC

Mobile devices

The three systems have some non-overlapping benefits and limitations, and therefore have the potential to effectively supplement each other if they are combined in a modular hybrid queue warning system design.

PROJECT GOALS AND OBJECTIVES The goal of the project is to utilize systems engineering to produce 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. The intent of this high-level design is to enable future development and testing efforts beyond this project.

This project will build upon prior efforts (e.g., INFLO Q-WARN) and current related projects (e.g., CAMP EDCM). It is not intended to duplicate, but rather, enhance, 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 specific objectives of this project are as follows:

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

9

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

• To work in conjunction with CAMP EDCM project (which will identify vehicle-side requirements), to develop system requirements for V2I Queue Advisory/Warning systems.

• To develop a high-level design to enable future prototype development 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. The scope of the project is limited to using the systems engineering process to develop a high level design for V2I Queue Advisory/Warning Applications. As part of the effort, TTI does not intend to develop, test, and deploy prototype applications in a controlled test environment or the field. STAKEHOLDER ENGAGEMENT Stakeholder engagement is a critical component to the successful completion of this project. Potential stakeholder groups include the following:

• CAMP, and automotive OEMs. • US Department of Transportation, Federal Highway Administration. • Infrastructure Owner/Operators (IOO), such as state departments for transportation. • The Cooperative Automated Transportation (CAT) Coalition. • The American Association of State Highway and Transportation Officials (AASHTO. • The Institute of Transportation Engineers (ITE). • The Society of Automotive Engineers (SAE) Infrastructure Applications Working Group.

The primary mechanism that TTI will use to engage stakeholders (other than USDOT and the CV PFS Advisory Panel) will be through periodic walkthroughs of specific deliverables. The TTI Team will coordinate with the CV PFS Advisory Panel and USDOT to conduct walkthroughs of the draft Concept of Operations, the draft System Requirements, and the draft High-Level Design documents for the V2I Queue Advisory/Warning application. One walkthrough will be conducted for each document. The purpose of these walkthroughs is to solicit input from stakeholders on the completeness and correctness of the documents. TTI will conduct these walkthroughs in person with representatives from the CAMP EDCM project team, the CV PFS Advisory Panel and USDOT. TTI may also invite other stakeholder groups, such as the work group members from the Cooperative Automated Transportation (CAT) Coalition, the Society of Automotive Engineers (SAE) Infrastructure Applications Technical Committee, and others, to participate in the walkthroughs. TTI will also provide web-conferencing capabilities to allow stakeholders who cannot attend in person to provide their input as well.

In these walkthroughs, the TTI Team will present the major elements of each document. To facilitate the discussion in the walkthroughs, TTI will develop Microsoft PowerPoint® presentations and walkthrough workbooks highlighting the major concepts and ideas in each document. The TTI Team will distribute these documents to the stakeholders at least 5 working days prior to each walkthrough.

10

TECHNICAL PLANNING AND CONTROL

This part of the document lays out a plan for the systems engineering activities. Specific elements presented in this section include:

• Work Breakdown Structure • Project Schedule • Systems Engineering Deliverables • Decision Gates • Validation and Verification Plans • Deliverable Review and Approval Process • Configuration Control • Roles and responsibilities for the systems engineering activities • Risk Management WORK BREAKDOWN STRUCTURE The Work Breakdown Structure (WBS) defined in the Project Management Plan (PMP) is shown in Figure 4. This WBS breaks the project activities down into technical work areas where specific deliverables and responsibilities can be assigned.

Figure 4. Work Breakdown Structure

11

PROJECT SCHEDULE Figure 5 shows a simplified version of the baseline project schedule developed in the PMP to track project progress. The project started on 4/3/2019 and will end on 10/23/2020.

Figure 5. Simplified Baseline Project Schedule

The schedule is aligned with the WBS. The initial version of the SEMP is developed as part of Task 1 in the WBS. Potential future updates of the SEMP that may be needed in subsequent tasks (i.e., concept development, system requirements and high-level design) are not reflected in the schedule. Note that project progress can also be affected by other inter-related CV-PFS efforts, such as the EDCM project. In this context, the initial project schedule should be considered as an estimated timeline for the completion of the project based on assumptions made at project start. SYSTEMS ENGINEERING DELIVERABLES Table 2 summarizes the major systems engineering deliverables that will be developed in the project. A brief description of the anticipated content of each deliverable is provided in the second column, and the parties authorized to approve them are listed in the third column of the table. Note that some deliverables (e.g. SEMP) may be considered as living document, and can be developed in stages.

Table 2. Deliverable Tables and Schedule

Deliverable Content Approving Agency

Project Management Plan (PMP) and Schedule

Define the Work Breakdown Structure, schedules of activities and organizational chart for the V2I Queue Advisory/Warning project. Describe the general processes used for project management, guidance, and oversight.

CV-PFS, U.S. DOT, CTS

12

Systems Engineering Management Plan

Document how the technical development of the V2I Queue Advisory/Warning system will be managed and what needs to be documented. It will also provide details on how the SE process need to be tailored to be able to utilize queue related information from multiple data sources and applications

CV-PFS, U.S. DOT, CTS

Assessment of Prior Work Technical Paper

Detailed review and assessment of all INFLO Q-WARN documents and reports to determine how the results and findings of that research can be most effectively used in this project.

Review documentation related to recent and on-going development of V2I Queue Advisory/Warning systems that have the potential to utilize multiple data sources.

CV-PFS, U.S. DOT, CTS

Concept of Operations Document

Define system/user needs, identify operational constraints. The ConOps will also include use cases representing different queue formation scenarios, queue warning application types and various combinations of data sources available for queue detection and prediction.

CV-PFS, U.S. DOT, CTS

Performance Measurement Technical Memorandum

Document with details on proposed method and metrics for performance measurement for • functionality of V2I Queue Advisory/Warning

Applications • components/factors affecting application • system performance • future impacts assessments.

CV-PFS, U.S. DOT, CTS

Systems Requirements Document

Itemized list of the specific requirements that the system components must be able to do. Provide details on functional, non-functional, interface, performance and data requirements. A Needs to Requirements (NTR) matrix that provides backward traceability to user needs is also included in the document.

CV-PFS, U.S. DOT, CTS

High-Level Design Document

Document the decomposition of the proposed hybrid V2I Queue Warning system into high-level components and interfaces based on the identified system requirements. The system architecture describing how the individual system components will communicate with each other is also included.

CV-PFS, U.S. DOT, CTS

13

DECISION GATES Decision gates are formal decision points, exit and entry criteria between consecutive processes in the project life cycle. Their function is to determine if a specific project phase is completed and all of its deliverables are accepted and approved, and the project team can move on to the next project phase. The main decision gates in this project are summarized in Table 3.

Table 3. Decision Gates

Decision Gate Criteria

Task 1: Project and Systems Engineering Management • Approval of the Project Management Plan and • Approval of Systems Engineering Management Plan

by US DOT, CV-PFS and CTS. Task 2: Assessment of Prior Work

• Approval of the Technical Paper reviewing and assessing recent and current work related to Queue Warning Systems using sensor data, CV data or third party data or any combination of them. Approval by US DOT, CV-PFS and CTS is required.

Concept Development will not start until the above approvals.

Task 3: Concept Development

• Approval of Concept of Operations Document • Approval of Performance Measurement Technical

Memorandum by US DOT, CV-PFS and CTS.

Development of the system requirements will not start until the above approvals.

Design Verification Technical Memorandum

Document the results of the traceability check performed on the High-Level Design across the concept of operations and the system requirements.

CV-PFS, U.S. DOT, CTS

CAMP EDCM Architecture and Data Framework Review Technical Memorandum

Document all major interactions and joint development efforts between the V2I Queue Warning and CAMP EDCM projects.

CV-PFS, U.S. DOT, CTS

14

Decision Gate Criteria

Task 4: System Requirements • Approval of System Requirements Document by US DOT,

CV-PFS and CTS. Work on High-Level Design will not start until the above approval.

Task 5: High-Level Design • Approval of High-Level Design Document by US DOT,

CV-PFS and CTS. Work on High-Level Design is considered completed after the above approval.

VALIDATION AND VERIFICATION PLANS The System Validation Plan outlines the steps and procedures to be followed to determine whether a deployed V2I QA/QW system satisfies all user needs defined in the ConOps. Since this project stops at the high level design in the SE process, only an initial system validation plan can be developed after completion of the Concept of Operations. The plan may include initial thoughts on the validation procedures and performance metrics. The performance metrics can be used to evaluate if the functionality and performance of a deployed QA/QW system satisfy all user needs. The initial system validation plan will need to be reviewed and updated closer to the start of an actual deployment. The System Verification Plan outlines the verification methods to be used for testing the V2I QA/QW system operations prior to future deployments. The verification methods to be developed in the initial System Verification Plan include:

• test strategies, • definitions of what will be tested, • the levels to which different system elements will be tested, and • a test matrix that provides traceability/mapping connecting the testing to the system

requirements. DELIVERABLE REVIEW AND APPROVAL PROCESS The review and approval process of project deliverables including all systems engineering documents and technical papers is illustrated by Figure 6. The PI and Co-PI will be responsible for reviewing and approving all draft reports, documents, and presentations prepared by the TTI technical team before being submitted to the CV PFS team for review. For key deliverables, the TTI Team may perform additional internal peer

15

reviews of the technical content and accuracy. Systems Engineering Documents related to the EDCM project will also be reviewed by the CAMP team.

Once all review comments have been incorporated, the PI will be responsible for transmitting the deliverables to the UVA CTS. Regardless of the author, at least the PI or the Co-PI will review and approve each deliverable before submittal. For major deliverables, TTI Communications staff will provide a full edit and format of project documentation. TTI will complete the revisions to the document within 10 business days, and then submit the revised document along with a comment resolution document if appropriate. This will complete the review and submission cycle for a given document developed in this project.

The approval of a project deliverable is an iterative process that may require multiple reviews and revisions until all comments are satisfactorily addressed and incorporated in the final version. Not all deliverables/documents will require all steps of the review and approval process. The project panel members from US.DOT, CV PFS and CTS will decide which review steps apply to each deliverable.

Figure 6. Review and Approval Process of Project Deliverables

Internal Review byTTI Technical Team

PI Approval of Draft SE Document

Review by CAMP EDCM Team

Review Draft DocumentUS.DOT, CV PFS, UVA CTS and Other Stakeholders

DocumentEDCM-related?Y N

N

TTI incorporatesCAMP Comments

TTI Prepares Revised SE Document and

Comment Resolution Report

Comments

Check Revised SE Document

US.DOT, CV PFS, UVA CTS

Submit toUVA CTS

CommentsProperly

Addressed?

Y

N

TTI PreparesDraft SE Document

Approval byUS.DOT, CV PFS, UVA CTS

SE Walkthrough (TTI, US.DOT, CV PFS, UVA CTS, CAMP and Other Stakeholders)

WalkthroughRequired? Y

16

CONFIGURATION CONTROL

This section defines the Configuration Items (CI) and Configuration Control process for this project. A CI can be any project deliverable such as systems engineering document, software or hardware that performs a complete function and has been chosen to be placed under change control. The Configuration Control Process describes the TTI team’s approach and methods to manage how changes to the identified CIs can be made and what version control procedures should be applied. The CIs identified in this project include the following key deliverables:

• Project Management Plan • Systems Engineering Management Plan • Concept of Operations Document • System Requirements document • High-Level Design Document Other documents produced in the project may be identified and added to this list. Any changes to the documents on the CI list will go through the following change management process:

• TTI team or Project Advisory Panel identifies the need and opportunity for improving a project document.

• TTI team and Project Advisory Panel review the proposed improvement and make a GO vs. NO-GO decision.

o Assess the expected impact of change. o Identify other system components (SE documents) affected by the change.

• If decision = GO, the TTI team will o Check out the SE document from the project shared folder and perform the proposed

change. o Check out all affected process documentation, and update them as appropriate. o Route each modified document for approval. o Check back all revised documents as new versions.

• Update the system to reflect the changes.

A shared project drive has been created under TTI’s Google Drive account. This is where all versions of the project documents are stored. Configuration control is maintained through appropriate user permission settings for specific shared folders and files (e.g., viewer, commenter, contributor, content manager). Once a deliverable is completed and approved by the US.DOT/CV PFS project panel, it will be moved into a shared folder with limited access (only Viewer) permission settings. A Trello Team Board has also been setup and will be linked to the shared project folders on Google Drive. ROLES AND RESPONSIBILITIES

The TTI team’s roles and responsibilities to perform all systems engineering activities throughout the project have been defined in the PMP document. If needed, it will be revised during subsequent project phases.

The roles and responsibilities in the following three critical tasks are distributed between the TTI and CAMP EDCM project teams:

17

• Task 3: Concept of Operations • Task 4: Development of System Requirements • Task 5: Development of High Level Design

The CAMP EDCM Project will provide support for the TTI team by providing the vehicle-related portions of the Concept of Operations and System Requirements that the TTI team will incorporate into the V2I QA/QW concept and design documents. The distribution of responsibilities between the two teams is illustrated by Figure 7. All other components of the V2I QA/QW Application Concept and Design documents, including the sensor-based and third-party data based components are the TTI team’s responsibilities.

Figure 7. Distribution of Responsibilities between TTI and CAMP EDCM Project

RISK MANAGEMENT

The PMP explains the process and procedures that TTI will follow to monitor, identify, assess, respond to and otherwise manage project risks. This section is a brief summary of the Risk Management Plan discussed in detail in the PMP.

The PI, with support from the entire project team, is responsible for managing team risks. The TTI team will maintain a risk register that identifies various internal risks and includes planned and actual responses to those risks. The PI will implement a coordination plan that will include regular internal team meetings (e.g., bi-weekly) and briefings to the project director (e.g., monthly). Concerns raised during these meetings will be appropriately documented to ensure that they are addressed. Team members will closely monitor any indication of scope creep and cost overruns indicated in team meetings and briefings.

TTI maintains the Risk Register in a separate file from the PMP and SEMP. In case of any change in the Risk Register, it will be provided to the project director with the next monthly update.

V2I Queue Advisory/Warning Application

Project and SE Management

Assessment of Prior Work

Concept of Operations

System Requirements High Level Desgin

EDCM ProjectProvides Vehicle Related ConOPs and System Requirements

TTI CAMP

18

APPLICATION OF SYSTEMS ENGINEERING PROCESS

PROJECT AND SYSTEMS ENGINEERING MANAGEMENT

The TTI team has participated in a project kickoff meeting with UVA CTS and CV PFS staff. The purpose of the kickoff meeting was to review and refine the proposed approach and discuss the goals and objectives of the project. The TTI team has also developed a draft Project Management Plan (PMP) and project schedule. The PMP includes plans for managing scope, costs, quality, human resources, communications and risks.

The PMP was reviewed by members of the CV PFS, USDOT and UVA CTS. Based on the review comments, the TTI team submitted a revised version of the PMP and project schedule. After approval of these submitted documents, the PFS team will issue an authorization to proceed with the activities described in the finalized PMP and project schedule.

The TTI team has also developed a draft Systems Engineering Management Plan (SEMP) that documents how the technical development of the V2I Queue Advisory/Warning system will be managed and what needs to be documented. It also provides details on how the SE process needs to be tailored to be able to utilize queue related information from multiple data sources and applications (e.g., data from speed sensors, third-party data providers and V2I applications). Based on the review comments from CV PFS members and USDOT, researchers will revise the SEMP and submit a final version that addresses all feedback.

The TTI team will participate in monthly project status calls and submit monthly progress reports by the 15th of each month. The monthly report will include cost, schedule, and performance information necessary for monthly USDOT ITS JPO Program Management Office (PMO) reporting. The performance information will include deliverable status, accomplishments, current risk registry, and the planned activities for the next month.

Monthly team teleconferences are scheduled to be held on every third Thursday of the month. Researchers will prepare a progress report, schedule, scope issues, budget, task results and team meeting summaries.

A project closeout meeting will be held in the last week of the project. At this meeting, researchers will 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.

ASSESSMENT OF PRIOR WORK & STAKEHOLDER INPUT

The TTI team will conduct a detailed review and assessment of all INFLO Q-WARN documents and reports to determine how the results and findings of that research can be most effectively used in this project. The technical review will include a detailed assessment of all system components, communications flows, queue detection and message selection algorithms, and will identify key elements of the INFLO-QWARN system architecture that may serve as the basis on which the SE activities can be built in this project.

19

Researchers will also identify and review documentations related to recent and on-going developments of V2I Queue Advisory/Warning systems by state DOTs and other state/local agencies. This review will focus primarily on those systems that have the potential to utilize multiple data sources such as sensor data (e.g., speed, occupancy) from infrastructure-based sensors, or traffic data from third party data providers (e.g., vehicle speeds from INRIX or estimated queues from Waze). Researchers will also review literature of emerging research in using infrastructure sensors to generate pseudo CV like data of unequipped vehicles on freeways and intersections and how it can be used to enhance queue detection algorithms. In addition to detailed technical reviews, the identified systems will also be assessed based on their compatibility with existing standards as well as privacy and data rights.

To gather additional input and identify gaps, constraints and developing areas that need consideration in the SE activities in subsequent tasks, it is important to have continuous interaction with a broad group of stakeholders. Appropriate stakeholders will be identified in coordination with the CV PFS members. Selection criteria will include, but is not limited to:

• Stakeholder members should include representatives from entities that are actively involved in the deployments or operation of ITS infrastructure and applications relevant to V2I Queue Warning

• They should also include members from organizations and working groups who have expertise with the latest version of the national ITS architecture, standards and cross-cutting efforts.

Organizations and entities that may be considered for stakeholder selection include, but is not limited to, the following:

• State/local DOTs • American Association of State Highway and Transportation Officials (AASHTO) • ITS America • Cooperative Automated Transportation (CAT) Coalition groups AV Groups • Standards working groups We will try to identify people with interest and expertise in the following areas:

• Congestion management • Traffic Sensor Data • Third-Party Traffic data • ITS infrastructure deployment and operation • TMC operation • CV/V2I applications, deployment, testing • Communications related to ITS, CV and V2I applications The TTI team will create an initial list of stakeholders and submit it for review to the US.DOT/ CV PFS team and project advisory panel. The list will also be discussed with the project advisory panel during one of the monthly calls. Based on the feedback and recommendations the TTI team will revise the list and contact each person by phone or email. The finalized list will

20

include those stakeholders who commit to perform all required document reviews and participate in the walkthrough meetings in person or remotely. Stakeholders will be engaged throughout the entire project. They will be asked to review and provide feedback on draft technical documents and reports, participate in meetings and discussions. If needed, additional stakeholders will be identified in the course of the project. The TTI team will document the findings of their assessment of relevant prior work related to V2I queue Advisory/Warning in a draft technical paper. The draft technical paper will be shared with the selected group of stakeholders. As an initial task, they will be asked to review the draft technical paper, provide feedback on its content and make recommendations for enhancement. Researchers will revise the draft technical paper based on the input received from stakeholders and the observations, recommendations and comments made by members of the CV PFS. A changelog of document changes will be kept throughout the process to track comments, their origin, and the response. CONCEPT DEVELOPMENT The TTI team will develop a Concept of Operations (ConOps) document for V2I Queue Advisory/Warning Applications that includes infrastructure/sensor-based data, CV data and third-party data. The high-level ConOps will define system/user needs, identify operational constraints and use cases, and define system architecture that provides enterprise views and representations. The use cases will represent different queue formation scenarios, queue warning application types and various combinations of data source availability for queue detection and prediction. Definition of user needs will be adjusted and refined in an iterative process to ensure that they adequately cover all use cases.

It is anticipated that market penetration of connected vehicles will be low in the early stages of the adoption of connected vehicle-based queue warning system technologies. Therefore, it is expected that the need for infrastructure-based traffic sensor data and third-party travel time and traffic data to monitor traffic conditions, and infrastructure-based signs to disseminate traffic and travel information to drivers will continue to have significant role in managing traffic on the roadway network. Until the percentage of connected vehicles increases significantly, these constraints will require the adoption of a modular and hybrid approach in the development of new queue warning applications where input data from multiple sources (infrastructure, connected vehicle, and third-party data providers) will be fused together to detect queues accurately and provide proper queue warning messages. As the penetration rate of connected vehicles increases over time, some of these algorithms might be able to rely on information collected from connected vehicles only without the need for data from other sources. The formulation of needs and constraints should consider these realities.

Examples of user needs that consider the availability or lack of certain data sources in a hybrid queue warning system:

• Traffic Operations needs to be able to detect a queue formation using data from any combinations of the following data sources such as infrastructure/sensor, connected vehicle sources and/or third-party data providers.

21

• Traffic Operations needs to be able to predict queue formation using data from any combinations of the following data sources such as infrastructure/sensor, connected vehicle sources and/or third party data providers.

Examples of constraints that account for the potential unavailability of one or more data sources:

• Queue detection and warning algorithms of different type of queue warning systems (i.e., sensor-based, connected vehicle based or third-party data based) must be designed to be able to function independently and in a modular fashion.

• Queue detection and warning algorithms must continue to function in the absence of either infrastructure, connected vehicle or third-party data. The algorithm should detect queues and produce queue warning messages even if some data sources are not available.

TTI researchers will develop the draft V2I Queue Advisory/Warning ConOps in close coordination with the CAMP EDCM project. CAMP is expected to provide significant input and material from the vehicle perspective. They will provide the vehicle-related portions of the ConOps, and the TTI team will incorporate those into their concept document. The TTI team will follow the EDCM project activities and will review their draft deliverables that are relevant to the development of the V2I QA/QW ConOps. The two project teams will hold regularly scheduled joint meetings to discuss interrelated portions of the ConOps development activities in the V2I AQ/QW and EDCM projects. They will also identify potential scheduling issues, constraints and risks, and will recommend actions to manage those risks. Based on the discussions and coordination with the CAMP EDCM project team, the TTI team will identify the connected vehicle data elements required for the V2I QA/AW application. The CAMP team will define the vehicle-side requirements for being able to generate these CV data elements, and any constraints that may limit the ability to receive the CV data on the infrastructure side. These requirements and constraints may be related to security, communications, positioning, standards, and access to new technologies like Advanced Driver Assistance Systems (ADAS) that are available in new cars. Some of these discussions have already been initiated with the CAMP EDCM project team during the weekly meetings. A Concept of Operations that can utilize EDCM-specific CV-data, sensor data from existing infrastructure-based systems and third party traffic data will make future deployment more flexible and customizable to local conditions with different data availability and information dissemination options (e.g., to vehicles, mobile devices, TMCs). The TTI team will submit the draft ConOps for an initial review by the CV PFS team. Based on the comments received, researchers will revise the draft document and resubmit it to the CV PFS team and a group of selected stakeholders. They will have at least two weeks to review the document before an in-person walkthrough meeting is conducted to present all details of the ConOps document and gather input and feedback from the participants. The meeting will be setup and conducted in coordination with the CV PFS and the USDOT. It is expected that a two-day meeting is needed with webinar options for those who cannot attend in person. Based on the stakeholder feedback received, researchers will prepare a Revised ConOps document and a Comment Resolution Report.

22

Researchers will also develop a draft technical memo that includes details on:

• Proposed methods (including modeling development) • Metrics for Performance Measurement for

o functionality of V2I Queue Advisory/Warning Applications o components/factors affecting application (e.g., latency, reliability, etc.) o system performance o future impacts assessments.

The draft technical memorandum will be revised based on initial comments by CV PFS and USDOT.

SYSTEM REQUIREMENTS Researchers will develop the system requirements in close coordination with the CAMP EDCM project. They will follow the EDCM project activities, review their requirements defined from the vehicle point-of-view and incorporate some of the content that is relevant to this effort. TTI researchers will also review any draft deliverables produced by the CAMP EDCM project that are likely relevant to the QA/QW system requirements. TTI anticipates conducting regularly scheduled joint meetings with the CAMP EDCM team to discuss interdependent portions of the system requirements development in the two projects.

The QA/QW system requirements will be developed for a hybrid system that can work with any combination of the three major sources of data: connected vehicle data, infrastructure sensor data, and third-party data. The coordination with CAMP EDCM project will ensure that the QA/QW system requirements to be developed will take into consideration the EDCM-specific system requirements related to connected vehicle data. The CAMP EDCM project team will identify the vehicle-side requirements that the TTI team will incorporate into their V2I QA/QW System Requirements document.

The draft System Requirements Document for V2I Queue Advisory/Warning Applications will provide details on:

• Requirements o Functional requirements o Non-functional requirements o Interface requirements o Performance requirements o Data requirements

• Needs to Requirements (NTR) matrix - Provides backward traceability to user needs defined in the ConOps document.

System requirements will be developed in a format similar to the functional requirements of the INFLO connected vehicle-based queue warning application. TTI researchers will submit the draft document to CV PFS and USDOT for review, and then revise it based on the feedback received.

23

The TTI team will also conduct an in-person walkthrough meeting to present all details of the System Requirement Document and review its completeness and correctness. Before the meeting, they will develop a system requirements walkthrough plan and workbook using templates provided by USDOT. The meeting will be setup and conducted in coordination with the CV PFS and the USDOT. It is expected that a two-day meeting is needed with webinar options for those who cannot attend in person.

Based on the feedback received and documented at the walkthrough meeting, researchers will prepare a Revised System Requirements Document and a Comment Resolution Report.

HIGH LEVEL DESIGN TTI researchers will develop a high-level design (HLD) of the V2I Queue Advisory/Warning applications. Overall, the role of HLD is to link a system architecture with the system requirements. The system architecture shows the fundamental organization of a system, defining structure and behavior. A robust and fully developed architecture should detail all of the components, their relationships to each other, and the environment in which the system exists. Inherently, the architecture and the HLD provides answers to questions such as:

• What are the main functional elements for the applications to operate and interact? • What operational features and capabilities are required? • What are the various interfaces within the architecture? • How do the system components interact with one another and with the outside environment? • What information will be managed, stored, and presented? There are a number of different organizations with published standards on representing system architectures, such as Institute of Electrical and Electronics Engineers (IEEE) and International Council on Systems Engineering (INCOSE). For this project, the systems architecture methodology will be followed pursuant to ISO/IEC/IEEE Standard 42010-2011 (IEEE Recommended Practice for Software Architecture Descriptions). A rigorous document, IEEE 42010-2011 sets forth numerous requirements for detailing the viewpoints, framework, and descriptions associated with a complete systems architecture.

The system architecture of a hybrid queue advisory/warning system will include subsystems that can utilize and aggregate data from different sources (e.g., connected vehicle, infrastructure and third-party data providers). At any given time, depending on the invoked use case and availability of data sources, any combination of these unique subsystems and their interfaces can be active simultaneously. It is envisioned that the queue warning portion of the INFLO system architecture delineated by a red polygon in Figure 6 may be used as a starting point with modifications to accommodate the additional queue warning sub-system modules for additional data sources.

24

Figure 8. System Architecture of INFLO TME-Based Queue Warning/Speed Harmonization System

The TTI team will develop the HLD in close coordination with the CAMP EDCM project. They will follow relevant EDCM project activities, review their high-level design from the vehicle point-of-view and incorporate some of the content that is relevant to this effort. TTI researchers will also review any draft deliverables produced by the CAMP EDCM project that are likely relevant to the HLD in this effort. TTI anticipates conducting a webinar-based meeting with CAMP representatives to discuss relevant portions of the two projects related to QA/QW HLD development. This will ensure that the overall HLD is compatible with the EDCM architecture.

Following completion of the HLD, the research team will perform traceability checks across the concept of operations and the system requirements using a requirements traceability matrix. At the conclusion of this effort, the research team will document the results in the Design Verification technical memo. The research team will also revise the HLD by removing any inconsistencies identified via traceability. If these revisions trace back to earlier submitted documents, such as the Concept of Operations, those documents will also be revised and updated to ensure conformity across all the entire document set and flow of information.

After the HLD task completion, the research team will conduct a detailed, and in-person, walkthrough of the HLD with the intent of demonstrating completeness and technical soundness. This walkthrough will be guided by a comprehensive resource kit using DOTS supplied templates. This walk-though, which will also have webinar capabilities, is anticipated to take up to two full days. The research team will provide comprehensive note taking capabilities throughout the presentation and discussions. The results of the webinar will be used to revise any

25

system document as necessary and provide a comments resolution report indicating the item, need, source, and resolution.

COORDINATION WITH CAMP EDCM PROJECT After project initiation, a meeting with CAMP EDCM project representatives will be organized to discuss the projects’ timelines and planned activities. Since there may be factors that result in variation from planned schedules, the TTI research team will develop a project coordination document that identifies upcoming planned interactions between the projects and regularly update it as needed to ensure that both projects have a common understanding of timelines.

Researchers will participate in joint meetings and workshops with the CAMP EDCM project team 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, researchers will participate in discussions via teleconference/web conference during specific project phases.

Researchers will review CAMP EDCM Project draft deliverables relevant to V2I Queue Advisory/Warning (i.e., EDCM Architecture and Data Framework), provide written comments related to the technical content of the documents, and participate in meetings to discuss the comments as necessary.

There may be differences in how the SE process is applied by CAMP in the EDCM project and the TTI team in the V2I QA/QW project. Therefore, the SE processes will be discussed in the coordination meetings and included in the project coordination documents. This will ensure a common and consistent understanding of SE roles and responsibilities.

26

REFERENCES

1. ISO/IEC IEEE 24748-4-2016, Systems and software engineering - Life cycle management - 4: Systems engineering planning.

2. FHWA Final Rule (23 CFR 650 and 940) Intelligent Transportation System Architecture and Standards. https://ops.fhwa.dot.gov/its_arch_imp/archrule_final_1.htm

3. ISO/IEC/IEEE 15288:2015(E), Systems and Software Engineering—System Life Cycle Processes.

4. ISO/IEC/IEEE 24748-1:2018(E): Systems and software engineering - Life cycle management - Part 1: Guidelines for life cycle management

5. ISO/IEC IEEE 24748-2-2012, Systems and Software Engineering - Life Cycle Management - Part 2: Guide to the Application of ISO/IEC 15288 (System Life Cycle Processes)

6. Systems Engineering for Intelligent Transportation Systems. An Introduction for Transportation Professionals. Publication No. FHWA-HOP-07-069, January 2007. https://ops.fhwa.dot.gov/publications/seitsguide/

7. Systems Engineering Guidebook for Intelligent Transportation Systems. Ver 3.0, FHWA, California Division, Nov. 2009. (https://www.fhwa.dot.gov/cadiv/segb/)finale

8. B. Eisenhart. ITS ePrimer. Module 2: Systems Engineering ITS Professional Capacity Building Program (https://www.pcb.its.dot.gov/eprimer/module2.aspx)