Multi-Modal Intelligent Traffic Signal Systemcts.virginia.edu/wp-content/uploads/2019/07/MMITSS_PMP... · 2019-07-25 · Pool Fund: Multi-Modal Intelligent Traffic Signal System PMP

Pool Fund: Multi-Modal Intelligent Traffic Signal System PMP Version 2.0 June 2019

PROJECT MANAGEMENT PLAN

FOR THE

Multi-Modal Intelligent Traffic Signal System Deployment Readiness Enhancements

(Phase III) Version 2.0

June 2019

University of Arizona (Lead) University of California, California Partners for Advanced Transportation

Technology (PATH) Program


1

PREFACE This Project Management Plan (PMP) is intended to provide guidance on the management of the Pool Fund: Multi-Modal Intelligent Traffic Signal System (MMITSS) Phase III project.

This project is called the “Multi-Modal Intelligent Traffic Signal System Phase 3: Deployment Readiness Enhancements” project for the CV PFS “Program to Support the Development and Deployment of Connected Vehicle Applications.” The CV PFS was created by a group of state and local 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) is supporting VDOT on the pooled fund study, serving as the technical and administrative lead for the effort.

The plan has been tailored from the Space and Naval Warfare (SPAWAR) Systems Center (SSC) San Diego Project Management Plan Template, TM-PP-01. The template conforms to the Institute of Electrical and Electronics Engineers (IEEE) Standard for Software Project Management Plans, IEEE Std 1058-1998, for format and content. The template and its standard were selected as they are flexible enough to be applied to any type of project. The management, technical, and supporting processes comply with the guidance provided by Standard for Information Technology - Software Life Cycle Processes, IEEE/Electronic Industries Association (EIA) 12207 Series; Systems Engineering – System Life Cycle Processes, International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC) 15288; or the Processes for Engineering a System, Electronic Industries Alliance (EIA) Standard 632; and the SSC San Diego Systems/Software Engineering Management Policy.

This document has been modified to meet the needs and expectations of the Multi-Modal Intelligent Traffic Signal System (MMITSS) project.

The MMITSS Principal Investigator (Professor Larry Head) assumes responsibility for this document and updates it as required to meet the needs of the Sponsor. Updates to this document are performed in accordance with the MMITSS Configuration Management Process.


2

RECORD OF CHANGES *A - ADDED M - MODIFIED D – DELETED

VERSION NUMBER

DATE

NUMBER OF FIGURE, TABLE OR PARAGRAPH

TITLE OR BRIEF DESCRIPTION

CHANGE REQUEST NUMBER

1.0

6/2018

1/2019

-

Draft

Changes requested by Melissa Clark

-


3

TABLE OF CONTENTS Section Page

SECTION 1. OVERVIEW .................................................................................................................. 5 1.1 PROJECT SUMMARY .................................................................................................................... 5

1.1.1 Purpose, Scope, and Objectives ............................................................................................ 5 1.1.2 Assumptions and Constraints ................................................................................................ 5 1.1.3 Project Deliverables .............................................................................................................. 6 1.1.4 Master Schedule ................................................................................................................... 6

1.3 DOCUMENT STRUCTURE ............................................................................................................. 8

SECTION 2. REFERENCES................................................................................................................ 9 2.1 STANDARDS AND DOCUMENTS ................................................................................................... 9 2.2 DEVIATIONS AND WAIVERS ......................................................................................................... 9

SECTION 3. DEFINITIONS ............................................................................................................. 10

SECTION 4. PROJECT ORGANIZATION .......................................................................................... 12 4.1 EXTERNAL INTERFACES .............................................................................................................. 12 4.2 INTERNAL STRUCTURE ............................................................................................................... 13

SECTION 5. MANAGEMENT PROCESS .......................................................................................... 15 5-1 START-UP .................................................................................................................................. 15 5.2 Budget and Cost Control ............................................................................................................ 15 5.3 Quality Control .......................................................................................................................... 15 5.4 RISK MANAGEMENT .................................................................................................................. 16 5.5 Human Resource Management ....................................................................................................... 18 5.6 Scope Management ........................................................................................................................ 18

SECTION 6. SUPPORTING PROCESSES .......................................................................................... 19 6.1 CONFIGURATION MANAGEMENT .............................................................................................. 19

APPENDICES ................................................................................................................................. 21

APPENDIX A. TASK DESCRIPTIONS .............................................................................................. 21 Task 1 - Project and Systems Engineering Management ....................................................................... 21 Task 2 – Cross-Cutting Activities ........................................................................................................... 22

It is our understanding that the USDOT Intelligent Transportation Systems Joint Program Office ...... 22 Task 3 – Enhancement of Existing MMITSS Prototypes ......................................................................... 25 Task 4 – Field Test and Demonstration ................................................................................................. 29 Task 5 – Technical Assistance to Deploy MMITSS ................................................................................. 33


4

LIST OF FIGURES

Figure Page

FIGURE 1. GANTT CHART OF MULTI-MODAL INTELLIGENT TRAFFIC SIGNAL SYSTEM PHASE III. ..................................... 7 FIGURE 2. GANNT CHART OF MMITSS - TASK 3 ............................................................................................................ 7 FIGURE 3. GANTT CHART TASKS 4 AND 5. .................................................................................................................... 8 FIGURE 4. EXTERNAL ORGANIZATIONAL INTERFACES................................................................................................. 12

LIST OF TABLES Table Page

TABLE 1. LIST OF DELIVERABLES AND DUE DATES ........................................................................................................ 6 TABLE 2. PROGRAMMATIC ROLES AND RESPONSIBILITIES ......................................................................................... 13 TABLE 3. RISK MANAGEMENT SPREADSHEET ............................................................................................................. 17 TABLE 4. TEAM ROLES AND RESPONSIBILITIES ........................................................................................................... 18 TABLE 5. TASK 1 PLANNED DELIVERABLES ................................................................................................................. 22 TABLE 6. TASK 2 PLANNED DELIVERABLES ................................................................................................................. 25 TABLE 7. TASK 3 PLANNED DELIVERABLES ................................................................................................................. 29 TABLE 8. TASK 4 PLANNED DELIVERABLES ................................................................................................................. 33 TABLE 9. TASK 5 PLANNED DELIVERABLES ................................................................................................................. 33


5

SECTION 1. OVERVIEW

1.1 PROJECT SUMMARY

The proposal for this project was developed in response to the request for proposal (RFP) from the Connected Vehicle Pooled Fund Study (CV PFS) to improve deployability of the MMITSS prototypes to address needs identified by the Pooled Fund Members, stakeholders, and the MMITSS developers (University of Arizona and California PATH program).

This project is called the “Multi-Modal Intelligent Traffic Signal System Phase 3: Deployment Readiness Enhancements” project for the CV PFS “Program to Support the Development and Deployment of Connected Vehicle Applications.” The CV PFS was created by a group of state and local 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) 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/.

1.1.1 Purpose, Scope, and Objectives

In order to make the MMITSS bundle and associated applications readily deployable, the goals of this project are to enhance the existing MMITSS prototypes that were developed and field tested in Anthem, Arizona (AZ), and Palo Alto, California(CA) and to make the MMITSS software code widely deployable with as little code customization as possible.

The objectives of this project are:

• To prioritize the enhancement components based on the United States (US) • Department of Transportation’s (DOT) preliminary research plan, high-level gap analysis

document, and feedback from past stakeholder engagement activities. • To enhance the existing MMITSS prototypes to expedite the deployment, which includes, but

not limited to, control interface, message standard version, security, control logic and generic application algorithm.

• To work, coordinate and collaborate with other deployers (including CV Pilots and Smart Cities) / standard groups / Crash Avoidance Metrics Partnership (CAMP) / Original Equipment Manufacturers (OEM) to build on existing research and avoid duplication where possible.

• To conduct field testing/demonstration of the enhanced components of the Multi-Modal Intelligent Traffic Signal System (MMITSS).

Improvements in Phase III include creating a more robust and maintainable application code that is hardware agnostic and interoperable or transferable regardless of the hardware vendors or products.

1.1.2 Assumptions and Constraints

Since this project is being conducted under a larger umbrella pool fund program the system being considered will operate within the cooperative “Connected Vehicle System” where vehicles communicate to an equipped infrastructure. The communications will include, but not be limited to, 5.9 Gigahertz (GHz) Dedicated Shore Range Communication (DSRC) and use messages consistent with the SAE J2735 standards being developed, as well as US DOT efforts for Signal Phase and Time (SPaT) and Map Data (MAP) messages and the National Transportation Communications for Intelligent Transportation System Protocol (NTCIP) standards for traffic management and control.


6

1.1.3 Project Deliverables

The deliverables created in this project are intended to investigate the enhancement of existing MMITSS prototypes to make the system readily deployable. The deliverables are summarized in Table 1 below with a project start date of February 1, 2018 as denoted in the Project Plan shown in 1.1.4 Master Schedule. Table 1. List of Deliverables and Due Dates

Task Name and Deliverable Project Relative Date Task 1 – Project Management and Systems Engineering Management Briefing Materials, Kick-Off Meeting March 2018 Draft PMP February 2018 Draft SEMP February 2018 Draft Project Schedule February 2018 Final PMP June 2019 Final SEMP June 2019 Final Project Schedule June 2019 Monthly Progress Reports Monthly Briefing Materials, Closeout Meeting (Assume this reporting will occur at the December 2019 CV Pooled Fund Meeting) December 2019 Task 2 – Cross Cutting Activities Monthly reports of the cross-cutting activities Monthly MMITSS Development Group Meeting May 2018 Draft Deployment Readiness Development Plan and Briefing June 2018 Final Deployment Readiness Development Plan May 2019 Task 3 - Enhancement of Existing MMITSS Prototypes Code to GitHub MMITSS-Public Repository (previously Code to the OSADP) Quarterly (as available) Task 4 – Field Test and Demonstration Draft Deployment and Field Test Plan August 2019 Final Deployment and Field Test Plan September 2019 Field Demonstration December 2019 Data and Test Results to the RDE December 2019 Draft Task 4 Report November 2019 Final Task 4 Report December 2019 Task 5 – Technical Assistance to Deploy MMITSS Select MMITSS Technical Support Recipient (new MMITSS deployment site) August 2019 Draft MMITSS Deployment Guidance document October 2019 Final MMITSS Deployment Guidance document November 2019 MMITSS Results and Guidance meeting/webinar December 2019 Draft MMITSS Deployment Lessons Learned report November 2019 Final MMITSS Deployment Lessons Learned report December 2019

1.1.4 Master Schedule The Master project schedule is shown in Figure 1 below. Because of the size of the schedule, the Task 3,


7

4, and 5 details are shown in separate figures below. The schedule is used to guide the team to so that the updates and enhancements are completed in time to conduct the 90-day field test (Task 4). The duration and sequence (precedence) was estimated based on logic development planning, but could be flexible due to implementation details and challenges.

Figure 1. Gantt Chart of Multi-Modal Intelligent Traffic Signal System Phase III.

Figure 2. Gannt Chart of MMITSS - Task 3


8

Figure 3. Gantt Chart Tasks 4 and 5.

1.3 DOCUMENT STRUCTURE

General Guidance

This plan is organized as follows: a. Section 1, Project Overview. This section provides an overview of the scope and objectives of

the project, the project’s assumptions and constraints, reference to the project deliverables, schedule and budget, and a description of the evolution of the plan.

b. Section 2, References. This section provides a list of all documents, policies, templates, processes, and other sources of information referenced in the plan.

c. Section 3, Definitions. This section contains the abbreviations and acronyms required to properly understand this planning document.

d. Section 4, Project Organization. This section identifies interfaces to organizational entities external to the project, the project’s internal organizational structure, and defines roles and responsibilities for the project.

e. Section 5, Project Management Process. This section describes the management, technical, and supporting processes.

f. Section 6, Supporting Processes. This section describes the processes used to support the project including configuration management.


9

SECTION 2. REFERENCES

2.1 STANDARDS AND DOCUMENTS The standards and documents listed below are referenced in this document:

a. A Description of the SSC San Diego Standard Process Assets (SPA), PR-OPD-35, SSC San Diego b. Institute of Electrical and Electronics Engineers (IEEE) Standard for Software Project Management

Plans, IEEE Standard 1058-1998, IEEE, December 1998 c. Project Management Plan Template, TM-PP-01, SSC San Diego

2.2 DEVIATIONS AND WAIVERS Deviations and/or waivers from the project’s documented standard processes or procedures will be defined in the individual build plans as necessary and approved by agreement between the project manager and the program manager.


10

SECTION 3. DEFINITIONS

The abbreviations and acronyms used throughout this document are listed below:

BIM Basic Infrastructure Message

CAMP Crash Avoidance Metrics Partnership

CM Configuration Management

CoE College of Engineering

CONOPS Concept of Operations

CTS Center for Transportation Studies (University of Virginia)

CTS PFS Cooperative Transportation Systems – Pool Fund Study

CV Connected Vehicle

DOT Department of Transportation

DSRC Dedicated Short Range Communications

FHWA Federal Highway Administration

GRA Graduate Research Assistant/Associate

GPS Global Positioning System

MMITSS Multi-Modal Intelligent Traffic Signal System

MPP Microsoft Project Plan

NCHRP National Cooperative Highway Research Program

OSADP Open Source Application Development Portal (US DOT)

PATH Partners for Advanced Transportation Technology (PATH) is administered by the Institute of Transportation Studies (ITS) at the University of California, Berkeley

PDF Portable Document Format

PFP Pooled Fund Project

PFS Pooled Fund Study

PI Principal Investigator

PMP Project Management Plan

RFP Request for Proposal

SAE Society of Automotive Engineers

SEMP Systems Engineering Management Plan

SVN Subversion Version Control System

TRB Transportation Research Board

UA University of Arizona

UVa University of Virginia


11

WBS Work Breakdown Schedule


12

SECTION 4. PROJECT ORGANIZATION

4.1 EXTERNAL INTERFACES External organizational interfaces and the chain-of-command for the MMITSS Project are defined in Figure 4.

Figure 4. External Organizational Interfaces. The responsibilities of the organizational entities and key positions shown in and are defined in Table 2.


13

Table 2. Programmatic Roles and Responsibilities POSITION ROLES/RESPONSIBILITIES

CV PFS (Virginia Lingham, VDOT)

Project Manager for the Connected Vehicle Pooled Fund Study

Technical and Advisory Lead (Brian Smith, UVA)

Principal Investigator for the Connected Vehicle Pooled Fund Study which is the overall project tasked to develop infrastructure based connected vehicle applications

Project Manager (Hyungjun Park, UVA)

Responsible for Project Management and Oversight

Project Panel • Champion: Greg Larson (Caltrans),

Faisal Saleem (MCDOT), Gene McHale (FHWA)

• Members: Blaine Leonard (Utah), Chuck Felice (Utah), Virginia Lingham (Virginia), Jianming Ma (Texas), Raj Ponnaluri (Florida), Hua Xiang (Maryland), Govind Vadakpat (FHWA), Debora Curtis (FHWA), Vanloan Nguyen (Virginia), Michael Clements (Virginia), Ahmad Jawad (Oakland County), Reza Karimvand (Arizona);

• References: Ray Derr (TRB)

Provides direction, review, and input to the Project Manager and Project team

Project Team PI: Larry Head, UA Co-PI: Kun Zhou, PATH

Responsible for the management and technical leadership of the project.

Project Team

Team members are responsible for contribution to technical execution of the project plan. PI for each Team organization is responsible for the team members at that organization. UA: Sherilyn Keaton, Senior Software Engineer Niraj Altekar, Graduate Research Assistant Debashish Das, Graduate Research Assistant Jane Gatzemeier, Undergraduate Research Assistant Drake Sitaraman, Undergraduate Research Assistant PATH: John Spring, R&D Engineering 4 Huadong Meng, Research Engineer David Nelson, , R&D Engineering 4

4.2 INTERNAL STRUCTURE

The Project Team is led by the PI (Dr. Larry Head) and co-PI (Dr. Kun Zhou). Dr. Head will be responsible for management of all management and technical aspects of this project. He will be


14

assisted in the management of the budget, cost controls, and human resource management by Dorothy Ashton (Accountant Assistant, Old Engineering Business Center, University of Arizona).

Project Team members from PATH and the technology partners will be contributors to the task developments as defined in the scope of work. The PATH Project Team members will be managed by Dr. Kun Zhou. Both teams will work on assigned tasks to provide a set of common components that will be designed to integrate with both prototypes being updated, MMITSS-AZ and MMITSS-CA. A repository has been created on GitHub for these common components and development efforts. Internal team requests and issues are tracked in the Issues tool specific to the repository

.


15

SECTION 5. MANAGEMENT PROCESS

5-1 START-UP

This project does not require any special training, staffing, or resource allocation in order to begin the project.

5.2 Budget and Cost Control The Principal Investigator (PI) is responsible for ensuring the project costs meet the planned budget.

Cost management establishes mechanisms, processes, and or procedures to measure, monitor, and control the cost of work completed, comparison of planned-to-budgeted cost, and corrective actions when controls are out of bounds. The MMITSS Project will use an updated version of the MIMITSS Project Plan (MPP) (named MMITSS_PhaseIII.mpp) as the baseline of labor estimates at a tasking level. The cost estimates for travel and material/supply costs are defined in the original proposal. On a monthly basis the MMITSS PI will compare the MPP baseline with the actual task progress to determine if task costs are within bounds. Also on a monthly basis, the costs associated with travel and materials/supplies will be compared with the budgeted amounts in the proposal. Deviations greater than 10% will be considered “out of bounds” and detailed in the quarterly report.

In all cases, the PI maintains total control over the resolution of any problems that are identified. If either the problem or the corrective action taken constitutes a program risk, the risk is quantified, minimized as much as possible, and added to the risk management database along with its contingency actions.

5.3 Quality Control The MMITSS Project quality management approach is defined to ensure that the project objectives are attained in a timely and useful manner: (1) this PMP and the associated SEMP; (2) Cross Cutting Activities, including engagement with standards organizations/committees, CAMP, and other sites interested in MMITSS; (3) Enhancement of the Existing MMITSS prototypes; (4) Field Testing and Documentation; and (5) Support for additional MMITSS deployments.

Six metrics have been defined to ensure these Project Objectives are achieved:

Tracking and Oversight – The tracking and oversight metrics are defined more specifically in the Scope Management and Cost Management sections. The MMITSS Project quality management approach defines a monthly assessment, auditing, and reporting process to ensure that progress on the project objectives are occurring within scope and cost bounds.

Briefings, Meetings, and Communications – A structured and planned approach for collaborating and sharing information is defined as follows:

Internal Team Meetings – Teleconferences are scheduled to occur at least weekly as team member’s schedules permit. A Zoom online meeting connection is used for each meeting. The Zoom is set up weekly. Materials reviewed in the weekly teleconferences will be made available through the MMITSS Project Box repository prior to the meeting. Access can be provided if requested.

Briefings – Monthly briefings will be held with the MMITSS Project sponsor and/or MMITSS Project Panel. In addition to technical and design information for the MMITSS Project objectives, these briefings will include updates on the monthly tasks defined throughout the PMP. Materials reviewed in the briefings will be made


16

available through the MMITSS Project Box repository and email attachment for those participants without access to the MMITSS Project Box repository.

Communications – As appropriate and needed, the MMITSS Project PI will offer communications via telephone, email, and physical mail. The MMITSS Project Box repository will serve as the primary source of technical information, since Configuration Management (CM) processes have been defined to ensure the timeliness and integrity of the content. Meeting minutes for MMITSS Project teleconferences and meetings will be available through the MMITSS Project Box repository and useful for assessing recent and historical progress on tasking and technical pursuits.

Documentation Quality – As part of the Communications Management approach, feedback on documentation contents is solicited and incorporated using the CM processes defined for this project. The CM processes and use of the MMITSS Project Box repository ensure that all internal and external MMITSS Project participants have access to the most current version of a document as well as useful historical information. In addition to accessibility and integrated feedback, the originating author of a document has change control authority to ensure that suggested changes are incorporated properly. In most instances, this change control is achieved through Microsoft Word “Track Changes” functionality.

5.4 RISK MANAGEMENT

The strategy to manage project risk is to continually monitor and track potential project risk. Table 3. Risk Management Spreadsheet, is the risk tracking matrix that will be used in risk management. Each risk will be assigned an ID and a Risk Owner. A summary of the risk will be included (Risk Statement) and the potential impact to the project (Impact Statement) will be provided to allow reviewers to understand the risk. If the risk is directly associated with a project task, a reference to the Work Breakdown Schedule (WBS) shall be included. The Likelihood and Severity will be estimated (High (0.9 - Red), Medium (0.5 - Yellow), or Low (0.1-Greeen)) and a Risk Score = Likelihood * Severity will be used to assess the criticality of the risk. Risks can be identified by any member of the project team, the UVA project management team, and the MMITSS Project panel members. Risks shall be reviewed in the weekly team project teleconferences and included in the monthly progress meetings. Any risk that as a high Risk Score (Greater than 0.5) shall be reported to the CV Pooled Fund Project Manager immediately. Risks shall be tracked and managed until they the management team is satisfied that they have be adequately mitigated. When a risk has been addressed, it shall remain in the risk table, but labeled “Closed” in the Risk Score column (Blue).


17

IDWBS&

Element Risk&StatementImpact&

StatementRisk&

OwnerRisk&

LikelihoodRisk&

Severity Risk&Score Mitigation&Strategy

<#>

X.X.X&'&reference&to&relevant&WBS&item

Brief&summary&statement&capturing&nature&of&the&identified&risk

How&the&risk&might&impact&the&project

Person&who&is&responsible&for&&managing&mitigation

[low(0.1),&medium(0.5),&high(0.9)]

[low(0.1),&medium(0.5),&high(0.9)]

Likelihood&*&Severity How&will&the&risk&be&managed?

Risk&Identification&and&Assessment Risk&Response

Table 3. Risk Management Spreadsheet


18

5.5 Human Resource Management

The roles and responsibilities of the project management team, project panel, and project technical team are defined in Table 4 below.

Table 4. Team Roles and Responsibilities

Task Assignment\ Team Member

Project Role and Responsibility

Brian Smith, UVA Review, Approve Hyungjun Park, UVA Review, Approve Virginia Lingham, VDOT Review, Approve Greg Larson (Caltrans) Review Faisal Saleem (Maricopa County in Arizona)

Review

Gene McHale (FHWA) Review Govind Vadakpat (FHWA) Review Blaine Leonard (UDOT) Review Chuck Felice (UDOT) Review Jianming MA (TxDOT) Review Raj Ponnaluri (FDOT) Review Hua Xiang (Maryland) Review Deborah Curtis (FHWA) Review Vanloan Nguyen (VDOT) Review Michael Clements (VDOT) Review Ahmad Jawad (Oakland County)

Review

Reza Kariomvand (ADOT) Review Ray Derr (TRB/NSHRP) Review Larry Head, UA Project Lead

Lead AZ Test Bed Input

Sherilyn Keaton, UA Input (Software Engineering) Niraj Altekar, UA Input (Traffic Control) Debashish Das, UA Input (Priority Control) Jane Gatzemeier, UA Input (Software) Drake Sitaraman, UA Input (Software) Kun Zhou, PATH Co-PI

Lead CA Test Bed Input

John Spring, PATH Input (Software Engineering) Huadong Meng, PATH Input (Research) David Nelson, PATH Input (Software)

5.6 Scope Management The project tasks are summarized in Appendix A. The scope will be managed according to the defined project tasks to ensure successful delivery of the project.


19

SECTION 6. SUPPORTING PROCESSES

6.1 CONFIGURATION MANAGEMENT The evaluated metrics under CM include the proper work product identification, change control, records management, and change reports. Identification of work products is achieved through the establishment, adoption, and use of naming conventions. Change control of work products will be achieved through the process of initiating track changes described previously under Documentation Quality.

Work Product Identification: Unless stated otherwise, all electronic work products will be available through the MMITSS Project Box repository.

Item Filename

Project Plan Source: MMITSS_ProjectPlan_PhaseIII.mpp

Distribution: MMITSS_ProjectPlan_PhaseIII.pdf

Monthly Briefings Source: Phase3.MonthYearUpdate.pptx

Distribution: Phase3.MonthYearUpdate.pdf

Monthly Briefings Meeting Minutes Source: MMITSS_MonthYearMonthlyMeetingMinutes.docx

Distribution: MMITSS_MonthYearMonthlyMeetingMinutes.pdf

MMITSS Development Plan Source: MMITSS3_DevelopmentPlan.docx

Distribution: MMITSS3_DevelopmentPlan.pdf

MMITSS Development Group Monthly Meetings

Source: MMITSS.DevGroup.MM.DD.YYYY.pptx

Distribution: MMITSS.DevGroup.MM.DD.YYYY.pdf

MMITSS Source Code Source: MMITSS GIT Repository

Distribution: via OSADP

System Integration and Laboratory Testing Notebook

Source: MMITSS3 MMITSS3_DevelopmentPlan _SILT.docx

Distribution: MMITSS3_STP.pdf, MMITSS3 MMITSS3_DevelopmentPlan _STPMatrix.pdf

Limited Simulation Experiment Report Source: MMITSS3_SimExpReport.docx

Distribution: MMITSS3_SimExpReport.pdf

AZ Field Test Procedures Source: MMITSS3_AZFieldTestProcedure.docx

Distribution: MMITSS3_AZFieldTestProcedure.pdf

CA Field Test Procedures Source: MMITSS3_CAFieldTestProcedure.docx

Distribution: MMITSS3_CAFieldTestProcedure.pdf

AZ MMITSS System Performance Document

Source: MMITSS3_AZPerformance.docx

Distribution: MMITSS3_ AZPerformance.pdf

CA Test Results Source: MMITSS3_CATestResults.docx


20

Distribution: MMITSS3_CATestResults.pdf

CA MMITSS System Performance Document

Source: MMITSS3_CAPerformance.docx

Distribution: MMITSS3_CAPerformance.pdf

Final Documentation Source: MMITSS3_FinalReport.docx

Distribution: MMITSS3_FinalReport.pdf

21

APPENDICES This appendix contains the original Task Descriptions and Deliverable Schedule.

APPENDIX A. TASK DESCRIPTIONS

This project will consist of the following tasks:

• Task 1: Project and Systems Engineering Management • Task 2: Cross Cutting Activities • Task 3: Enhancement of Existing MMITSS Prototypes • Task 4: Field Test and Demonstration • Task 5: Technical Assistance to Deploy MMITSS

Task 1 - Project and Systems Engineering Management

The University of Arizona is responsible for contract management, monitoring, and control of the project. The project management team will include Principal Investigator Larry Head, assisted by Kun Zhou (PATH Project Manager) and Sherilyn Keaton (UA). The project management team will be responsible for progress monitoring and control of the project. The Project and Systems Engineering Management is comprised of the following subtasks:

• Participate in a project kick--off meeting. The meeting will be scheduled within two weeks of the project start date of February 1, 2018. This meeting will be conducted via remote conferencing service. The purpose of the meeting will be to review the approach to the project including work activities.

• A Systems Engineering Management Plan (SEMP) will be developed that describes an overall system engineering management approach for the project in which both development teams (MMITSS--AZ and MMITSS--CA) will support.

• A detailed project schedule will be prepared that lists tasks, meetings, deliverables, and major milestones. The project schedule will be submitted electronically in Microsoft Project Plan (.MPP) format (MS Project 2010 or higher).

• A project management review meeting will be schedule with the Pooled Fund Study Members and USDOT Coordinator to review the PMP, SEMP, and project schedule (.mpp). On the basis of this review, the Pooled Fund Study Team will issue an authorization to proceed.

• Monthly progress conference calls will be held throughout the project. Meeting minutes, including action items will be submitted in PDF format within one week after the meeting.

• A monthly progress report will be compiled and submitted electronically to the Sponsors by the 15th of the month. In cases where the 15th of the month falls on a weekend, the report will be submitted the following Monday. The monthly progress report shall include estimated cost, schedule, executive summaries of technical deliverables, and performance information necessary for monthly USDOT 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), accomplishment and the planned activities for the next month. The report shall be formatted per the ITS JPO PMO templates that are available at http://www.its.dot.gov/project_mang/index.htm.

• The project team will attend team meetings or teleconferences as requested, prepare a report on progress, schedule, scope issues, budget, and results of tasks at team meetings, and, prepare team

22

meeting summaries, which will, at a minimum, track the status of action items.

• Larry Head (PI) will attend a project closeout meeting to be held during the last week of the project. During this meeting, they will present a summary of the work performed under each task, an overview and status of each deliverable, and total funds expended.

Table 5. Task 1 Planned Deliverables

Task 1 Deliverable Due Date

Briefing Materials, Kick-Off Meeting Within 4 weeks

Draft PMP 2 weeks

Draft SEMP 2 weeks

Draft Project Schedule 2 weeks

Final PMP 6 weeks

Final SEMP 6 weeks

Final Project Schedule 6 weeks

Monthly Progress Reports Monthly

Team Meetings Summaries Within 1 week of Monthly

Briefing Materials, Closeout Meeting 78 weeks

Task 2 – Cross-Cutting Activities

The goal of this project is to make the MMITSS prototypes and associated applications readily deployable and to enhance the existing MMITSS prototypes, conduct a field test at each site (MMITSS--CA and MMITSS--AZ), and make the MMITSS software widely deployable with as little code customization as possible. Significant consideration to other connected vehicle deployment efforts will be given in this project to determine how MMITSS can contribute and the deployment readiness needs of the current MMITSS prototypes. The purpose of Task 2 is to engage with the other critical activities including formation of a group of stakeholders that are implementing, or planning to implement MMITSS in the near future.

Task 2.1: Engage with ITS Standards Activities

Larry Head will continue to work with SAE DSRC Technical Committee. The work will include development of the J2945/x documents for MAP/SPaT and for Signal Priority and Preemption. Other activities include following the IEEE 1609 working group and NTCIP 1202 and 1211 efforts.

Task 2.2: Engage with other Groups (CVRIA, SCMS, etc)

The MMITSS team will review the current Connected Vehicle Reference Implementation Architecture (CVRIA) with respect to the MMITSS application and provide feedback to the FHWA and CVRIA developer. The review will include MMITSS requirements, architecture, and interfaces, as well as interoperability with other applications. Recommendations for updating the CVRIA tool to better reflect the MMITSS requirements, data, architecture, and interfaces will be provided.

It is our understanding that the USDOT Intelligent Transportation Systems Joint Program Office (ITS JPO) is working to develop a Security Credential Management System (SCMS) for the three CV pilots (March 2017). We will reach out to this effort to see if we can use a local SCMS or connect to the national SCMS for the MMITSS prototypes. We will investigate options for the SCMS, including using the USDOT

23

SCMS or a local copy for project purposes (Larry Head discussed this option with Jonathan Petit of Security Innovation, who is responsible for developing the SCMS for USDOT during a CV Pilot meeting in Tampa, FL on October 27, 2016). The MMITSS team believes that integration with the SCMS to provide security through message signing is primarily a system integration issue between the RSU devices and the SCMS, since both of these systems are responsible for signing the messages that are broadcast over the DSRC channels, checking the credentials of messages that are received, and maintaining the current revocation list. As such, we do not believe that changes to the MMITSS code is required for integration of SCMS--based security. The team will validate this assumption with the USDOT staff, SCMS developers, and DSRC vendors.

Task 2.3: Engage with Entities Deploying MMITSS

Currently, there are several active and planned MMITSS projects including:

• Tampa Hillsborough Expressway Authority (THEA) Connected Vehicle Pilot Deployment (MMITSS--AZ),

• Utah DOT Connected Vehicle Deployment (MMITSS--AZ),

• San Diego Port Tenants Association (via Peloton) (MMITSS--AZ),

• Columbus Smart City (via Peloton) (MMITSS--AZ),

• Vehicle-to-Infrastructure (V2I)--Hub Integration Project (MMITSS--AZ, Battelle, UA),

• Santa Clara Valley Transportation Authority (VTA), San Mateo County Transit Authority (SamTrans) and Metropolitan Transportation Commission (MTC) for CV--based Transit Signal Priority along El Camino Real

(MMITSS--CA),

• Los Angeles (LA) DOT (MMITSS--CA), and

• Potential MMITSS implementation with other interested agencies.

The MMITSS team will reach out to these projects to identify their needs with respect to MMITSS operations and potential enhancements required for future deployments and assess if MMITSS can be improved (overall) by addressing the needs. A short synopsis will be developed for each project that can be used by the Pooled Fund Members and USDOT Coordinator to determine which project teams should be invited to participate in the MMITSS User Group (See Task 2.6 below).

Task 2.4: Coordinate CV PFS Tasks including BIM, standards, and Other CV PFS Tasks

The MMITSS Team will work with the Pooled Fund Study Team to contact the PFS BIM contractor and discuss common interests. In addition, the MMITSS Team will review the BIM work that CAMP is championing with the SAE DSRC Technical Committee (through the J2945/4 task force). Any impact of the BIM or information MMITSS can provide to the BIM will be identified and reported to the Pooled Fund Panel.

Task 2.5: Coordinate with CAMP V2I Consortium and V2I Deployment Coalition

The MMITSS team will contact CAMP to explore how we can work more closely, especially to brief them on the capabilities of MMITSS and how some of the early CAMP--supported applications, including red light violation warning, spot weather impact, reduced speed zone/work zone, pedestrian in signalized cross walk, and transit warnings, could work cooperatively with MMITSS. The V2I Deployment Coalition and CAMP have identified several of these applications and are working together on the concepts to promote early adoption.

Task 2.6: The MMITSS Open Source Software Development Plan

The MMITSS Phase I and Phase II projects resulted in the development of two (2) prototype software systems referred to as MMITSS--AZ and MMITSS--CA. These prototypes have been submitted to the FHWA Open Source Application Development Portal (OSADP) and there are several teams using the source code to develop systems for projects. These projects include:

24

• THEA Connected Vehicle Pilot Deployment (MMITSS--AZ),

• Utah DOT Connected Vehicle Deployment (MMITSS--AZ),

• San Diego Port Tenants Association (via Peloton) (MMITSS--AZ),

• Columbus Smart City (via Peloton) (MMITSS--AZ),

• V2I--Hub Integration Project (MMITSS--AZ, Battelle, UA),

• VTA, SamTrans and MTC for CV--based Transit Signal Priority along El Camino Real

(MMITSS--CA),

• LADOT (MMITSS--CA), and

• Potential MMITSS implementation with other interested agencies.

The THEA CV Pilot Deployment and Utah DOT CV project are being led by system integration teams that are using, or plan to use, the source code available in the OSADP. The Port of San Diego and Columbus Smart City projects include the University of Arizona to support system integration and development. The V2I--Hub project is led by Battelle and includes the University of Arizona to integrate MMITTS--AZ. The VTA and LADOT projects are planning to utilize MMITSS--CA.

The Pooled Fund Panel has identified a need to improve the deployment readiness of MMITSS through enhancements, improved software, and support from the MMITSS research team (University of Arizona and California PATH Program. Note: Savari and Econolite are not included in the Phase III effort to help ensure the products are hardware agnostic.)

To address this need, the MMITSS Team proposes the establishment of the MMITSS Development Group (MDG) that includes key development members from each of the projects shown in the bulleted list, along with identified individuals that are actively using one of the MMITSS prototypes from the OSADP. Each of these organizations will assign a designated individual to the MDG who has “voting” rights on development planning decisions and priority establishment. The Pooled Fund Panel members will have “final voting” rights on these decisions.

The MDG will commence with a two-day kick-off meeting1 offering detailed presentations of the MMITSS prototypes, code reviews, needs identification and prioritization activities. The MMITSS research team will provide technical support and answers on questions regarding the build process, integration, host platform (e.g. Linux Ubuntu 14.04), standards, source code review (plans) and other topics identified by the MDG members. At the end of the kick--off meeting, a prioritized list of development needs will be identified. Possible and likely approaches will be identified and documented, including the MMITSS research team developing features/improvements, MDG participants/projects undertaking development, or a third--party developer doing the work. The group--defined, prioritized set of needs will be used to develop a plan and cost estimate for the work required to make MMITSS deployment ready.

The MDG activities will continue using a webinar format where source code walkthroughs and reviews will be conducted monthly, or as needed, as part of the effort to “clean up” the code and make it more usable by the MDG stakeholders who are engaged in deploying the code. The sequence of source code reviews will be based on the preference of the MDG stakeholders.

After the two--day kick--off meeting, a regular update schedule will be developed to ensure that the MDG members have access to the current version of MMITSS source code. For example, updates could be provided on a quarterly basis or sooner depending on the nature of the development effort and the ability of the selected team to develop and test associated changes.

At a minimum, the OSADP distribution will be updated quarterly. As members of the MDG identify additional

1 The MMITSS team proposed to hold this meeting at the Turner--Fairbank Highway Research Center in McLean, VA so that as many participants as possible can attend.

25

issues or needs, the group can hold virtual meetings (via remote conference services) to discuss solutions, needs, priorities, and development schedules. These virtual meetings will be offered quarterly, or more frequently, as needed.

The findings and activities of the MDG will be documented in the MMITSS Deployment Readiness Plan that will include:

• identification of enhancements needed to make MMITSS deployable,

• development cost estimates for each enhancement,

• prioritization of the identified enhancements by the Pooled Fund Panel, and

• documentation of projects and agencies that are actively engaged in using MMITSS or

are considering MMITSS as a solution.

The MMITSS Deployment Readiness Plan will be submitted to the Pooled Fund Panel/USDOT Coordinator and support for comment and review. The MMITSS team will brief the Pooled Fund Panel/USDOT Coordinator and support. A final plan will be based on the input received. The Draft MMITSS Development Plan will be submitted within 60-days from the start of the project.

The Final Plan will be submitted within 90-days of the start of the project, assuming a 2-week comment period for the Pooled Fund Panel/USDOT Coordinator and support.



Quarterly reports of the cross cutting activities Every quarter

Meeting Minutes Within 1 week of Meeting

Task 3 – Enhancement of Existing MMITSS Prototypes

The MMITSS prototypes represent the results of a research and development effort focused on a new approach to traffic control that utilizes information from connected vehicles, especially passenger vehicles, emergency vehicles, transit, trucks, and pedestrians. The prototypes were developed to the level of maturity required to support field testing, proof--of--concept, and demonstrations. It is acknowledged that they are not ready for deployment and additional development is needed to ensure that they have greater utility to the projects planning to use them and to the future of traffic control. The Task 2 efforts and the MMITSS Developers Group are focused on identification of enhancements needed to advance the deployment readiness of the MMITSS prototypes. This task will address the needs, within the available resources, to ensure that MMITSS can be utilized in real--world implementations.

An iterative and incremental approach to development and testing will be used throughout the project. For example, as the enhancements are made to the code, such as implementing the J2735 2016 messages and the development of a RSU API for the message transceiver will be tested as one build. Then, other improvements and refactoring of the code will be tested.

Finally, the traffic control enhancements, such as coordination, will be developed and tested. Using an iterative and incremental approach will help ensure a stable and operating system during the project. The detailed schedule of the build/test cycles will depend on several factors, including the input received from the MDG about improvements and enhancements. Some testing, such as the enhanced traffic control features will likely be tested early in the development process due to the improvements being developed prior to the start of the project.

Task 3.1 Update to the SAE J2735 2016 Standard

26

The Phase II effort utilized the SAE J2735 2009 standard and the MMITSS team participated in making improvements to the standard to support the MMITSS operation. There are significant changes to the 2016 version of the standard including a new message frame for every message, a new MAP message specification, a new Signal Status Message (SSM) that is based on the MMITSS Phase II priority use case, and the use of UPER encoding of the message payload. The MAP message is used in several MMITSS components to determine if a vehicle is in the roadway or off the roadway, such as in an adjacent parking lot. Hence, changing the MAP representation and functions in MMITSS is a significant change. Updating to the 2016 version of the standard is necessary for deployment readiness and can be accomplished in two ways:

1) Since the revised standard utilizes some new message formats and UPER encoding, open source ASN.1 compilers and libraries are not currently available. A commercial ASN.1 compiler, such as the Objective Systems ASN1C compiler, could be used. This compiler can be purchased for approximately $1700 for an academic license that requires the code to be recompiled every 30 days (which isn’t deployment ready, but would provide a path to deployment for adopters).

2) Utilize the FHWA developed open source ASN.1 compiler and library that is expected to be available in the Fall 2017. This option would leverage the FHWA open source effort.

Each of these options will be evaluated in the Task 2.6 efforts in consultation with the MMITSS Developers Group, Pooled Fund Study Members and USDOT Coordinator. This task will support both MMITSS--AZ and MMITSS--CA and will be coordinated between the Arizona and PATH team members.

Task 3.2 Develop an API Specification for an RSU Deployed Message Transceiver

In the Phase II effort, the MMITSS prototypes utilized Savari specific DSRC WAVE stack functions to transmit and receive BER encoded messages. To support the goal of a hardware agnostic solution, an API specification will be developed, based on the DSRC Roadside Unit (RSU) Specifications Document v4.12 message format and requirements, which will support use of RSUs from multiple vendors that conform to the 4.1 specification. This task will support both MMITSS--AZ and MMITSS--CA and will be coordinated between the Arizona and PATH team members. Task 3.3 Enhancements to the AZ Prototype

This section discusses enhancements to the MMITSS--AZ prototype to ensure the prototype is ready for deployment. These enhancements will be tested in the Task 4 Field Readiness Test. It is assumed that the Task 2 effort will identify, prioritize, and estimate the required level of effort of additional enhancements identified by the MDG and Pooled Fund Panel. The discussion below is the MMITSS team’s suggestions for enhancements. [Note: All category 2 and 3 improvements will be approved by the CV PFS before development starts.] The enhancements to the MMITSS--AZ prototype are grouped into three categories: Category 1-improvements to the MMITSS code and documentation, Category 2 -- MMITSS prototype system enhancements to support the 90--day field readiness testing (Task 4) and Category 3 - traffic control enhancements that operational agencies will require/desire for deployment. Task 3.3.1 Improvements to the MMITSS--AZ Code and Documentation (Category 1)

This task will focus on improving the MMITSS--AZ source code, software build manual, installation manual, and software design documentation. As described in Task 2.6, monthly webinars will be held with the MDG to conduct reviews of the source code, including modifications made under this project. Each review will focus 2 FHWA, DSRC Roadside Unit (RSU) Specifications Document v4.1, DTFH61--12--D--00020, October 31, 2016.

27

on one of the software components, including the detailed design documentation (revised). The MMITSS--AZ installation manual will be updated and one agency will be asked to review and attempt to set up an intersection in MMITSS. The source code and documentation will be maintained and updated in the OSADP repository. Task 3.3.2 Update to the System Performance Measures (Category 2)

The system performance measures will be updated to collect data to support the Task 4.2 – 90 Day Readiness Testing, including collection of system uptime (i.e. System Availability), number of messages (vehicles) processed, and other system performance data identified to support evaluation of the system performance over the 90--day readiness test. Task 3.3.3 Add Support for RDE Data Capture (Category 2)

The Research Data Exchange (RDE) is operated by FHWA to provide data sets for researchers to access for the purpose of supporting research, analysis, application development and support. Adding features to support data collection for reporting to the RDE will require that the desired data format be defined and the current logging functions modified to produce data logs in the defined format. The level of effort required for this development will depend on the required format, but some initial effort has been estimated for the purpose of budgeting. The MMITSS team will provide data logging/streaming that can be captured and uploaded to the RDE. Task 3.3.4 Enhance Traffic Control Features to Support Deployment Readiness (Category 3)

Category 3 enhancements include features needed to support additional use cases such as integration between coordination and priority, section level priority, and the N--level priority policy, as well as new functionality identified in Task 2. Since the March 2015 MMITSS--AZ Field Test, progress has been made on several of these items under support from other projects. For example, Mehdi Zamanipour has been working on the integration of coordination and priority while serving as an FHWA Intern and NAS Fellow at the Turner--Fairbank Transportation Research Laboratory. His work is currently being tested using simulation and limited field testing. His work needs to be integrated into the MMITSS AZ code base, tested, and installed in the Arizona Test Bed for field testing and evaluation. The Utah Department of Transportation (UDOT) is supporting the addition of peer--to--peer communication of priority request to extend the headway (range) of request to allow the priority control algorithms to have additional time to plan better accommodation of priority requests. This enhancement will support section level priority (route priority) for emergency vehicles, transit and trucks. Both of these enhancements will be included in the Arizona MMITSS code base and updated to the OSADP once they have been developed, simulation tested, and field tested before the completion of this MMITSS Phase III task. This effort is assumed to be included in this project for no additional development cost, but will be included in the field testing Task 4.1. Additional traffic control enhancements may be identified by the MMITSS Developers Group in the Task 2 effort. The cost and impact on the overall project budget will be reviewed with the Pooled Fund Panel when they are identified and cost estimates prepared. Task 3.4 Enhancements to the CA Prototype

The enhancements to the MMITSS--CA prototype are grouped into four categories: 1) improvements to the MMITSS code and documentation, 2) MMITSS prototype system enhancements to support the 90--day field readiness testing (Task 4), 3) add traffic controller interface for deploying MMITSS--CA with NTCIP controllers, and 4) traffic control enhancements that operational agencies will require/desire for deployment. [Note: All category 2, 3 and 4 improvements will be approved by the CV PFS before development starts.] Task 3.4.1 Improvements to the MMITSS--CA Code and Documentation (Category 1)

This task will focus on improving the MMITSS--CA source code, software build manual and automated make scripts, installation manual, and software design documentation. The MMITSS Team will participate in the

28

webinars with the MDG to conduct reviews of the source code, update build manual/scripts and installation manual. The source code and documentation will be maintained and updated in the OSADP repository. Task 3.4.2 Add Support for 90--Days Field Readiness Testing (Category 2)

The system performance measures will be updated to collect data to support the Task 4.2 – 90 Day Readiness Testing including collection of system uptime (e.g. Availability), number of messages (vehicles) processed, and other system performance data identified to support evaluation of the system performance over the 90--day readiness test. The data capture features will be added to support data collection for reporting to the RDE. The MMITSS Team will provide data logging/streaming that can be captured and uploaded to the RDE. Task 3.4.3 Add Traffic Controller Interface for Deploying MMITSS--CA with NTCIP Controllers (Category 3)

In MMITSS--CA, the decisions for priority control (desired green split for priority cycles, when and how to place priority call to the traffic controller, etc.) and for coordination control (desired cycle length, splits, and/or offsets, etc.) are made in the MRP based on data from connected vehicles. The control commands are sent to the Caltrans 2070 controller using AB3418 serial communications protocol. The MRP receives signal status raw data from the 2070 controller via AB3418 protocol and encodes SPaT messages. This task focuses on adding an interface to NTCIP controllers using NTCIP objects for ASC to support deploying MMITSS--CA over NTCIP controllers. The existing NTCIP objects for sending control parameters such as cycle length, splits, offsets, force--off points, will be added in parallel to AB3418 messages over Caltrans 2070 controllers. Task 3.4.4 Traffic Control Enhancements to Support Deployment Readiness (Category 4)

Enhancements include adding traffic control features to support section level priority control, N-level priority, and integration with coordination control. In the current (Phase II) MMITSS--CA, TSP is implemented by using the 2070 controller’s built--in priority control logic. The MRP (MMITSS Roadside Processor) receives Signal Request Messages (SRMs) and Basic Safety Messages (BSMs) from transit vehicles, prioritizes the requests for priority, selects the priority request to serve, and sends the request to the 2070 controller to grant the priority. Caltrans division of traffic operations is modifying the 2070 control software to allow dynamically change force--off points for priority control. The modification shall be in place for MMITSS Phase III, which allows more intelligent priority and traffic control, i.e., determination of phase splits based on connected vehicle data and system detector data in real time. Task 3.4.4.1 Section Level Priority Control

In MMITSS Phase II, signal priority control is managed at the intersection level, without the consideration of coordinating the signal priority control along a section of signals. A vehicle that obtained priority at an upstream intersection may have to stop at a downstream intersection, resulting in possible interruption of signal progression and no net travel time saving for the vehicle. The section--level priority control coordinates the priority strategies among a section of signals based on projected movements of requested vehicles, signal status and estimated queue length of each intersection, thereby gaining net travel time savings for priority eligible vehicles and reducing side impact on general traffic. Santa Clara Valley Transportation Authority (VTA) operates both the BRT line and local bus lines along the California test network, which provide the environments for testing N--Level Priority Policy, and evaluate priority benefits on BRT buses vs. local buses. Task 3.4.4.2 Integration with Coordination Control

Improved traffic coordination or progression also benefits the priority eligible vehicles when they are travelling with major platoons. Signals in the California test network are operated under the actuated--coordinated control mode with three time--of--day timing plans. Signal coordination parameters, including cycle length, phase sequence, split and offset, are programed based on historical field survey data and/or field observations, and does not reflect the dynamic and changing of traffic flow and speed. During peak hours, queue spillback often occurs at closely spaced intersections. With the enhanced queue length estimation,

29

detection of vehicle trajectories (e.g., VTA buses and other connected vehicles), and count and occupancy data from system detectors, the coordination timing plan parameters will be dynamically adjusted to adapt to the prevailing traffic conditions and requests for priority.



Draft Deployment Readiness Development Plan and Briefing 8 weeks

Final Deployment Readiness Development Plan 10 weeks

Draft Task 3 Report 35 weeks

Final Task 3 Report 40 weeks

Public Briefing/Presentation Materials 45 weeks

Public Briefing 45 weeks

Code to the OSADP 50 weeks

Updated MMITSS Systems Engineering Documents 50 weeks

Draft Deployment Readiness Development Plan and Briefing 8 weeks

Task 4 – Field Test and Demonstration

Task 4.1: Testing of the Enhancements from Task 3.

The enhancements identified in Task 3 will need to be field tested prior to the start of the 90--day Readiness Test (Task 4.2). A test plan will be defined and executed for the enhancements developed in Task 3. Any issues or problems will be corrected and retested, if needed. As mentioned in the Task 3 descriptions, an iterative and incremental approach to development and testing will be used to ensure a stable and operating system is maintained throughout the project.

Task 4.1.1 MMITSS Testing of the SAE J2735 2016 Messages (BSM, SPaT, MAP, SRM, SSM) including the RSU Message Transceiver

Upgrading to the 2016 version of the SAE J2735 standard is a significant change since these messages impact most of the software components. Hence, both laboratory and field testing are critical to the success of the project.

Task 4.1.2 Testing of the Improved and Refactored Code

As the MMITSS code is improved and refactored, iterative testing will ensure that the system continues to function as designed and desired. In support of field testing, laboratory testing will be conducted using the MMITSS Software--in--the--Loop simulation platform developed by the University of Arizona, and by using unit test components for each of the MMITSS components. The testing intersection at PATH Richmond Field Station, which has the same configuration as Palo Alto California testbed, will be used for unit testing of the MMITSS--CA components, and improved and refactored code.

30

Task 4.1.3 Testing the Updates to the System Performance Measures

The additional performance measures are required to support the 90--day readiness testing as well as supporting future deployments. Ensuring that the additional performance measures provide the desired characterization of system performance is essential to assessing the success of this project.

Task 4.1.4 Testing Support for RDE Data Capture and Upload

The Research Data Exchanged (RDE) is operated by FHWA to provide data sets for researchers to access for supporting research, analysis, application development and support. The MMITSS field tests, as well as the simulation tests, will provide valuable contributions to the RDE. The enhancements required include providing documentation of data, metadata, and data collected in a format that is useful to other researchers. Testing of this data capability will include collection of data, review for accuracy and completeness, and will include submission to the RDE. This capability will be used during the 90--day readiness test (Tasks 4.2).

Task 4.1.5 Testing of the Enhanced Traffic Control Features to Support Deployment Readiness (including Coordination and Peer--to--Peer/Route Priority)

The traffic control enhancements, including coordination and peer--to--peer communication to the MMITSS –AZ system, have been identified as critical enhancements that are required to make the prototypes deployable. Testing of these enhancements will ensure that these features operate as designed and required for deployment readiness. The testing will include laboratory and field testing.

Task 4.2: Readiness Testing – 90 day in Arizona and Palo Alto, CA.

A 90--day Readiness Test will be conducted in each of the test beds. Task 4.2.1 addresses the general plan for testing in the Arizona Test Bed and Task 4.2.2 addresses the general plan for testing in the California Test Bed. [The test plans for each network will be approved by the CV PFS/USDOT prior to the start of the 90-day field test]. Task 4.2.1: Arizona Test Plan

The goal of the field testing task is to assess the enhanced MMITSS--AZ prototype for deployment readiness in support of the ongoing and planned MMITSS deployments, including USDOT--led Connected Vehicle Pilot Deployments; MMITSS deployments in other states such as Utah; states planning to deploy MMITSS in near future; and expansion plans in AZ and CA. The test (or suite of tests) will be performed over a 90--day period when the MMITSS-AZ system will be operated continuously. System data that characterizes system operational performance, as well as traffic control measures, will be collected and reported using the FHWA RDE. As identified in the MMITSS Phase II Final Report (Section 8.1), one of the most significant needs and challenges is the quantitative market penetration of connected vehicles required to test, evaluate, and demonstrate the MMITSS ISIG component, as well as the integration of traffic data into the MMITSS Priority (EVP, TSP, and FSP) component. To address this need, the Maricopa Department of Transportation is working to equip 10 private vehicles, 20 Deer Valley School District buses, and 5 Deer Valley Fire vehicles. The 10 private vehicles are provided by volunteers, such as MCDOT Director Jennifer Toth and other MCDOT employees and public volunteers who live in Anthem, AZ, and are willing to have aftermarket safety devices installed on their vehicles. The 20 Deer Valley school buses represent a subset of the fleet serving the Rock Creek High School where there are challenges getting the platoon of buses into and out of the school twice a day. We recognize that this isn’t the desired level of market penetration to fully evaluate the MMITSS ISIG component, but it will provide useful data for the components to operate the system during the 90--day evaluation. We continue to work with local partners and are seeking opportunities to increase the market penetration (note: The Arizona CV Pilot Deployment proposal included equipping 2,000 vehicles, which would represent 20% market penetration of the resident

31

vehicles in Anthem. Given the closed topology of the Anthem network, these vehicles would have to traverse the MMITSS equipped intersections. The Anthem Community Association provided a letter of support to participate in vehicle equipment opportunities and continues to support the project effort in the test bed). Depending on the availability of funding, additional vehicles will be equipped with OBUs permitting their participation during the field testing period. A test plan will be prepared to include component and system level testing. The deployment readiness assessment will be evaluated by system performance measures including:

• System Availability (up time) and • System Service Time (time to return the system to operational status).

A system log will be maintained that includes annotations about operational experience such as issues (e.g. Failure of RSU, OBU, Traffic Signal Controllers, etc.), citizen reports/complaints, comments on success (e.g. for the school bus challenge, hopefully), and other observations of events to capture the operational experience of the system. In addition, traffic performance measures will be captured and evaluated. These measures include:

• The number, and type, of priority requests sent and received, • The number of equipped vehicles observed, and • Traffic performance in terms of travel time, delay, and stops.

A Field Test and Evaluation Report will be developed that summarizes the outcomes and assessment of the 90--day field testing. Key lessons--learned will be captured and documented, including the perspectives of the MCDOT Traffic Engineer, private residents who have their vehicles equipped, the Deer Valley School district, MCDOT REACT responders and Fire Department. Task 4.2.2 Test and Evaluation of MMITSS in California

The goal of this field testing task is to support the enhancement of MMITSS in order to facilitate a good understanding of the effectiveness of MMITSS--CA in an urban traffic environment and the assessment of MMITSS--CA as a deployable system. This task is a necessary step for making MMITSS ready for deployment.

A 90--day Readiness Test will be conducted in the California test bed to collect comprehensive data and support analyses that characterize system operational performance, as well as traffic control measures using the FHWA RDE. While the California test site will be ready to perform a suite of tests over a 90--day period under the Phase III MMITSS project, it will be continuously operated thereafter for data collection, data analysis, and tests of other Connected Vehicle applications.

Task 4.2.2.1 Enhancement of Test Environment

The previous phase of MMITSS concentrated on proof of concept testing of the signal priority algorithms. The focus of research in MMITSS Phase III has now shifted towards the development and testing of true intelligent traffic control strategies. Enhanced testing environments and sound experimental approaches need to be developed to support not only priority triggering (which was achieved in Phase II), but also to enable CV--based traffic detections at different level of penetrations, with various traffic volumes, at any time--of--day and day--of--week. This approach is essential to support a full performance evaluation of MMITSS strategies under more realistic application scenarios. In order to facilitate the development of a MMITSS traffic control algorithm and conduct a full evaluation of the designed MMITSS functions, the California team proposes to instrument three (3) intersections with infrastructure--based sensors to detect all vehicles that approach the instrumented intersection within a predetermined range while continuously tracking every vehicle with lane level accuracy (both equipped and unequipped). We then use the tracking data to randomly assign and emulate equipped vehicles at different levels of penetration as inputs to MMITSS for enabling intelligent traffic control strategies. We will also use this data to generate a full set of performance measures for assessing the

32

effectiveness of MMITSS. This approach is appropriate for urban corridors such as the California CV test bed, where traffic volumes are high and it is not possible to equip enough vehicles to support effective testing of MMITSS.

The CA team has explored the use of alternative sensing technologies, including radars and video based sensors that can track vehicles (moving as well as stopped) in real time. We have selected radars developed by Smart Microwave Sensors (SMS radar) as the infrastructure sensors for this project. SMS radars are well proven technologies and have been sold around the world and in the United States for enhanced traffic detection functions.

Their current radars can cover 6 lanes and track 128 targets simultaneously in real-- time, with a less than 80ms update rate and a maximum detection range of between 200 to 300 meters, depending on the installation height. PATH has used SMS radars for more than ten years, and have installed the radars at the test intersection at the Richmond Field Station, as well as at two Caltrans operated intersections. The SMS radar provided quality data to support various research projects, including the CICAS project funded by USDOT, where data collected from SMS radars was used to track every vehicle approaching an intersection for a thorough analysis of red light running behaviors (see Appendix A for SMS data example collected at an intersection in Albany, CA). PATH developed the algorithms necessary for processing the data from SMS radars; therefore, there is little new development except for installation and fine turning. The instrumentation of a segment of three consecutive intersections is necessary for robustly observing traffic flows along the corridor, the impact on the cross streets, as well as progression on the main streets. While the radars will be procured under the MMITSS Phase III project, the installation will be cost- shared by Caltrans in early summer 2017 under the Caltrans- funded California Connected Vehicle test bed upgrade project (there would be no installation costs to this project).

The California team also proposes to instrument VTA Line 22/ Rapid Bus 522 transit buses with on--board units. VTA Line 22 buses run every 10 minutes during weekdays, primarily along El Camino Real (SR 82) corridor. The Line serves the cities of San Jose, Santa Clara, Sunnyvale, Mountain View, Los Altos, Palo Alto, and Menlo Park. It is the VTA’s most heavily used Line, carrying over 23,000 riders daily and representing 16% of VTA’s total bus ridership. The Line operates near capacity with many buses experience standing room only. Rapid Bus 522 is a limited stop BRT service operating on the Line 22 route. Signal priority is essential for achieving the designed operating efficiency for both of these routes.

VTA desires to use Connected Vehicle technology to achieve higher efficiency TSP with minimum impact to automobile traffic. The combination of the test bed preparation and vehicle instrumentation will enable the project team to evaluate all aspects of MMITSS functions in a real--world condition and for a wide range of penetrations, from 0% up to 100%.

Task 4.2.2.2 Field Testing

A test plan will be developed to provide the test objectives, detailed test procedures, collected data, performance measures, and reporting outlines. In specific, the test plan will outline methods to collect and evaluate both baseline data (with MMITSS functions turned off) and operating MMITSS traffic control strategies. As part of the test preparation, connected vehicle based performance metrics identified in the MMITSS Phase I project will be selected for characterizing the system performance. With the infrastructure--based detection system, each performance measure will be implemented using both actual BSMs from vehicles, as well as emulated BSMs based on data from the SMS radars, so that we will be able to compare calculated performance metrics with observations (measurements of actual traffic). As an example, MMITSS performance measures will estimate the queue length based on connected vehicle data at different penetration rates. This estimated queue length will be compared with the observed (through SMS radar data) distance of the last stopped vehicle from the stop bar for each lane, and/or the queue in terms of the number of stopped vehicles at each lane. We will follow the test plan to conduct the field testing, and at the end of the 90--day testing, PATH and Caltrans will conduct a demonstration at the El Camino Real CV test bed and report the project results.

Task 4.2.2.3 Data Archiving and Processing Tools

Data archiving and processing tools will be developed for real--time and post processing the infrastructure data

33

and data collected from the test vehicles in order to derive the performance metrics and the observation data. System performance data, such as availability and reliability of MMITSS, will be also collected.

Task 4.2.2.4 Field Test Evaluation Report

A Field Test Evaluation Report will be developed to document testing results and findings from the 90-day field testing. Key lessons learned will be captured and documented, including the perspectives of the participating stakeholders.



Draft Deployment and Field Test Plan 48 weeks

Final Deployment and Field Test Plan 52 weeks

Field Demonstration 65 weeks

Data and Test Results to the RDE 72 weeks

Draft Task 4 Report 72 weeks

Final Task 4 Report 78 weeks

Task 5 – Technical Assistance to Deploy MMITSS

The MMITSS team recognizes the challenges that agencies face when considering utilizing new technologies, such as connected vehicles and MMITSS. In order to estimate a reasonable level of effort for this task, the MMITSS team will plan to support two SPaT Challenge projects that want to include MMITSS in the deployment corridor. One of the SPaT Challenge projects will want to use the MMITSS--CA system and one the MMITSS--AZ system. Support will include the following activities:

1. Provide an overview of MMITSS, in the context of the SPaT Challenge,

2. Discussion of the MMITSS architecture, including selecting the hardware vendors that the project chooses to install,

3. Support for the configuration of MMITSS for each of the 20 SPaT Challenge intersections including explanation of the configuration data required, MAP data, networking, etc.

4. Support during integration and testing to answer questions and address issues identified, and

5. Support during a 90--day operation period including addressing questions or issues identified.



Select MMITSS Technical Support Recipient (new MMITSS deployment site) 20 weeks

Draft MMITSS Deployment Guidance document 68 weeks

Final MMITSS Deployment Guidance 70 weeks

34

document

MMITSS Results and Guidance meeting/webinar 72 weeks

Draft MMITSS Deployment Lessons Learned report 4 weeks from installation

Final MMITSS Deployment Lessons Learned report 12 weeks from installation