Multi-Modal Intelligent Traffic Signal System · The Multi-Modal Intelligent Traffic Signal System ... communicate information such as passenger ... from the smart phone of registered

Multi-Modal Intelligent Traffic Signal System

Project Management Plan Development of Concept of Operations, System

Requirements, System Design, and Test Plan

University of Arizona (Lead) University of California PATH Program

Savari Networks, Inc. SCSC

Econolite Kapsch

Volvo Technology

Version 2.0

4/30/2012

Pooled Fund Project - PMP

Pooled Fund Project - PMP UA_PFP_PMP

Page 1 of 28

RECORD OF CHANGES

A – Added, M- Modified, D - Deleted

Version Number

Date Identification of Figure, Table, or

Paragraph Title or Brief Description

Change Request Number

1.0

3/29/12

N/A

Initial Draft submitted for review and feedback.

CDRL

2.0

4/30/12

All

(1) Reformatted for ease of reading and referencing. (2) Feedback from Review Panel integrated as requested. (3) Project Plan included as an appendix. (4) Acronym listed expanded and included as an appendix

Draft

Review Process



Page 2 of 28

Table of Contents 1 OVERVIEW ............................................................................................................................................ 4

1.1 Project Summary ........................................................................................................................... 4

1.1.1 Purpose Scope and Objectives ................................................................................................. 6

1.1.2 Assumptions and Constraints ................................................................................................... 6

1.1.3 Project Deliverables .................................................................................................................. 6

1.1.4 Master Schedule ....................................................................................................................... 7

1.2 DOCUMENT STRUCTURE .......................................................................................................... 8

2 REFERENCES ...................................................................................................................................... 9

2.1 STANDARDS AND DOCUMENTS ............................................................................................... 9

2.2 DEVIATIONS AND WAIVERS ...................................................................................................... 9

3 PROJECT ORGANIZATION .................................................................................................................. 9

3.1 EXTERNAL INTERFACES ........................................................................................................... 9

3.2 INTERNAL STRUCTURE ........................................................................................................... 11

4 MANAGEMENT PROCESS ................................................................................................................ 12

4.1 START-UP .................................................................................................................................. 12

4.2 BUDGET AND COST CONTROL ............................................................................................... 12

4.3 QUALITY CONTROL .................................................................................................................. 13

4.4 RISK MANAGEMENT ................................................................................................................. 13

4.5 HUMAN RESOURCE MANAGEMENT ....................................................................................... 16

4.6 SCOPE MANAGEMENT ............................................................................................................. 17

5 SUPPORTING PROCESSES .............................................................................................................. 17

5.1 COMMUNICATIONS MANAGEMENT ........................................................................................ 17

5.2 CONFIGURATION MANAGEMENT ........................................................................................... 18

6 APPENDICES ...................................................................................................................................... 20

APPENDIX A: TASK DESCRIPTIONS ................................................................................................... 20

APPENDIX B: ACRONYMS .................................................................................................................... 23

APPENDIX C: PROJECT PLAN ............................................................................................................. 24



Page 3 of 28

Figure 1 – Master Project Schedule Roll-up ................................................................................................. 8 Figure 2 – External Organization Interfaces ............................................................................................... 10 Figure 3 – Functional Management Organization ....................................................................................... 12 Figure 4 – Risk Management Process ........................................................................................................ 14

Table 1 – List of Deliverables and Due Dates............................................................................................... 6 Table 2 – Programmatic Roles and Responsibilities .................................................................................. 11 Table 3 – Risk Tracking Matrix.................................................................................................................... 15 Table 4 – Project Roles and Responsibilities.............................................................................................. 16 Table 5 – Communication Activities ............................................................................................................ 18 Table 6 – CM File Naming Conventions ..................................................................................................... 19



Page 4 of 28

1 OVERVIEW This Project Management Plan (PMP) is intended to provide guidance on the management of the

Cooperative Transportation System Pooled Fund Study (CTS PFS): Multi-Modal Intelligent Traffic Signal

System (MMITSS) project. Originally, the plan utilized the template 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 (ETA) 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. Incorporating feedback from the PMP Draft review, 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 project, Program Manager, and PFS Review Panel.

Updates to this document are performed in accordance with the MMITSS Configuration Management

Process.

1.1 Project Summary The MMITSS project is part of the Cooperative Transportation System Pooled Fund Study (CTS PFS)

entitled “Program to Support the Development and Deployment of Cooperative Transportation System

Applications.” The CTS 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’s Center for Transportation Studies is supporting VDOT on

the Pooled Fund Study, serving as the technical and administrative lead for the effort. The focus of the

CTS PFS is on prototyping and testing practical infrastructure oriented applications that lead to

deployment rather than developing theoretical applications. More information about the CTS PFS and the

scope of the project can be found at http://cts.virginia.edu/CTSPFS_1.html.

The United States Department of Transportation (US DOT) has recently identified ten high-priority

mobility applications under the Dynamic Mobility Applications (DMA) program for the connected vehicle

environment where high-fidelity data from vehicles, infrastructure, pedestrians, etc. can be shared

through wireless communications (Further information is available at

http://www.its.dot.gov/dma/index.htm). Among the ten identified high-priority applications, three

applications (Intelligent Traffic Signal System, Transit Signal Priority, and Mobile Accessible Pedestrian

Signal System) are related to transformative traffic signal operations. Since a major focus of the CTS

PFS members – who are the actual owners and operators of transportation infrastructure – lies in traffic

signal related applications, the CTS PFS team is leading the project described in this RFP, entitled “Multi-

Modal Intelligent Traffic Signal System” in cooperation with US DOT’s Dynamic Mobility Applications

Program.

Multi-Modal Intelligent Traffic Signal System

This project aims to conduct the foundational analysis and design necessary to prepare for the

development and field testing or demonstration of a Multi-Modal Intelligent Traffic Signal System, which is



Page 5 of 28

defined as a comprehensive traffic signal system taking advantage of the connected vehicle environment

for multiple transportation modes, including general passenger vehicles, transit, emergency vehicles,

freight vehicles, and pedestrians. The Multi-Modal Intelligent Traffic Signal System incorporates, at a

minimum, the arterial traffic signal applications identified through the DMA template process of US DOT.

Brief descriptions of these applications, modified from the DMA applications description document, are

provided below:

1. Intelligent Traffic Signal System (ISIG):

This application will make use of high-fidelity data collected from vehicles through wireless

communications to accurately predict lane-specific platoon flow, platoon size, and other driving

characteristics. The proposed application with high-fidelity data, in real-time has the potential to

transform how traffic signal systems are designed, implemented and monitored. Developing new systems

that use data via V2V and V2I wireless communications to control signals in order to maximize flows in

real-time can significantly improve traffic conditions. The ISIG application also plays the role of an over-

arching system optimization application, accommodating transit or freight signal priority, preemption, and

pedestrian movements to maximize overall arterial network performance. In addition, the interface (or

data flow) between arterial signals and ramp meters (essentially traffic signals installed on freeway

onramps) must also be considered (note, however, that the development of ramp metering algorithms —

the metering rates to optimize freeway flow — is not included in the scope of this application).

2. Transit Signal Priority (TSP):

Transit Signal Priority strategy is suggested to allow transit agencies to manage bus service better by

adding the capability to grant buses priority based on a number of different factors. The proposed

application provides a mechanism by which transit vehicles equipped with on-board equipment can

communicate information such as passenger count data, service type, scheduled and actual arrival time

and heading information to roadside equipment via DSRC.

3. Mobile Accessible Pedestrian Signal System (PED-SIG):

This application will integrate information from roadside or intersection sensors and new forms of data

from wirelessly connected pedestrian-carried mobile devices, and then wirelessly communicate with the

traffic signal controller to obtain real-time Signal Phase and Timing (SPaT) information, which will then be

used to inform the visually impaired pedestrian as to when to cross and how to remain aligned with the

crosswalk. The application will allow an “automated pedestrian call” to be sent to the traffic controller

from the smart phone of registered blind users after confirming the direction and orientation of the

roadway that the pedestrian is intending to cross. To the extent that these new data are useful, this

application may also support the accommodation of safe and efficient pedestrian movement of a more

general nature.

4. Emergency Vehicle Preemption (PREEMPT):

The proposed application will be functionally similar to current signal preemption systems but may be

viewed as a replacement of optical, 900 MHz, and other technologies used for signal preemption with

integrated V2V and V2I communication systems. The application would adjust preemption and signal

recovery cycles to account for non-linear effects of multiple emergency responses through the same

traffic network.

5. Freight Signal Priority (FSP):



Page 6 of 28

Freight Signal Priority concept provides signal priority along an arterial corridor near a freight facility

based upon current and projected freight movements into and out of the freight facility. The goal of freight

signal priority application is to reduce delays and increase travel time reliability for freight traffic, and

enhance safety at intersections around the freight facility.

1.1.1 Purpose Scope and Objectives The final goal of the CTS PFS team is to field-test or demonstrate a Multi-Modal Intelligent Traffic Signal

System. This project, constructed as a first step, will develop a concept of operations (ConOps) and

system requirements specification (SyRS) in general and include a conceptual system design and a test

plan for the selected locations.

The objectives of this project are:

• To develop a concept of operations, systems requirements specification, and system design for a

comprehensive traffic signal system that services multiple modes of transportation, including

general vehicles, transit, emergency vehicles, freight fleets and pedestrians; and

• To prepare for field testing or demonstration of the developed Multi-Modal Intelligent Traffic

Signal System.

1.1.2 Assumptions and Constraints This project is being conducted under a larger umbrella Pooled Fund program titled “Program to Support

the Development and Deployment of Cooperative Transportation Systems Applications”. As such, the

system under consideration will operate within the cooperative “Connected Vehicle System” where

vehicles communicate to an equipped infrastructure. The communications will include, but are not limited

to 5.9 GHz DSRC and will use messages consistent with the SAE J2735 standards being developed as

well as US DOT efforts for SPaT and MAP messages and NTCIP standards for traffic management and

control.

1.1.3 Project Deliverables The deliverables created in this project will support the full development of a deployable Multi-Modal

Intelligent Traffic Signal System. The deliverables are summarized in Table 1 below. All deliverables in

this project are documents (reports) and will be submitted in PDF format by email to the Project Manager.

Table 1 – List of Deliverables and Due Dates

TASK NAME AND

DELIVERABLE

DUE DATE Calendar Date

(Assuming a March 1,

2012 Start Date)

Task 1 – Project Management and Systems Engineering Management

Briefing Materials, Kick-Off Meeting Two weeks from Contract Award March 15, 2012

Draft PMP, Final PMP Four weeks from Contract Award March 29, 2012

Draft Project Schedule, Final Project Schedule Four weeks from Contract Award March 29, 2012

Quarterly Update Conference Calls and Minutes Every quarter from Contract Award June 1, September 1,

December 1

Monthly Progress Reports Every month from Contract Award 1st Day of Month

Team Meetings Summaries Within 1 week after each meeting -

Briefing Materials, Closeout Meeting 52 weeks from Contract Award February 28, 2013



Page 7 of 28

Task 2 – Develop Concept of Operations (ConOps)

Subtask 2.1 – Assessment of Relevant Prior and Ongoing Research

Outline of Draft Report on Assessment of

Relevant Research

Four weeks from Contract Award March 29, 2012

Draft Report on Assessment of Relevant

Research

Six weeks from Contract Award April 12, 2012

Briefing on Assessment of Relevant Research Six weeks from Contract Award April 12, 2012

Final Report on Assessment of Relevant

Research

Eight weeks from Contract Award April 26, 2012

Subtask 2.2 – Solicit Stakeholder Input

Presentation Materials for Stakeholder Meetings Eight weeks from Contract Award April 26, 2012

Technical Memorandum from Each Meeting 10 weeks from Contract Award May 10, 2012

Draft Report on Stakeholder Input 12 weeks from Contract Award May 24, 2012

Final Report on Stakeholder Input 14 weeks from Contract Award June 7, 2012

Subtask 2.3 – Develop Concept of Operations (ConOps)

Draft Concept of Operations (ConOps) 16 weeks from Contract Award June 21, 2012

Revised Concept of Operations (ConOps) 18 weeks from Contract Award July 5, 2012

Walkthrough Workbooks for Walkthrough Review 19 weeks from Contract Award July 12, 2012

Walkthrough Comment Resolution Report 22 weeks from Contract Award August 2, 2012

Final Concept of Operations (ConOps) 24 weeks from Contract Award August 16, 2012

Task 3 – Develop System Requirements

Draft System Requirements 28 weeks from Contract Award September 13, 2012

Revised System Requirements 32 weeks from Contract Award October 11, 2012

Walkthrough Workbooks for Walkthrough Review 34 weeks from Contract Award October 25, 2012

Walkthrough Comment Resolution Report 38 weeks from Contract Award November 22, 2012

Final System Requirements 40 weeks from Contract Award December 6, 2012

Task 4 – Conduct System Design

Draft System Design 44 weeks from Contract Award January 3, 2013

Final System Design 46 weeks from Contract Award January 17, 2013

Task 5 – Prepare a Deployment and Field

Test Plan

Draft Deployment and Field Test Plan 50 weeks from Contract Award February 14, 2013

Final Deployment and Field Test Plan 52 weeks from Contract Award February 28, 2013

1.1.4 Master Schedule The Master Project Schedule is shown in Figure 1 below. The schedule will be updated monthly to track

task progress, for cost estimation monitoring, and to reflect and changes in start/end dates. An expanded

version of the Master Project Schedule can be found in Appendix C.



Page 8 of 28

Figure 1 – Master Project Schedule Roll-up

1.2 DOCUMENT STRUCTURE The Project Management Plan is organized into the following sections and appendices:

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.

Section 2, References. This section provides a list of all documents, policies, templates,

processes, and other sources of information referenced in the plan.

Section 3, 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.

Section 4, Project Management Process. This section describes the management, technical, and

supporting processes.

Section 5, Supporting Processes. This section describes the processes used to support the

project including configuration management.

Appendices: Task Descriptions, Acronyms, and Project Plan



Page 9 of 28

2 REFERENCES

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

A Description of the SSC San Diego Standard Process Assets (SPA), PR-OPD-35, SSC San

Diego

Institute of Electrical and Electronics Engineers (IEEE) Standard for Software Project

Management Plans, IEEE Standard 1058-1998, IEEE, December 1998

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.

3 PROJECT ORGANIZATION The project organization is divided into two primary categories: External Interfaces and Internal Structure.

The following sections define these categories, define roles, and identify personnel assigned to the roles.

3.1 EXTERNAL INTERFACES External organizational interfaces and the chain-of-command for the MMITSS Project are defined by the relationships show in Figure 2. The responsibilities of the organizational entities and key positions shown in Figure 2 and are defined in Table 2.


Pooled Fund Project - PMP UA_PFP_PMP Page 10 of 28

Figure 2 – External Organization Interfaces

POSITION ROLES/RESPONSIBILITIES

CTS PFS PI

(Brian Smith) Principal Investigator for the Cooperative Transportation

System Fool Fund Study, which is the overall project

tasked to develop infrastructure based connected

vehicle applications

CTS PFS Project Manager

(Hyungjun Park) Responsible for Project Management and

Oversight



CTS PFS Project Panel

Greg Larson -CalTrans

Faisal Saleem - Maricopa County Arizona)

Ben McKeever (FHWA)

Danielle Deneau (Oakland County Michigan)

Melissa Lance (VDOT)

Hyungjun Park (UVA – Center for Transportation Studies)

Ray Derr (TRB/NCHRP)

Provides direction, review, and input to the Project

Manager and Project Team

Other PFS Members

(TBD)

Other PFS members may be asked to review

documentation and findings.

Project Team – PI

(Larry Head)

Responsible for the management and technical leadership

of the project.

Project Team

(See: Figure 3) 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.

Table 2 – Programmatic Roles and Responsibilities

3.2 INTERNAL STRUCTURE The Project Team is led by the PI (Dr. Larry Head). Dr. Head will be responsible for leading and directing

all management and technical aspects of this project. He will be assisted in the management of the

budget, cost controls, and human resource management by Joanne Canalli (Senior Business Manager,

Systems and Industrial Engineering Department, College of Engineering, University of Arizona). He will

be assisted in technical management by Ann Wilkey. Ms. Wilkey will provide internal audits for scope,

quality, communications, and risk management.

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.

Steve Shladover. The functional management organization of the project is shown in Figure 3.



Research Team PI(Larry Head)

Scope Management

(L. Head)

Cost Management(L. Head)

Quality Management

(L. Head)

Human Resource Management

(L. Head)

Communications Management

(L. Head)

Risk Management(L. Head)

Internal Communications

Audit(Wilkey)

Internal Risk Mgmt. Audit

(Wilkey)

Internal HR Mgmt Audit

(Wilkey)

Internal Quality Audit

(Wilkey)

Internal Cost Audit(Wilkey)

Internal Scope Mgmt. Audit

(Wilkey)

ExternalScope Mgmt. Audit

(Park)

ExternalCost Audit

(Park)

ExternalQuality Audit

(Park)

ExternalHR Mgmt. Audit

(Park)

External Communications

Audit(Park)

ExternalRisk Mgmt. Audit

(Park)

Figure 3 – Functional Management Organization

4 MANAGEMENT PROCESS

4.1 START-UP This project does not require any special training, staffing, or resource allocation in order to begin the

project. The project will start with a Kick-Off meeting. The primary goals of the Kick-off meeting will

include: (1) introduction of the PFS Team, (2) introduction of PFP MMTISS Team, (3) Overview of the

Pooled Fund Study Objective, (4) Project Objectives, (5) Overview of Draft Project Management Plan,

and (6) Question and comment segment.

4.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 Pooled Fund Project (PFP) will use an updated version of the PFP

Project Plan (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 PFP 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.



4.3 QUALITY CONTROL The PFP quality management approach is defined to ensure that the project objectives are attained in a

timely and useful manner: (1) Concept of Operations, CONOPS, (2) System Requirements, (3) System

Design, and (4) System Test Plan.

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 PFP quality management approach defines a

quarterly assessment, auditing, and reporting process to ensure that progress on the four 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 weekly on Tuesdays from 4:30-

5:30PM PST. Until a WebEx connection is defined, a dial-in service has been defined: Call in Number

916-209-4534 Pin: 6389144. Materials reviewed in the weekly teleconferences will be made available

through the PFP CM system (SVN) repository prior to the meeting. In addition, draft meeting minutes will

be posted in the repository within three days and quality reviewed and approved meeting minutes will be

posted within seven days.

Briefings – Quarterly briefings will be offered to the PFP sponsor and/or PFS Panel. In addition to

technical and design information for the PFP project objectives, these briefings will include updates on the

quarterly audits defined throughout the PMP. Materials reviewed in the briefings will be made available

through the PFP SVN repository and email attachment for those participants without access to the PFP

SVN repository.

Communications – As appropriate and needed, the PFP PI will offer communications via telephone,

email, and physical mail. The PFP SVN repository will serve as the primary source of technical

information, since CM processes have been defined to ensure the timeliness and integrity of the content.

Meeting minutes for PFP project teleconferences and meetings will be available through the PFP SVN

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 PFP SVN repository ensure that all internal and external PFP

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.

4.4 RISK MANAGEMENT The strategy to manage project risk is to continually monitor and track potential project risk. The general

approach to risk management is shown in . Table 3 is the risk tracking matrix that will be used to identify,

quantify, manage, and monitor project and task risks. After identification of a risk, the risk is managed by

a defined process detailed in the following steps. The risk is assigned an identifier (ID) and a Risk

Owner. The task is entered into the Risk Tracking Matrix and summarized using the Risk Statement. The

potential impact to the project (Impact Statement) will be provided to allow reviewers to understand the

risk. If the risk is associated directly with a project task, a reference to the WBS shall be included. The



Likelihood and Severity will be estimated (High (1.0-0.7; Red), Medium (0.69-0.20; Yellow), or Low (0.19-

0.01; Green)) and a Risk Score = Likelihood * Severity will be used to quantify the risk assessment.

Risks can be identified by any member of the project team, the UVA project management team, and the

PFP panel members. Risks shall be reviewed in the weekly project teleconferences and included in the

monthly progress reports. Any risk that as a high Risk Score (greater than 0.7) shall be reported to the

CTS PFP PM immediately. Risks shall be tracked and managed until the management team is satisfied

that risk has been mitigated adequately. Once a risk has been addressed, it shall remain in the risk

tracking matrix throughout the duration of the project, but it will be labeled “Closed” in the Risk Score

column (Blue).

Figure 4 – Risk Management Process

1. PlanningEstablishment of the risk

management program plan and

assignment of responsibilities

2. Risk IdentificationAnticipation, recognition &

prioritization of potential

adverse outcomes and the

associated root causes

3. Risk AssessmentCharacterization of the

Magnitude and likelihood of

risks, to the depth warranted

4. Risk AnalysisEvaluation of costs and benefits

associated with available risk

mitigation options, if needed

5. Risk HandlingProgram intervention to reduce

or eliminate risks, if justified,

and tracking to assure success

Program

Management &

Systems

Engineering

Requirements, Functions& System Elements

Modifications to

program plan

Table 3 – Risk Tracking Matrix

4.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.

Task Assignment\ Team Member

Task 1: Project and Systems Engineering Management

Task 2: Develop Concept of Operations (CONOPS)

Task 3: Develop System Requirements (SyRS)

Task 4: Conduct System Design

Task 5: Prepare a Deployment and Field Test Plan

Project Management Team

Brian Smith, UVA Review, Approve

Review, Approve

Review, Approve

Review, Approve

Review, Approve

Hyungjun Park, UVA Review, Approve

Review, Approve

Review, Approve

Review, Approve

Review, Approve

Melissa Vance, VDOT Review, Approve

Review, Approve

Review, Approve

Review, Approve

Review, Approve

Project Panel

Greg Larson (CalTrans) Review Review Review Review Review

Faisal Saleem (Maricopa County in Arizona)

Review Review Review Review Review

Ben McKeever (FHWA) Review Review Review Review Review

Danielle Deneau (Oakland County in Michigan)

Review Review Review Review Review

Ray Derr (TRB/NCHRP) Review Review Review Review Review

Project Team

Larry Head, UA Lead Input

Lead Input

Lead Input

Lead Input

Lead Input

Ann Wilkey, UA Support Input

Support Input

Support Input

Support Input

Support Input

GRA, UA Support Support Support Support

Steve Shladover, PATH Input Input Input Input Input

Wei Bin Zhang, PATH Input Input Input Input

Liping Zhang, PATH Input Input Input Input

Kun Zhou, PATH Input Input Input Input

Gary Duncan, Econolite Input Input Input

Eric Raamot, Econolite Input Input Input

Ramesh Siripurapu, Savari

Input Input Input

David Kelley, SCSC Input Input Input

Justin McNew, Kapsch Input Input Input

Mike Siebert, Volvo Technologies

Input Input Input

Table 4 – Project Roles and Responsibilities



4.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 Concept of Operations, Requirements, System Design,

and Field Implementation and Test Plans.

5 SUPPORTING PROCESSES

5.1 COMMUNICATIONS MANAGEMENT This section reviews the integrated processes, provisions, and plans, detailed in other sections, that

ensure timely generation, collection, distribution, storage, retrieval, and ultimate disposition of key project

information. The Principal Investigator (PI) and Systems Engineer responsible for the activities and

products provided under Communications Management.

The PI is the primary point of contact (POC) for all communications between the Project Manager, CTS

PFS Project Panel, and Project Team. In the event of a planned or unplanned absence, the PI will define

an authorized delegate to serve as a POC. Such delegation will be authorized through a memorandum of

record detailing the delegate, delegated scope of authority, and specific period of delegation.

Working in collaboration with the Project Team, the PI shall be responsible for organizing team meetings

and critical communications in support of the ConOps Development members and stakeholders. The PI

will utilize the most appropriate communication forum, such as email, teleconferences, and written

documentation, to communicate with internal and external project members (See: Figure 2 and Figure 3)

on the organization and scheduling of project activities such as Stakeholder Meetings, Walkthrough

Reviews, Requirements Development, and Test, Integration, and Evaluation Plans.

Regular and effective communications with the Project Team are critical to the success of the project. As

such, weekly teleconferences are scheduled for Tuesday afternoons from 4:30-5:30PM PST. Until a

WebEx connection is defined, a dial-in service has been defined: Call in Number 916-209-4534 Pin:

6389144. Materials reviewed in the weekly teleconferences will be made available through the PFP CM

system (SVN) repository prior to the meeting. In addition, the SE will compile and post draft meeting

minutes in the repository within three days. The Quality Management and Configuration Management

plans provide provisions for reviewing the minutes, removing the “draft” marking, naming the documents

and electronic files, and posting the resulting materials in the project SVN repository.

The communication activities are summarized in Table 5. Configuration Management and Quality

Management sections provide information on details supporting written communications, document

identification, revision control, and storage. Refer to these sections for more specific information.

Communication Item/ Activity

Purpose Frequency Intended Audience

Monthly Progress Reports

Provide monthly status on project tasks, budgets, action items, and risk assessments.

Monthly Program Manager, Sponsoring Organization, Project Team

Update Conference Calls

Provide synopsis of project task progress, budgetary status, action item status, and risk assessments and solicit constructive feedback on project activities.

Quarterly Program Manager, Sponsoring Organization



Communication Item/ Activity

Purpose Frequency Intended Audience

Project Team Meetings Exchange and monitor task progress, identify and quantify project risks, and modify tasking responsibilities and details as appropriate.

Weekly Internal Project Team Members

Project Management Plan

Provide guidance on the management of the Pooled Fund: Multi-Modal Intelligent Traffic Signal System (MMITSS) project

Draft and Final PMP

Program Manager, Project Panel, Project Team

Stakeholder Meetings Solicit, gather, synthesize, and document input from identified stakeholders regarding goals, needs, and system performance measures.

Two Per Project Schedule

Program Manager, Project Panel, Stakeholder

Concept of Operations The ConOps provides a stakeholder-influenced vision and roadmap for the development, deployment, operation and maintenance of future Multi-Modal Intelligent Traffic Signal Systems.

Per Project Schedule

Program Manager, Project Panel, Stakeholder, Project Team

SyRS The System Requirements form the basis for the design, implementation, testing, and acceptance of any system.

Per Project Schedule

Program Manager, Project Panel, Project Team

Table 5 – Communication Activities

5.2 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 PFP SVN repository.

CM-Controlled Item Filename

Project Plan Source: PFP_ProjectPlan.mpp Distribution: PFP_ProjectPlan.pdf

Project Management Plan (PMP) Source: PFP_PMP.docx Distribution: PFP_PMP.pdf

Monthly Progress Reports Source: PFP_MonthlyReport_mmyy.docx Distribution: PFP_MonthlyReport_mmyy.pdf

Quarterly Briefings Source: PFP_QtrBriefing_ddmmyy.pptx Distribution: PFP_QtrBriefing_ddmmyy.pdf

Quarterly Briefings Meeting Minutes Source: PFP_QtrBriefingMinutes_ddmmyy.docx Distribution: PFP_QtrBriefingMinutes_ddmmyy.pdf

Concept of Operations Draft Source: PFP_CONOPSDraft.docx Draft Distribution: PFP_CONOPSDraft.pdf Final Source: PFP_CONOPSFinal.docx Final Distribution: PFP_CONOPSFinal.pdf

Systems Requirements Document Source: DOORS Secondary Source: PFP_SRD.docx (DOORS export) Distribution: PFP_SRD.pdf

System Design Description Source: PFP_SDD.docx



CM-Controlled Item Filename

Distribution: PFP_SDD.pdf

System Test Plan Source: PFP_STP.docx (PFP_STPMatrix.xlsx) Distribution: PFP_STP.pdf, PFP_STPMatrix.pdf

Teleconference Meeting Minutes Source: PFP_Telecon_ddmmyy.docx Distribution: PFP_Telecon_ddmmyy.pdf

Table 6 – CM File Naming Conventions



6 APPENDICES

APPENDIX A: TASK DESCRIPTIONS Deliverables:

• Task 1: Project Plan, 3/29/2012

• Task 2: Concept of Operations, 8/16/2012

• Task 3: System Requirements Document, 12/6/2012

• Task 4: System Design Document, 1/17/2013

• Task 5: Deployment and Fiend Test Plan, 2/28/2013

Task 1 – Project and Systems Engineering Management

The purpose of this task is to provide project management support for all tasks described in this scope of

services. The Monthly Progress Reports shall contain the following sections: 1) Executive Summary

highlighting the overall project status and comments summarizing how and issues are being addressed,

2) Controls section highlighting any significant issues and the associated risk analysis, 3) Budget

Summary, 4) Status of Scheduled Milestones/Deliverables, and 5) Accomplishments and Plans.

Deliverable: Project Management Plan

Deliverable: Monthly Progress Reports and Quarterly Update Conference Calls

Task 2 – Develop Concept of Operations (ConOps)

A Concept of Operations (ConOps) captures the stakeholders views of the system being developed and

is written so that it can be easily reviewed by the various stakeholder communities. The Concept of

Operations will provide a vision and a roadmap for the development, deployment, operation and

maintenance of future Multi-Modal Intelligent Traffic Signal Systems. It will identify clear goals for a Multi-

Modal Intelligent Traffic Signal System to achieve to support a transformation of traffic signal control from

today’s technology into a safer and more efficient system for the future. It will identify opportunities for

early deployment and adoption as an enabling technology that will support wide scale technology

adoption.

Deliverable: Report on Assessment of Relevant Prior and Ongoing Research

Deliverable: Stakeholder Workshop Report

Deliverable: Concept of Operations Document

Task 2.1 – Assessment of Relevant Prior and Ongoing Research

The Research Team will prepare a Report on Assessment of Relevant Prior and Ongoing Research that

will identify the literature and project sources. This report will be structured to include traffic control

algorithms and strategies, standards and technology developments, past and on-going projects, US DOT

and AASHTO strategic plans, and other sources of Connected Vehicle activities that could influence the

development of a Multi-Modal Intelligent Traffic Management System.

Task 2.2 – Solicit Stakeholder Input on Transformative Goals, Performance Measures and User

Needs



The Research Team will conduct two (2) stakeholder meetings, plus informal solicitations from relevant

stakeholders, to identify transformative benefits for the application, corresponding performance

measures, and user needs for the application. The first stakeholder meeting will include key stakeholders

representing different classes of users, owners, and operators. The second stakeholder meeting will be

conducted as a webinar where a larger and broader group of participants can be included. The Research

Team will develop a report summarizing the findings of the workshop.

Subtask 2.3 – Develop Concept of Operations (ConOps)

The Assessment of Relevant Prior Research, Stakeholder Inputs and Research Team vision will be used

to develop the Concept of Operations. The Concept of Operations document is intended to capture the

stakeholders’ views and is to be easily readable by the stakeholder community. The Research Team will

follow the IEEE Standard 1362-1998 format. A Concept of Operations Walkthrough will be conducted to

review the document with critical stakeholders.

Task 3 – Develop System Requirements (SyRS)

The System Requirements Specification forms the basis for the design, implementation, testing, and

acceptance of any system. Each requirement places a cost on the system, hence it is important that a

minimum set of requirements be defined and that each requirement be verifiable and traceable to its

origin, such as to a need identified in the Concept of Operations. Requirements can be related to system

functionality, the technology available to build the system, functional performance, acquisition and

operating cost, the system-ilities that include reliability, maintainability, availability, and trade-offs between

performance and cost/utilization. Requirements must also be testable so that the developed system can

be verified to satisfy the requirements. Requirements are based on sound understanding and analysis of

the problem.

The will develop a set of system requirements based on the Concept of Operations. The requirements will

be developed following the guidance in IEEE Standard 1233-1998, IEEE Guide for Developing System

Requirements Specifications and using the DOORS requirements management tool that supports

requirements tracking and management. The Research Team will prepare Walkthrough Workbooks and

will conduct a Requirements Review Meeting. Based on the comments received in the Requirements

Review the System Requirements will be revised and Comment Resolution Report will be developed and

delivered.

Deliverable: System Requirements Document

Task 4 – Conduct System Design

Based on the Concept of Operations and the System Requirements Specification, high-level system

designs will be developed based on deployment on the existing Arizona and California test beds. The

high level designs will be represented considering several stakeholder views. These views include the

users (multi modal travelers), operators, maintainers, and managers (owners). Since each of the field

sites is currently based on different technology, the high level design will seek to identify common and

custom design features required for the respective implementation.

Each design will include a detailed deployment specification that includes hardware components,

software components, software artifacts (e.g. J2735 MAPs, traffic signal controller databases) interfaces,

messages, backhaul communications, and power for the respective network topology. Each design will



include a requirements allocation view to ensure that each design meets the requirements. Each design

will be evaluated with respect to the requirements.

Deliverable: System Design Document

Task 5 – Prepare a Deployment and Field Test Plan

The Research Team will develop Field Deployment and Test Plans for both the California and Arizona

test networks. Each Field Deployment Plan will include a schedule and cost estimate and identification of

any specific issues that need to be addressed for the respective network. A common Test Plan will be

developed for both test beds. It is possible that one or more of the Dynamic Mobility Applications (e.g.

Intelligent Traffic Signal System, Transit Signal Priority, Mobile Accessible Pedestrian Signal System,

Emergency Vehicle Preemption, and Freight Signal Priority) might not be operational in one of the test

networks, but an important goal of this project is to demonstrate the ability to provide the same

functionality on different implementations and networks.

Deliverable: Deployment and Field Test Plan



APPENDIX B: ACRONYMS AASHTO American Association of State Highway and Transportation Officials CM Configuration Management CoE College of Engineering ConOps Concept of Operations CTS Center for Transportation Studies (University of Virginia) DMA Dynamic Mobility Applications CTS PFS Cooperative Transportation Systems – Pooled Fund Study DOORS Dynamic Object Oriented Requirement System DOT Department of Transportation DSRC Dedicated Short Range Communication FHWA Federal Highway Administration FSP Freight Signal Priority GHz Gigahertz (1 x 10

9 Hz)

GPS Global Positioning System HR Human Resources IEEE Institute of Electrical and Electronic Engineers GRA Graduate Research Assistant/Associate ID Identifier/Identification ISIG Intelligent Traffic Signal System ISO International Organization for Standardization ITS Intelligent Transportation Systems MMITSS Multi-Modal Intelligent Traffic Signal System MPP Microsoft Project Plan NCHRP National Cooperative Highway Research Program NTCIP National Transportation Communications for ITS 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 PM Program Manager PMP Project Management Plan PPT PowerPoint PST Pacific Standard Time RFP Request for Proposal SAE Society of Automotive Engineers SCSC Subcarrier Systems Corporation SDD System Description Document SIE Systems and Industrial Engineering SPA Standard Process Assets SPaT Signal Phase and Timing SRD System Requirements Document SSC Space and Naval Warfare Systems Center STP System Test Plan SVN Subversion (Version Control System) TRB Transportation Research Board TSP Transit Signal Priority UA University of Arizona US United States V2I Vehicle to Infrastructure V2V Vehicle to Vehicle UVa University of Virginia VDOT Virginia Department of Transportation WBS Work Breakdown Structure

APPENDIX C: PROJECT PLAN









Documents

Multi-Modal Intelligent Traffic Signal System · The Multi-Modal Intelligent Traffic Signal System ... communicate information such as passenger ... from the smart phone of registered