San Mateo County Smart Corridors Program






Prepared by:





SEPTEMBER 18, 2009








Document: #10000.004


1.0       Introduction.. 1

2.0       Relevant Documents. 2

2.1       Relevant Documents. 2

3.0       Purpose of Document. 3

4.0       Scope of Project. 3

4.1       Project Phasing.. 4

4.2       Stakeholder Roles. 5

4.3       Technical Challenges. 8

5.0       Systems Engineering Process. 8

5.1       System Engineering Planning Process. 8

5.2       Regional System Architecture. 11

5.3       Standards. 11

6.0       Technical Planning and Control. 14

6.1       WBS Structure. 14

6.2       Task Deliverables. 15

6.3       Schedule. 15

6.4       Interface Control Plan Guidelines. 16

6.5       Technical Review Plan.. 17

6.6       System Integration Plan.. 17

6.7       Verification Plan Guidelines. 19

6.8       Deployment Plan.. 20

6.9       Operations and Maintenance Plan.. 22

6.10     Training Plan.. 24

6.11     Configuration Management Plan.. 24

6.12     Risk Management Plan.. 26

6.13     System Procurement Plan.. 27

6.14     System Development Plan.. 27

6.15     Quality Management Plan.. 29

6.16     Documentation.. 31

6.17     Systems Engineering Management Plan (as provided under the current contract) 32

6.18     Requirements Documentation (as provided under the current contract) 33

7.0       Transitioning Critical Technologies. 34



Table 1 – Project Goals

Table 2 – Project Stakeholders and Current Roles

Table 3 – Systems Engineering and Rule 940

Table 4 – Design Reference Documents

Table 5 – Device Interfaces and Standards

Table 7 – Project Schedule Milestones (Systems Engineering Only)

Table 8 – Potential Project Risks and Proposed Mitigation

Table 9 – Quality Assurance Matrix



Figure 1 – Smart Corridor Project Phasing

Figure 2 – System “V” Diagram



Appendix 1      Project Schedule (Program Schedule and Project Schedule)

Appendix 2      Glossary and Abbreviations




1.0            Introduction

The City/County Association of Governments of San Mateo County (C/CAG) and the San Mateo County Transportation Authority (SMCTA) in conjunction with the California Department of Transportation (Caltrans) has initiated an effort to address the operation of the freeway and arterial roadway network in San Mateo County.  The San Mateo County Smart Corridor Program is intended to benefit a variety of users including commuters, local traffic, and commercial vehicle and transit operators.

A Traffic Incident Management Committee (TIMC) was formed to identify and evaluate projects under the Smart Corridor Program. The TIMC is comprised of representatives of local agencies, California Department of Transportation (Caltrans), California Highway Patrol (CHP), Metropolitan Transportation Commission (MTC), San Mateo County Office of Emergency Services (OES), and San Francisco International Airport (SFO) as well as C/CAG and SMCTA. The TIMC focus is to increase coordination between Caltrans, CHP, local agency public safety, and local agency public works staff during freeway incidents when a significant amount of traffic is expected to exit the freeway and use local streets as an alternate.

In addition, a Steering Committee was established as the decision-making body of the Smart Corridors Program. Members include the Caltrans District 4 Chief of Operations, the MTC Director of Highway Operations, the SMCTA Program Director, the San Mateo City Public Works Director, and the C/CAG Executive Director.

The mitigation of the impacts of non-recurring traffic congestion on local streets within San Mateo County during major freeway incidents on US-101 was identified as a high-priority project in the Smart Corridor Program.  A Project Report (PR) was written that proposes the deployment of integrated Intelligent Transportation System (ITS) elements to provide local agencies and Caltrans the tools to manage this congestion.  The project includes the installation of the following ITS elements:


·         Directional signs (trailblazer and turn prohibition) to direct traffic;

·         Fixed or pan-tilt-zoom closed-circuit television cameras at intersections and midblock locations to monitor traffic congestion and end-of-queue location;

·         Communications to provide interconnect between local agency traffic signals on local streets and State operated traffic signals on State routes;

·         Upgraded traffic signal controllers and/or cabinets and signal operation software systems;

·         Arterial changeable message signs to inform motorists of traffic conditions (also referred to as Arterial Dynamic Message Signs in this document);

·         Center-to-center communications between the proposed San Mateo County Hub (SMCHub) and the Caltrans District 4 Transportation Management Center (D4TMC) (note where TMC is used in a general manner in this document, it refers to the SMCHub, the D4TMC and local TMC’s); and

·         Vehicle detector stations (non-intrusive or intrusive technology) on non-freeway state routes (El Camino Real) and local streets at mid-block locations.

Many of these same elements can also be used to manage traffic along the corridor during recurrent congestion.  In addition to the ITS elements noted above, the following ITS elements were identified for possible deployment on future projects:


·         Transit priority service at intersections;

·         Emergency vehicle preemption at intersections;

·         Highway Advisory Radio (HAR) transmitters and signs;

·         Advance warning signs at Caltrain at-grade crossings;

·        Changeable message signs for arterial travel times.

The TIMC also facilitated the development of the Alternate Routes for Traffic Incident (ARTI) Guide (April 2008) to identify arterial streets that would best serve as alternative routes for moving traffic during incidents on US-101 and minimizing the impacts of diverted traffic on the local street network across multi-jurisdictional boundaries. During a major freeway incident on US-101, Caltrans operators at the D4 TMC will implement signal timing plans and activate trailblazer signs along the appropriate ARTI route(s) and notify the local agencies that the management of the alternate route(s) is in effect. The ARTI Guide has subsequently been revised (June 2009) with the assistance of Caltrans staff.

In addition, traffic signal timing modifications will be implemented to manage traffic that has exited the freeway during incidents. The project is estimated to cost $30.71 million, with $22.37 million in construction costs, with a phased approach proposed. A Project Study Report (PSR) for this project was approved on March 28, 2008.

A Concept of Operations (ConOps) was prepared in October 2008 and updated in September 2009, with input from local agencies and Caltrans, and direction from the Federal Highway Administration (FHWA).  This is an initial step in the Systems Engineering process defined by the FHWA.  This document identifies the stakeholders, their roles and responsibilities, their coordination with each other, and how the system will be developed.

2.0            Relevant Documents

2.1              Relevant Documents

Relevant documents include:

·        FHWA/Caltrans Systems Engineering Guidebook for ITS, version 2.0, January 2007

·        Final Draft ITS Infrastructure Improvement Plan, San Mateo County Alternative Route Plan, January 2008

·        Draft Project Report in San Mateo County on US-101 and SR-82 from I-380 to the Santa Clara County Line, San Mateo County Smart Corridors, EA 4A9200, October 2008

·        Project Study Report to Request Programming in the STIP for Phase 1of the San Mateo County Smart Corridors, March 2008

·        San Mateo County Smart Corridors Projects Traffic Light Synchronization Program Funding Application March 2008

·        San Mateo County Arterial Route for Traffic Incident Guide, June 2009

·        San Mateo County Smart Corridors Program Concept of Operations, October 2008, updated September 2009

·        Functional Requirements, San Mateo County Smart Corridors Program, version 12000.007, September 2009

·        High Level Requirements, San Mateo County Smart Corridors Program, version 13000.003, September 2009

·        Detailed Design Requirements, San Mateo County Smart Corridors Program, version 13500.004, September 2009

·        Interface Control Requirements, San Mateo County Smart Corridors Program, version 14000.004 September 2009

·        Detailed Design Requirements Test Plan, San Mateo County Smart Corridors Program, version 23000.004, September 2009             

3.0            Purpose of Document

The purpose of this document is to:

·        Identify the stakeholders and their roles/responsibilities

·        Document the process to be followed in developing, installing, operating and maintaining the system

·        Specify the documentation requirements for the system

·        Document the management controls that will be used to manage the project

4.0            Scope of Project

The goals of the project identified in the Concept of Operations have been modified as shown in Table 1


Table 1 – Project Goals

Goal Area

Smart Corridors Program Goals

Traffic Incident Management

·         Proactively manage traffic already diverted from the freeway to minimize impacts on local arterials, and return regional traffic back to the freeway as soon as possible by:

o        Actively managing traffic signal operations on selected routes to maximize traffic flow around a major incident and minimize delays caused by diverted freeway traffic.

o        Improving collection of current travel condition information along local arterials on the alternate routes. (Future)

o        Providing accurate and timely route guidance information about the corridors to agency transportation managers. (Future)

o        Minimizing the intrusion of freeway traffic on local streets due to major freeway incidents.



·         Provide the capability for shared control and operation of the Smart Corridors components by the agencies.

·         Improve sharing of resources between agencies for more unified transportation management operations across jurisdictions.

·         Improve communications between the agencies during major freeway incidents

Traffic Operations and Management

·         Improve traffic flow within the corridor during normal operation

·         Share traffic information between the agencies to improve coordination and management of traffic during normal operations

4.1              Project Phasing

The complete deployment of the Smart Corridor program includes the freeway network and parallel arterials of regional significance in San Mateo County. The deployment will be completed in phases, with each subsequent phase building upon the elements of previous phases.

The Smart Corridor Project Phasing shows the map of San Mateo County with the three phases of the Smart Corridors program color coded.

Figure 1 – Smart Corridor Project Phasing

As shown in Figure 1, there are three primary phases currently planned for the Smart Corridors program with full buildout including additional future phases when funding becomes available and policy dictates. The first three phases are:

·        Phase I – US-101 and adjacent local streets between I-380 and 3rd Avenue;

·        Phase II – US-101 and adjacent local streets between 3rd Avenue and Whipple Avenue; and

·        Phase III – US-101 and adjacent local streets between Holly Street and the Santa Clara County Line.

The current project includes Phases I and II.

4.2              Stakeholder Roles

The stakeholders and their roles in this project are listed in Table 2.

Table 2 – Project Stakeholders and Current and Proposed Roles


Current Role(s)


Organize stakeholders in San Mateo County and build consensus; project champion/sponsor; administrative lead.


Operate and maintains the freeways (US-101) and state routes (El Camino Real, SR-84, etc.). Lead the technical side of the project. Will operate the system in the event of a major incident.


Administers the proceeds of a county-wide half-cent sales tax (Measure A) for transportation projects; participates in project steering committee; administers consultant contracts.


Enforcement, security, and accident investigation on the freeways and state highways. Typically the incident commander.


Metropolitan Planning Organization (MPO) of the Bay Area, maintains the Regional ITS Architecture, distributes transportation funds; operates and maintains 511, the regional ATIS, and the regional center-to-center data sharing network (currently in development)

San Mateo County

Operate and maintain arterials within its jurisdiction.

San Mateo County Transit (SamTrans)

Operate bus service on the arterials and freeways.


Operate heavy commuter rail service and support private shuttle service

Bay Area Rapid Transit (BART)

Operate commuter rail service.

Dumbarton Express

Operate bus service on the arterials and freeways.

Local Emergency Response and Public Safety Agencies

Respond to incidents on local routes, coordinate with traffic management personnel on local and state routes, coordinate with CHP during major incidents.

Town of Atherton

Operate and maintain arterials within its jurisdiction.

City of Belmont

Operate and maintain arterials within its jurisdiction.

City of Burlingame

Operate and maintain arterials within its jurisdiction.

City of East Palo Alto

Operate and maintain arterials within its jurisdiction.

City of Foster City

Operate and maintain arterials within its jurisdiction.

City of Menlo Park

Operate and maintain arterials within its jurisdiction.

City of Millbrae

Operate and maintain arterials within its jurisdiction.

City of Redwood City

Operate and maintain arterials within its jurisdiction.

City of San Bruno

Operate and maintain arterials within its jurisdiction.

City of San Carlos

Operate and maintain arterials within its jurisdiction.

City of San Mateo

Operate and maintain arterials within its jurisdiction.

City of South San Francisco

Operate and maintain arterials within its jurisdiction.


Develop plans, specifications and estimates.


Develop and implement system engineering process.




The ARTI provides the stakeholders a guideline/process for implementing route guidance and operational strategies to manage diverted traffic on local streets, minimizing the impacts on the residents of County of San Mateo. The primary objectives of the project identified in the ARTI are:

·        Proactively manage traffic on local streets that has diverted off the freeway due to a major incident on US-101 or other freeway;

·        Minimize the delay that traffic experiences on local streets during major freeway incidents;

·        Instrument local streets and provide the TMC operators with the tools to proactively manage traffic detoured due to an incident;

·        Enhance the communications and coordination between “local agency public safety, Caltrans, CHP, and local agency public works” to create a regional approach to managing incident traffic; and

·        Enable local agencies to share information and control strategies to enhance traffic management.

Through installation of ITS equipment along the alternate routes, the stakeholders will have tools and strategies that will enable them to do the following:

·        Change route guidance signs to guide incident traffic along a specific alternate route to avoid a situation where drivers seek unknown routes;

·        Increase the green time along an alternate route during an incident to reduce the travel time.

·        Monitor traffic on local streets;

·        Share data and video between agencies to create a regional partnership to manage traffic; and

·        Coordinate operations between Caltrans and local agencies during major incidents.

Caltrans will be required to commit to active operation and control of the Smart Corridor tools by the D4TMC operators with support from local agencies. Active operation during major freeway incidents will include implementing alternate route signage and monitoring CCTV camera images to optimize the flow of traffic along alternate routes. If necessary, it will also require adjusting alternate routes device parameters in response to changing conditions. The system will also require communication and coordination between agencies, adjustment of signal timing, notifications to travelers, and other operational strategies implementation along the affected portion of the corridor in an event of major freeway incident.

The segment of US-101 within the County of San Mateo is part of the National Highway System, classified as a strategic highway network route to provide defense access, continuity, and emergency capability for transporting personnel, materials, and equipments during both peace and war times.

4.3              Technical Challenges

Technical challenges to be faced on this project include:

·        Potential integration of legacy equipment

·        Coordination of signals across jurisdictional boundaries

·        Sharing of control on a hierarchical basis

·        Providing a communications network on already crowded local roadways

·        Providing aesthetically pleasing equipment in an urban setting

·        Potential use of a hybrid communications system

·        Integration of local ITS equipment and systems into a regional traffic management center

·        Future integration of the local systems into the Caltrans ATMS

5.0            Systems Engineering Process

5.1              System Engineering Planning Process

The systems engineering planning process is an interdisciplinary approach that helps to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements and proceeding with design synthesis and system validation while considering the complete problem:

·        Operations

·        Performance

·        Test

·        Manufacturing

·        Cost & Schedule

·        Training and Support

·        Disposal

Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

The SE process (“the process”) is used to identify the project’s needs and constraints and lay out the activities, resources, budget, and timeline for the project. A critical part of the process is to build consensus among the stakeholders of the project. The process should be applicable at all stages of a project, from initial system planning through final operations and maintenance of the system.

FHWA Federal Rule 940, Intelligent Transportation Systems Architecture and Standards, which implements Section 5206 (e) of the Transportation Equity Act of the 21st Century (TEA – 21), requires agencies implementing projects with ITS elements utilizing federal funds to develop regional architectures and adopt a SE approach for project deployments in order to qualify for ITS grants.

The process shall be followed for the San Mateo County Smart Corridors Program.

The following table illustrates the relationship between the various processes of the SE process and Rule 940.

Table 3 – Systems Engineering and Rule 940

Table Systems Engineering and Rule 940 shows the relationships between the systems engineering process steps (Concept of Operations, Requirements: High-Level and Detailed, and Design: High-Level and Detailed) and the corresponding Rule 940 requirements.

The systems engineering process shall follow the guidelines in the “System Engineering Guidebook for ITS”, version 2.0 dated January 2, 2007 published by the Federal Highway Administration/California Division and Caltrans/Division of Research and Innovation.

The systems engineering process can be summarized in a “V” diagram (see Figure 2 below). The first phase of the process involves concept exploration and identification of regional architecture requirements. The next phase includes developing a SEMP (this document) and a Concept of Operations for the proposed system. Once those are completed, the system requirements (both functional and performance) are able to be determined, and a matrix is developed that ties all requirements to their origin in the Concept of Operations document. This matrix will later be used as a System Verification plan. This is followed by high-level design, which develops requirements for subsystems and begins to detail the architecture of the system. The next phase is detailed design, which draws from all the previous documents to identify each piece of the system and produce plans for construction. During all stages of construction and installation, the process is used to test, validate, and accept systems and subsystems to ensure that the final product will meet or exceed the expectations written out during the planning and design phases.


V Diagram - top

V Diagram - middle part 1

V Diagram - middle part 2

V Diagram - bottom

Figure 2 – System “V” Diagram

At each stage of the above noted figure, applicable documents will be developed. A typical project would include but not be limited to the following (not necessarily in order):

·        Regional System Architecture

·        Concept of Operations

·        System Engineering Management Plan

·        Functional Requirements

·        High-Level Requirements

·        Detailed Design Requirements

·        Interface Control Requirements

·        Configuration Management Plan

·        Deployment Plan

·        Design Documents including PS&E

·        System Integration Plan

·        Individual Test Plans

·        System Acceptance Test Plan

·        Verification Plans

·        Test Plan Results

·        Maintenance Plan

·        Operations Plan

For a list of specific documents that will be developed for this project, please see pages 31 and 32.  For this project, requirements are broken into several documents:

·        Functional requirements

·        High-level requirements

·        Detailed design requirements

·        Interface control requirements

Requirements focus on “what” the system must do, not “how” the system does it. A requirements analysis includes:

·        Functions

·        Expected outcomes

·        Definition of expected interfaces

·        Performance objectives

The requirements defined should be based on the ConOps developed previously. When considered against the requirements of Federal Rule 940, this step of the process relates to the requirements definition aspect of the systems engineering analysis.

Requirements will be traced in a matrix from the ConOps through the Requirements to the Test Plans.

Many documents (such as the SEMP) will be living documents, subject to revision as the process moves forward. The documents serve to provide connection between the various phases of the project and a framework from which to build a well-functioning system that brings benefits to all stakeholders and end users.

5.2              Regional System Architecture

The proposed system shall be compatible with the Bay Area Regional Architecture.

The proposed system shall use the Bay Area C2C communications protocol between systems.

It is not necessary that the interface protocol between components in a system or subsystem be compatible with like components in another system or subsystem.

5.3              Standards

National Transportation Communications for ITS Protocol (NTCIP) defines a family of general-purpose communications protocols and transportation-specific data dictionaries/message sets that support most types of computer systems and field devices used in transportation management. Applications for NTCIP are generally divided into two categories: center-to-field (C2F) and center-to-center (C2C). The former, normally involves devices at the roadside, communicating with management software on the central computer. C2C applications usually involve computer-to-computer communications where the computers can be in the same room, in management centers operated by adjacent agencies, or across the county. Some of the data transfers involved in ITS operational uses have special needs that are the subject of other standards not covered under NTCIP. NTCIP standards can be classified into: primary, supporting and base standards and protocols.

Equipment compatibility will be confirmed in several ways:

·        Specifying the required compatibility with the D4 TMC

·        Specifying equipment that is either similar or identical to that which has already been integrated with the D4 TMC

·        Performing verification and validation testing on ITS components

·        Performing a System Acceptance Test

The following table lists reference documents to be followed in the design, implementation, testing, operation and maintenance of the proposed system.

Table 4 – Design Reference Documents


Reference Source

Standard for Application and Management of the Systems Engineering Process, IEEE Std 1220-1998, December 8, 1998

The Institute of Electrical and Electronics Engineers, Inc.

Guide for Information Technology – System Definition – Concept of Operations (ConOps) Document, IEEE Std 1362-1998, March 19, 1998

The Institute of Electrical and Electronics Engineers, Inc.

System Life Cycle Processes, ISO/IEC Standard 15288, October 2002

ISO Central Secretariat, International Organization for Standardization (ISO)

Quality Management System Guidelines for Configuration Management Revision 3,ISO 10007, June 15, 2003

ISO Central Secretariat, International Organization for Standardization (ISO)

Quality Management System Requirements, ISO 9001, December 15, 2000

ISO Central Secretariat, International Organization for Standardization (ISO)

Transportation Electrical Equipment Specifications (TEES) for Model 334 CCTV housing and mounting cage.


Caltrans "Standards Specifications" dated 2006


Caltrans "Standard Plans and Erratum No 2006


Caltrans Ramp Meter Design Manual, Jan. 2000


Caltrans Transportation Electrical Equipment Specifications (TEES), Nov. 1999 and updates


Caltrans TEES Chapter 8, CMS Model 500 (series) Specifications,  latest version


Caltrans Division of Materials Engineering and Testing Services, Xenon Changeable Message Sign, Quality Assurance and Testing Guidelines, latest version


IEEE 1220-1998, Institute of Electrical and Electronic Engineers (IEEE), Standard for Application and Management of the Systems Engineering Process, 1998


EIA 632, Electronics Industries Association (EIA), Processes for Engineering a System, Jan. 1999


EIA/IS 632, Systems Engineering, Interim Standard, Sep. 20, 1994


EIA-359 (ANSI C83.1), Colors for Color Identification and Coding, Jul. 1998


EIA-359-1 Addendum 1 to EIA-359, Electronics Industries Association (EIA), Special Colors (for Color Identification and Coding), Jul. 1998


TIA/EIA-456, Telecommunications Industries Association / Electronics Industries Association (TIA/EIA), Test Procedure for Fiber Optic Fibers, Cables, Transducers, Sensors, Connecting and Terminating Devices, and Other Fiber Optic Components, Oct. 1998


TIA/EIA-568 SET Commercial Building Telecommunications Cabling Standards Set: Part 1 – General Requirements; Part 2 – Balanced Twisted Pair Cabling; Part 3 – Optical Fiber Cabling Components Standard, June 2002


TIA/EIA-569, Commercial Buildings Standard for Telecommunications Pathways and Spaces, Dec. 2001


TIA/EIA-598, Optical Fiber Cable Color Coding (ref. Munsell 10100, EIA SP 3555), Dec. 2001


TIA/EIA-606, Administration Standard for the Commercial Telecommunications Infrastructure


TIA/EIA-758 Customer-Owned Outside Plant Telecommunications Cabling Standard, Apr. 1999


Note: Above references to be confirmed during the design phase.

The system shall utilize the interface standards as noted in the following table.

Table 5 – Device Interfaces and Standards


Physical Interface

Interface Standard


Model 2070 Controllers to Protocol OTR/SHR

C2 S Connector

EIA RS-232


Model 170 Controllers


EIA RS-232

Per Caltrans

CCTV Camera Control Protocol to VOTR

DB 9 Connector

EIA RS-232

Specified CCR

CCTV Video Out to Video VOTR

BNC Connector/ Coaxial Cable


Color Full Motion

CMS to Modem

DB25 Connector

EIA RS-232 Protocol



DB25 Connector

EIA RS-232

Caltrans Protocol

Node Processor to Backbone

RJ 45

10 Base T


Node Processor to (see OTR/SHR above)

DB25 Connector

EIA RS-232

Device Specific

Node to TMC/TOC (TDM)

SC Connector, Single Mode Fiber



Video switch/ Video Demux

BNC Connector Coaxial Cable


Color Full Motion

Note: Above standards to be confirmed during the design phase.

Additional standards from ITE, SAE and IEEE will be determined during the design phase.

6.0            Technical Planning and Control

6.1              WBS Structure

A Work Breakdown Structure (WBS) is a hierarchical structure that contains the following information:

·        The identified project tasks and subtask

·        The name of the task or subtask

·        The allocated budget for the task or subtask (although this can be elsewhere)

·        The team or organization with the authorization to give direction to the task

·        The roles and responsibilities of those parties involved in the task

The WBS structure combined with the overall project schedule will be used to track discrete project activities.

The WBS structure and overall project schedule are shown in Appendix 1.

6.2              Task Deliverables

The systems engineering process as applied to the current project will produce, at a minimum, the following documents:

·        Systems Engineering Management Plan (SEMP)

·        Functional Requirements

·        High-Level Requirements

·        Detailed Design Requirements

·        Interface Control Requirements

·        Detailed Design Requirements Test Plan

·        Communications Alternatives Memorandum

·        Concept of Operations (revised to include minor changes as project progresses)

Other documents will be identified in this SEMP as to be developed as they are not part of the current system engineering contract. As the various phases of the Smart Corridors Program are implemented, these additional documents will be developed.

All documents will be first circulated as a draft.

Written comments will be requested within one week of submission.

One week following receipt of the comments, final versions of the documents will be issued.

Documents will be circulated to appropriate parties and agencies as necessary to ensure that a complete and timely review has been performed.

6.3              Schedule

A copy of the Smart Corridors System Engineering Services Project Schedule is included in Appendix 1. The systems engineering process will be applied throughout the entire project, and a table of key project milestones is shown below.

Table 7 – Project Schedule Milestones (Systems Engineering Only)


Date Complete

Concept of Operations

September 2009

Functional Requirements

September 2009

High-Level Requirements

September 2009

Communications Alternative Memorandum

April, 2009

Detailed Design Requirements

September 2009

Interface Control Requirements

September 2009

Detailed Design Requirements Test Plan

September 2009



The work breakdown structure shown in Appendix 1 will be used to track project progress. This schedule will be maintained and updated by Caltrans and C/CAG. As the systems engineering process creates additional inputs, the schedule will be revised.

6.4              Interface Control Plan Guidelines

Interfaces are the relationships among system components in which the components share, provide, or exchange data. Interface design shall include both interfaces among major components and their interfaces with external entities such as regional hubs, subsystems, operators, and general public users.

A Project-unique identifier shall be assigned to each interface. All interfacing entities (systems, configuration items, users, etc.) shall be identified by name, version, and documentation references, as applicable.

The identification shall also state which entities have fixed interface characteristics (and therefore impose interface requirements on interfacing entities) and which are being developed or modified (thus having interface requirements imposed on them).

One or more interface diagrams shall be provided, as applicable, to depict the interface.

For each interface, the description shall include, as applicable, the following with more details in the Interface Control Plan provided by the Contractor for the project.

·        Priority assigned to the interface by the interfacing identities

·        Type of interface (such as real-time data transfer, storage-and-retrieval of data, etc.)

·        Characteristics of individual data elements that the interfacing entities will provide, store, send, access, receive, etc.

·        Characteristics of data assemblies (records, messages, files, arrays, displays, reports, etc.) that the interfacing entities will provide, store, send, access, receive, etc.

·        Characteristics of communication methods that the interfacing entities will use for the interface

·        Characteristics of protocols that the interfacing entities will use for the interface

·        Other characteristics, such as physical compatibility of the interfacing entities (dimensions, tolerance, loads, voltages, plug compatibility, etc.)

An interface control requirements document will be developed. This document will recommend:

·        The proposed communication protocol standards to be utilized for interfacing field elements, subsystems and systems

·        Both the hardware and software interface standards to be followed. Potential interface control standards include:

-        Between the traffic signal control system and the cameras, CMS, trailblazer signs, vehicle detection systems and other traffic control systems (i.e. those associated with the Smart Corridor-other cities and Caltrans ATMS)

-        Between the Caltrans ATMS and the cameras, CMS, trailblazer signs, vehicle detection systems and other traffic control systems (i.e. those associated with the Smart Corridor-other cities and Caltrans ATMS)

-        It may also include the interface to non traffic control systems such as traveler information systems

6.5              Technical Review Plan

The most common outputs of the systems engineering process are documents, and ensuring that they accurately reflect the input of stakeholders is a critical component of the systems engineering management plan. For this project, all documents, whether developed by consultants, agencies, or third parties, should be reviewed by representatives of both the owning agency and the operating agency. This will help ensure that the final system will be functional and effective.

All comments received are to be tracked. If, during the review process, conflicting comments are made by various parties, the document originator will attempt to resolve them by working with each commenter individually. If this process does not take place reasonably quickly, or a solution does not appear to be simple and straightforward, then a meeting will be scheduled between all affected parties with the purpose of resolving the conflict.

During system implementation a formal review process will be necessary that requires the following:

·        all comments to be in writing

·        all comments are to be on a comment review form

·        resolution of all comments are to be in writing

·        a formal resolution conflict process is to be established with resolution first being attempted by technical staff. If that is not successful, the item in question is to be directed to a steering committee composed of senior stakeholders.  

6.6              System Integration Plan

System integration will be a joint effort of Caltrans, C/CAG and the selected Contractor. The contractor will be responsible for leading these efforts and for successful integration of the various components of the San Mateo Smart Corridor Project. The Contractor will also be responsible for developing a System Integration Plan specifically directed towards this project.

By following the System Integration Plan (SIP), the following actions will result:

·        Discrepancies and errors are detected and corrected as early as possible in the Project life cycle

·        Equipment and software quality and reliability is enhanced

·        Management visibility into the equipment development and software coordination is improved

·        Proposed changes to the Project and consequences of the changes can be quickly assessed

·        Project risk, cost and schedule are reduced

·        Testing tasks will be performed in parallel with the development of equipment and coordination of software

System integration will involve the use of a building block approach starting with elements combined into components which are then combined into subsystems and thence into a system. At each stage, testing will occur.

Testing Methodology-All system configuration items will undergo and successfully pass appropriate testing before it is released. Testing will include subsystem testing and integration testing. Pre-installation testing relates to tests of all material and equipment in a test environment prior to delivery to the Project Site. Equipment that is provided by Caltrans will undergo pre-installation testing/bench testing by Caltrans.

The initial testing will consist of tests on the individual subsystems (Arterial DMS, vehicle detection subsystem, directional sign subsystem, traffic signal subsystem, communications subsystem, and the project software). Within a given subsystem, the individual field elements (i.e., an arterial DMS) will first undergo manufacturer testing. Upon delivery to the project (or to Caltrans in the case of Caltrans-supplied equipment), the item will be subject to bench testing. This will be followed by field testing at the local cabinet followed by testing at the local TMC (if applicable), the SMCHub and the D4TMC. The TMC/Hub testing will involve end-to-end testing of the various ITS field elements where the project software is used to monitor and control the specific field device. Following successful completion of the individual subsystems, testing will occur per the system acceptance test plan to be developed at a later date.

Testing of the subsystems is dependent on the status of the field installations. However, before end-to-end testing of a subsystem can occur, the communications subsystem will need to first be successfully tested.

Testing will be documented at all stages with pass/fail/comments.

Testing will be performed by the system integrator with representatives from C/CAG and Caltrans. Manufacturer staff may be required at the discretion of the project engineer.

Testing personnel shall have a skill set suitable for the particular testing environment.

Failures will be classified as major or minor.

A major failure or a predetermined number of minor failures will be sufficient to either pause or restart the test from the beginning.

Integration will take place in phases. These phases are geographically based. As each phase becomes ready for integration, it will first be tested as a stand alone system before testing as part of the existing system.

Testing equipment to be utilized will include oscilloscopes, OTDR, voltmeters and other test equipment appropriate to the application. Inputs to the item being tested may be simulated, historical data or real time data.

System testing and design covers the integration testing which is required to validate the operational performance of equipment and software. For the Project, at least for the initial phase, there is expected to be little or no software creation or hardware development. To reduce project costs and risk, all software and hardware scheduled to be used is commercial off the shelf applications for at least the initial phase of the Project. This may change for subsequent phases.

Testing will be performed to validate the functionality of the field devices. This functionality will be end-to-end and will show that the devices can be controlled and monitored by the local and regional TMCs and eventually the Caltrans ATMS. The exact testing to be performed will be detailed in the individual device acceptance test plans and in the system acceptance test plan. If a malfunction is determined, the responsibility for correcting that malfunction will rest with the party responsible for where the malfunction is occurring (for example, if a camera is not providing an image and it is determined the camera is at fault, the installation contractor will fix the camera; if it is determined there is a problem with the communications lines between the Millbrae BART station and the D4 TMC, then the responsibility is Caltrans’.)

6.7              Verification Plan Guidelines

Acceptance testing for the Project will consist of a variety of tests ranging from tests at the factory on the proposed equipment through system acceptance testing.

Acceptance testing will be based on a matrix that is a function of the requirements, specifications, implementation, and the procedures to ensure that all requirements are tested. An overview is provided below with more details in the Detailed Design Requirements Test Plan. The Detailed Design Requirement Test Plan will include further definition of the test environment, input source/output, method of test, and traceability of a test to the requirements.

Factory tests – As part of the Project, a variety of equipment/material will be required. To ensure this equipment/material is suitable for this project and meets the specifications, it will be necessary that tests be performed at the factory. These tests will range from compliance with environmental requirements (i.e., the operating and storage temperature ranges) to the loss per meter in fiber optic cabling.

Delivery tests – Upon delivery of material to the selected project site, various tests will need to be performed. As a minimum, these tests will be to compare what was ordered with what was delivered and what was specified. Additionally, other tests such as noise loss of fiber optic cable on the reel will be required.

Bench tests – Following delivery testing, it is imperative that additional testing be performed in the shop before placement of the components in the field. This testing will range from simply powering up the component to establishing a mini-network in the shop to demonstrate receipt and transmission of messages as well as compatibility of the various components. Components such as modems will need to be tested to ensure they can transmit data and video and they can be individually addressed.

Component tests – Component testing will involve both installations at the D4TMC, at the IT server location, in the field and at remote locations as applicable. Components will need to be connected to the equipment in the cabinet/equipment at their respective locations and tests performed ranging from powering up to receipt/transmission of messages from the connected equipment.

Subsystem tests-Subsystems to be tested include CCTV, vehicle detectors, CMS, trailblazer signs, and traffic signals. However, to do subsystem testing, it will be necessary to first have the communications subsystem in place with a connection provided between the various locations. These communication links will need to be individually tested before connection to the transceivers or other communication devices. Recommended testing shall as be as per the Caltrans Fiber Optic Testing Guidelines (or equivalent). With the verification that the communication links are continuous (i.e., able to transmit a signal in both directions), testing of the subsystem can occur. This will involve sending signals from the field to the D4TMC and in the reverse direction. Faults will be intentionally introduced. The installed subsystems shall be inspected and tested to validate neat cable placement, cable markings and unit installation in accordance with manufacturer’s installation recommendations. Functional test shall be conducted for the subsystems to ensure that the subsystems perform the functions as a standalone system.

System tests-Once the various subsystems have been tested individually, a system acceptance test will need to be performed to ensure all components (existing and proposed) work together. This will involve end to end testing of all linkages. The testing initially consists of testing the functionality of the components by comparing it to the specifications. A traceability matrix is to be developed to aid in this process. Once the functionality of all the subsystems have been successfully tested, the communications subsystem will undergo an acceptance test period. This testing is typically performed over a 30- to 90-day period with rigid requirements that delineate between minor failures and major failures.

Test plans will be developed by Caltrans or their designated representative to verify the system provided meets the requirements of the specifications.

6.8              Deployment Plan

The deployment of the ITS elements for the San Mateo Smart Corridor Project will be based on the following requirements:

·        Organization:

§         Caltrans will be the lead technical entity

§         C/CAG will provide administrative and technical support to Caltrans

§         SMCTA, C/CAG, Caltrans, and Cities/County will be the contracting agencies

§         Consultants will be used as necessary for design functions, technical assistance during implementation, assistance with review of documentation and assistance during testing

§         Multiple Contractors will have responsibility for provision, implementation, integration and testing of their portion of the proposed system.

§         A System Integrator will have overall responsibility to coordinate the work of multiple Contractors and integrate and test the entire Smart Corridor system.

·        The Project will follow a staged implementation:

§         The pilot implementation will be in the City of San Mateo

§         Following successful implementation of the pilot, the next implementation will be Phases I and II (see Figure 1) with implementation occurring from I-380 south.

§         The final implementation will be Phase III

·        Procurement

§         The initial procurement will be for the pilot implementation followed by Phases I and II which will be followed by Phase III.

§         Equipment provided by Caltrans will be uniquely identified and provided in a timely manner

§         All procurements should be competitive.

§         The option shall exist for public agencies to provide equipment to the selected integration and installation contractor(s).

§         Maximum use shall be made of multi-agency procurements.

§         The procurement process shall follow the requirements of the local agencies, Caltrans and the funding agencies.

§         C/CAG shall lead the procurement effort with assistance from other affected agencies.

§         Non-proprietary components are to be given priority over proprietary hardware components.

§         For hardware and software development and procurement, minimum or essential requirements that are not controlled by performance characteristics, interface requirements or referenced documents will be specified. They will include appropriate design standards, requirements governing the use or selection of materials, parts and processes, interchangeability requirements, safety requirements, and the like.

§         Special attention will be directed to prevent unnecessary use of materials that may impact the schedule or the implementation of the project.

§         The Specifications shall require the use of standard and commercial parts.

§         Where possible, hardware components are to be interchangeable and replaceable.

·        Implementation

§         The Contractor shall provide a deployment plan/schedule for review by Caltrans/ C/CAG / SMCTA. This deployment plan/schedule is to be updated at least monthly.

§         The Contractor is to provide 24 hours notice before entering a cabinet unless this is an emergency.

§         The Contractor shall integrate the system according to the approved System Integration Plan. This is to involve a building block approach.

§         Training on the system is to be provided before system acceptance testing.

§         The Contractor shall provide lead technical staff with at least 5 years of experience in the implementation of similar systems.

§         The Contractor shall provide a cutover plan for approval. This cutover plan shall provide for a near seamless transition from existing operations to the proposed system with minimal impact on operations.

§         If a new feature is added or desired to be added to the system and it is determined this feature has system-wide applicability, it should first be installed and tested in the existing system.

§         The Contractor is responsible for integration of designated legacy equipment and systems.

§         The Contractor is responsible for obtaining and complying with all permits.

·        Maintenance and Operations

§         Once the Contractor accesses a cabinet, he is then responsible for maintenance of that cabinet and associated equipment until system acceptance

§         New equipment provided by public agencies will be maintained by these public agencies to the extent these public agencies will be viewed as a manufacturer. The Contractor will be responsible for identifying malfunctions and replacement of equipment.

§         Spare equipment is to be stockpiled locally and provided in a timely manner.

§         Operation of equipment until system acceptance shall remain with the entity responsible before system implementation


6.9              Operations and Maintenance Plan

New equipment, the communications network and the system hardware and software provided by the Project and outside State Right of Way will be owned by the agency where it is located and maintained by C/CAG. Following system acceptance, C/CAG will be responsible for arranging for maintenance of this equipment, the communications network and system hardware and software.

Equipment provided by other public entities shall be owned and maintained by these entities following system acceptance. Modifications of this equipment will be owned by these entities and maintained by C/CAG.

The owner of the equipment shall be responsible for maintaining a suitable supply of spares that can be provided in a timely manner.

Maintenance shall be provided in accordance with the manufacturer’s recommendations.

Operations and maintenance shall be in accordance with the Deployment Plan.

A Memorandum of Understanding shall be signed between the various public entities on this Project that contains the requirements in this section.

The Contractor shall provide an operations and maintenance plan for all equipment, hardware and software he provides or modifies. This plan shall conform to the following:

·      The Operations and Maintenance (O&M) Plan for the project will be reviewed and approved by the stakeholders.

·      The O&M Plan shall clearly explain the methods that will be used to effectively operate and maintain the system in consistent with other contract document requirements.

·      This Plan will be followed after the warranty period.

·      The stakeholders will closely monitor the O&M effort to ensure that it is being performed correctly.

·      A system activity log will be kept, which will include system deficiency report, user feedback, and system repair record on all components, subsystems and the system as a whole.

·      Maintenance shall be carried out in a way that minimizes the interruption to normal system operations. Any maintenance activities that cause major interruption shall be discussed with and approved by the affected agencies prior to implementation.

·      All system support and maintenance activities shall be documented.

·      System documentation that is affected by maintenance and enhancement activities shall be periodically updated.

·      The O&M Plan shall include a user manual, a policy manual and a maintenance manual.

·      The O&M Plan shall include preventive maintenance as well as periodic maintenance.

·      Special hardware and software required to maintain the system, subsystems and the components shall be identified.

6.10          Training Plan

The Contractor shall submit a training plan for approval which meets the following requirements:

·        As equipment is installed and upgraded on this project, training in operation as well as maintenance and repair will be required. Wherever possible, this training should include hands-on experience, either in the field or in the TMC, and be provided by the equipment manufacturer or other qualified personnel.

·        Classroom training should be provided in the theory and design of various subsystems throughout the corridor.

·      An outline shall be provided for approval prior to scheduling training classes.

·      Training materials shall be provided for approval prior to initiation of training.

·      At least one location of each type of field equipment shall be in place prior to initiating training.

·      Training shall be oriented to the audience (ie. administrators, operators, maintenance personnel).

·      All training should include testing of the attendees at the end of each session to verify necessary knowledge and skill levels.

·      Written manuals should be provided as part of each training workshop.

·      As new functionality or hardware is added to the system, training on these new items shall be provided in a timely manner.

·      Training must be satisfactorily completed prior to assumption of maintenance responsibilities.

6.11          Configuration Management Plan

Configuration management applies to all aspects of system design, development, implementation, operation and maintenance.

Configuration control will be maintained by a change control board (CCB). The CCB will enforce rigorous control and tracking procedures of the system changes. The change control system will ensure that any change made to a system, subsystem or component will be analyzed before change implementation and changes must be tested before being incorporated.

The CCB shall consist of technical representatives from the stakeholders (Caltrans, C/CAG, SMCTA and the Contractor with non voting representation by the Consultant).

The general responsibilities of the change control board shall include, but are not limited to:

·        Establishment and maintenance of engineering baselines

·        Provision of configuration requirements and control

·        Configuration identification and assignment of version numbers

·        Participation in formal audits and reviews

·        Tracking the status of items under configuration management

·        Establishment of periodic milestones and configuration reviews (including periodic integration testing)

·        Approval and tracking of change requests and defect reports

The Contractor shall submit a configuration management plan for approval by Caltrans, C/CAG and SMCTA.

Configuration identification shall identify each critical component, including software unit, documentation, and other supporting information that is to be put under the configuration control. Any such component is termed a Configuration Item (CI). Configuration identification also consists of defining baselines and releases that are time-phased to the development schedules.

Each CI shall be assigned a unique identification. For example, a document may be assigned the number 1300 and the name System Review Procedures. The document will be referred to as Document #1300. Version control shall maintain individual versions of the CIs. The CI and version control shall be maintained in each document.

Major versions of the CI shall be recorded as a decimal extension to the CI unique number, as in Document #1300.01. Minor versions shall be indicated by a letter extension (Document #1300.01A). Temporary versions shall be indicated, where necessary, by a date (Document #1300.02C – 04/05/1999).

Major versions of CIs shall be established when the CIs are accepted by the CCB and enter a baseline. Minor versions of CIs shall be established as necessary to indicate a new level of available functionality or information. Temporary versions shall be used by individual development teams where desired.

Change control (CC) is intended to assure a disciplined process for handling problems and changes of CIs. Any change to any CI under CCB control shall go through change control. Change control starts from a change request originated by a change request originator, who can be the developer, user, Independent V&V tester, or one of the stakeholders. This request shall include the description of the problem (if any), the proposed change, and the impact of the change (both cost and benefit) from the point of view of the party proposing the change. If deemed necessary, the CCB shall identify parties that might be affected by the change and distribute the change request for their review. CCB members will then combine their assessments and prioritize the change request. The CCB may decide to accept, reject, or defer the change request. If a change request is accepted, the change tasks will be allocated. The CCB shall notify all concerned parties about its decision. The originator shall document this request in a CI Change Request Form (CRF) and submit this request to the CCB. The CCB shall sign it to indicate its decision. If a change request is approved, the change implementers shall implement the change proposed in the CRF. The implementation of changes shall follow the regular CI development procedures. Successful testing must be conducted before the CI is released to the CCB to be put under CCB control.

A change request tracking tool shall be evaluated and selected prior to the Initial Build. This tool will be used by the development team to track the status of each CI change.

·        Establishment and maintenance of engineering baselines

·        Provision of configuration requirements and control

·        Configuration identification and assignment of version numbers

·        Participation in formal audits and reviews

·        Track the status of items under configuration management

·        Establishment of periodic milestones and configuration reviews (including periodic integration testing)

Each version or stage will consist of the following:

·        A description of the functionality to be met by each of the subsystems for this version/baseline (i.e., the development goals for the baseline)

·        A definition of specific configuration items (CIs) within each subsystem whose configurations will be tracked according to the requirements of the System Development Plan (SDP)

·        A description of the integrated functionality to be accomplished during baseline integration

·        A series of test cases and functionality assertions which must be met by each CI and each subsystem before the baseline integration begins

·        A series of test cases and functionality assertions which must be met by the integrated baseline

·        A development schedule for each CI and subsystem

·        A development schedule for baseline integration

6.12          Risk Management Plan

Potential project risks and the associated mitigation measures are identified in the following table.

Table 8 – Potential Project Risks and Proposed Mitigation

Potential Project Risk

Proposed Mitigation

Funding will not be available when needed

C/CAG and SMCTA to closely monitor

Custom software development will delay the project or require additional funding

The project specifications are to maximize use of off the shelf components. This will be done by thoroughly reviewing the potential applicable systems.

Unexpected field problems such as damaged conduits

Maintain a contingency fund

Use of legacy equipment could increase the cost or delay the project

Perform a trade-off analysis during the design phase of the impact of using specific legacy equipment

Use of legacy systems could increase the cost or delay the project

During the design phase, identify the alternative with least risk

Unavailability of staff

Commit staff to this project

Unavailability of public agency supplied equipment including spares

Stockpile needed equipment prior to implementation

Impact of other construction activities

Inform owners of equipment/facilities in the right of way of this project

Delays in reviewing contractor submissions

Commit to the approved schedule

Standardized equipment incompatible

Be prepared to replace with compatible equipment

Communications issues

Resolve as they occur

Customized hardware

Minimize or eliminate the need for customized hardware


6.13          System Procurement Plan

See Deployment Plan.


6.14          System Development Plan

The Contractor shall provide a deployment plan for approval by C/CAG, Caltrans and the SMCTA. The plan shall meet the requirements in this section.

To ensure that all system development activities are conducted in an organized way, the planning process is carried out throughout the entire system development life cycle. The planning encompasses the system requirements analysis, system design, system implementation, system testing and system transition. System development planning is a dynamic process and is periodically modified based on the feedback from the execution of the planned activities.

Configuration management will be exercised to ensure that the system construction follows an incremental approach. This will be documented in a configuration management plan.

Reviews both internal and/or external will be conducted for all system development products (ie. plans, specifications, estimates, hardware, software). Internal reviews will be conducted within Caltrans and the affected stakeholders independently. The external reviews will involve Caltrans and other stakeholders as a team. Reviews will be performed on both deliverables and intermediate products. These reviews include various documents and memos, system designs, test designs, and software codes.

A series of systematic tests will be performed at various stages of the system development to ensure the developed system performs as expected. These tests include subsystem testing, incremental integration testing, internal system testing, and system verification and validation (V&V) testing. Among other testing techniques, regression testing and stress testing will be used whenever applicable. For baseline testing, subsystem testing and incremental integration testing, the contractor will be responsible to perform the tests, but the test design will be reviewed and the testing will be witnessed by CCB or designated representatives. To ensure independence of the system V&V testing, an independent system Verification and Validation Group (V&VG) will be established to perform the testing. Members of the V&VG are not the designers or operators who are responsible for the implementation.

The system team (the contractor, the stakeholders, Caltrans and other consultants) will document in detail the system design and implementation, and maintain consistency between components, subsystems and system and documents.

In addition, all system design and implementation shall conform to the Quality Assurance Plan.

The subsystem implementation will be performed incrementally. Various incremental internal baselines will be defined. A set of activities such as coding, documentation, integration, and testing will be performed for each baseline until the final baseline.

As part of an incremental development cycle, the smallest and most meaningful part of the system shall be implemented first and established as a baseline. Then iterative improvements to that baseline shall be performed which shall result in the complete system. This approach, also called iterative prototyping, helps insure coordination among parts of the system.

Where possible, the selection for implementation emphasis shall be on those modules determined to be of higher technical risk. The team (contractor, stakeholders, Caltrans and consultants) shall perform a risk analysis during the design phase to determine risk factors of the various components of the design.

As part of an iterative development strategy, it is understood that as system construction proceeds, changes appropriate to the analysis and design stages may become apparent. As changes to system architecture and design are indicated through the iterative development and implementation process, the team shall modify the appropriate analysis and design documentation to reflect the change. For each such change, an analysis of the results of that change on the other components of the system shall be performed.

Prior to the system cut-over or the initial baseline implementation, user training will be conducted to ensure that the operators and maintenance personnel are capable of operating and maintaining the system.

The final release of the system will be transferred to Caltrans and the stakeholders at the end of the Contract.

6.15          Quality Management Plan

While each agency associated with this Project is responsible for following their own in-house quality management plan, the Contractor shall develop a project-wide Quality Management Plan conforming to the requirements of this section.

This SEMP defines the interdisciplinary tasks required throughout a system’s life cycle to transform stakeholder needs, requirements, and constraints into an intelligent transportation system (ITS) solution. Quality management (QM) is a critical element of the back-end phase of a systems engineering process (SEP). The QM element is essential to the verification and validation process of all system requirements identified in the front-end systems engineering phase.

This section provides guidance for the Contractor to implement quality system planning to support the establishment of a QM system. A QM system consists of quality assurance (QA) and quality control (QC) processes during the life cycle of ITS programs, projects, or products.

A reference to QM includes the overall management functions that determine and implement quality policy. Through an effective QA program, QM establishes a uniform management policy and implements an effective configuration control program. Therefore, the processes presented in a QM document are based on both QM and configuration management (CM) processes, and are tailored to meet the guidelines and recommendations in the ANSI/EIA-649 standard, the ISO 10007 configuration management guidelines, and the IS0 9000 family of international QM standards.

The organizational structures, responsibilities, procedures, processes, and resources for implementing a QM system should only be as comprehensive as needed to meet the quality objectives and contractual purposes. The QM system is the overall management of the collective body of processes, operating procedures, objectives, responsibilities, resources, and infrastructure to implement an effective quality policy. To be successful, it requires the commitment and participation of all stakeholders, including the full commitment and responsibility of top management.

The first step for the Contractor in setting up a QM system is to generate a “quality manual.” This should be done before any quality procedures or specifications are written. The quality manual is a document that states in a concise format the organization’s high-level policies and objectives that are required to achieve the desired level of quality compliance. It should also show how the organization’s overall documentation of specifications is structured.

Each ISO quality section or element the quality manual addresses should be written with a minimum of the following three sections:

·        A Scope section that simply states the purpose of the covered area

·        A Policy section that states company policy regarding the applicable ISO clause

·        A Responsibility section that states who is responsible for the policy using generic titles or positions

Achieving quality and maintaining it requires funds, referred to as the cost of quality, so the quality system should not exceed what is needed to meet the desired quality objectives. A quality system should encompass not only the quality of the finished product, but also the quality of operational processes as well. It is therefore essential to clearly document the desired quality objectives, and the processes by which these objectives will be achieved. The essence of these quality objectives is the “quality standard,” and it is up to the quality system to ensure that the documented procedures, actual operation, and quality records all conform to this standard.

The implementation of a successful QM program includes the identification of responsibilities and authority related to the implementation and verification of the QM process. It is important for the individual with overall responsibility for the system to develop a project organization and assign QA/QC responsibilities to key personnel.

Typically, the QA Engineer has been delegated the overall operational authority to implement the project QA program in accordance with project requirements. The QA Engineer or his/her designee has responsibility for delivering a system that meets quality expectations. Specific responsibilities include:

·        Determining quality objectives

·        Assigning quality objectives to subordinate system stakeholders

·        Developing the QA plan

·        Periodically reviewing project performance against quality objectives

·        Developing remediation plans when quality performance is not in line with objectives

Once the quality system plan has been completed, the quality system must undergo full documentation that reflects the complexity of the implementation process, the manpower skills required for production, and the training requirements needed to achieve these manpower skills. At a minimum, quality system documentation should include the organization’s quality manual and specifications showing the processes, work instructions in support of these processes, and production/quality records required by these work instructions.

The following table provides a matrix for checking the viability of a quality management plan.

Table 9 – Quality Assurance Matrix




Are project tracking activities evident?



Are project tracking and oversight being conducted?



Are all plan reviews conducted according to plan checklists?



Are all issues arising from peer reviews addressed and closed?



Are status and review meetings conducted according to the schedule?



Has a contract work breakdown structure that supports all deliverables and the long-term projects been developed?



Are changes managed according to the configuration management plan?



Have all deviations from standards and procedures documentation been approved?



Are project roles and responsibilities defined?






6.16          Documentation

Project documentation control includes the processes to ensure that the Project is administered in conformance with the contract requirements. A solid and efficient document control system to administer Project records will ensure that the work is constructed in accordance with the contract requirements.

Documents shall be developed that describe the responsibilities and requirements for the identification, preparation, and maintenance of records that furnish documentary evidence of the process undertaken, the design of the system, the implementation of the system, and the operation and maintenance of the system. The term "records" used throughout this section refers to records attesting to the achievement of the requirements that are generated during the various phases of this project.

Records will be legible, identifiable, and retrievable. These records will be protected against damage, deterioration, or loss. Requirements and responsibilities for record transmittal, distribution, retention, maintenance, disposition, and organizational responsibilities will be identified. A record is defined as a completed document that furnishes evidence of the quality of items and/or activities affecting quality. A records retention and distribution system will be established by C/CAG and Caltrans. The scope of the records retention and distribution system will be described in instructions and procedures.

Records will be indexed. The indexing system will include, as a minimum, record retention times and the location of the record within the record system. The records and/or indexing system will provide sufficient information to permit prompt retrieval, and identification between the record and the items or activities to which it applies.

Corrections to records will be controlled. Controls will provide for appropriate review or approval by the originating organization. All corrections will include the date and the identification of the person authorized to issue the correction.

Previously developed records shall be updated when major changes are made and accepted in related documentation

Records shall be subject to configuration management.

Original records shall be numbered as follows:

·        Systems Engineering Management Plan (10000 series) (developed under the current contract)

·        Functional Requirements (12000 series) (developed under the current contract)

·        High-Level Requirements (13000 series) (developed under the current contract)

·        Detailed Design Requirements Document (13500 series) (developed under the current contract)

·        Interface Control Requirements (14000 series) (developed under the current contract)

·        Configuration Management Plan (15000 series) (to be developed by the Contractor)

·        Risk Management Plan (16000 series) (part of SEMP)

·        System Procurement Plan (17000 series) (part of SEMP)

·        System Development Plan (18000 series) (to be developed by the Contractor)

·        Quality Management Plan (19000 series) (to be developed by the Contractor)

·        Design Documents including PS&E (numbered per agency requirements) (to be developed by Caltrans or its designate)

·        System Integration Plan (20000 series) (to be developed by the Contractor)

·        Verification Plan (21000 series) (to be developed by Caltrans or its designate)

·        Deployment Plan (22000 series) (part of SEMP)

·        Test Plans (23000 series) (to be developed by Caltrans or its designate)

·        Detailed Design Requirements Test Plan (23000.004) (developed under the current contract)

·        Operations and Maintenance Plan (24000 series) (to be developed by Contractor)

·        Training Plan (25000 series) (to be developed by Contractor)


6.17          Systems Engineering Management Plan

The Systems Engineering Management Plan (SEMP) will include the following:

·        The technical challenges facing the Project (to be provided by Caltrans and C/CAG)

·        The identification and involvement of stakeholders (to be provided by Caltrans and C/CAG)

·        The required technical staff and development teams (to be provided by Caltrans and C/CAG)

·        The roles of all involved parties (to be provided by Caltrans and C/CAG)

·        The interfaces between the various parties (to be provided by Caltrans and C/CAG)

·        The expected result/products of this Project and how related activities will be controlled (to be provided by Caltrans and C/CAG)

·        The work breakdown structure/overall project schedule (to be provided by Caltrans and C/CAG)

·        Procurement plan

·        Guidelines for system development plan

·        Guidelines for interface control plan

·        Guidelines for a system integration plan

·        Guidelines for a verification plan (including test environment, input source/output, method of test and guidelines for establishing use cases)

·        Guidelines for a detailed design requirements test plan

·        Guidelines for a training plan

·        Guidelines for a configuration management plan

·        Risk management plan (to be provided by Caltrans and C/CAG. Effort being led by Caltrans.)

·        Methodology for tracing requirements from the Concept of Operations (ConOps) to the final implementation

·        Methodology for identifying and selecting critical technologies

6.18          Requirements Documentation

The functional requirements will be based on:

·        San Mateo County Arterial Route for Traffic Incident Guide, February 2009

·        The San Mateo County Smart Corridors Program Concept of Operations, October 2008

·        Multiple traffic signal systems along El Camino Real and other proposed alternate routes

·        Inclusion of cameras, trail blazer signs and vehicle detection systems along El Camino Real and other proposed alternate routes

·        Signal control hierarchy/strategies for remote signal timing and control (signal operational strategies will be provided by Caltrans)

·        Termination of the Smart Corridor communications backbone at the Millbrae BART station

·        Identification of the functionality of the proposed systems (communications, traffic signal systems, CCTV, trail blazer and vehicle detection)

·        Identification of the functionality desired between the existing Caltrans ATMS and the proposed systems

·        The functional requirements will be technical in nature and not operational or institutional.

·        The functional requirements shall be traced to the ConOps where possible

·        The functional requirements will be further detailed in future documents

·        Each requirement will have a method of verification

·        Constraints resulting from technology, standards or policies


The high-level requirements will be based on the following:

·        Functional requirements developed previously

·        System requirements will be of the following types:

-        Functional in nature (what the system shall do)

-        Performance (how well the system and its components will perform)

-        Interface (definition of the interfaces to other systems or components or users)

-        Data (data elements)

-        Non functional (safety, reliability, environmental)

-        Enabling requirements (production, development, testing, training, support, deployment, etc.)

-        Constraints imposed


The detailed design requirements will be based on the following;

·        High level requirements previously developed

·        Identification of the system architecture and its associated subsystems (this will include notation of its integration with the Regional Architecture)

·        Identification of the logical architecture

·        Further definition of the data, performance measures and interface requirements

·        Tracing the detailed design requirements to the high level requirements to the functional requirements and the ConOps

·        Evaluation of alternative communication systems along El Camino Real and other proposed alternate routes (this effort will involve investigation of alternative protocols, alternative physical interfaces, alternative recommended equipment and the use of interim communication technologies if needed)

7.0            Transitioning Critical Technologies

Critical technologies are those technologies which prevent the system from meeting its goals/objectives and providing the functionality required. There are no backups to critical technologies. With this definition, all technologies in the proposed system are critical.

Appendix 1



















Program Schedule with WBS

Project Schedule

Page 1 of the Smart Corridor Schedule shows the V-Diagram and Routes and Equipment Layout tasks.
Page 2 of the Smart Corridor Schedule shows the Project Report and Environmental Document, Local Roads Phase 1 and 2 Design Contracts, and Local Roads Phase 1 and 2 Design tasks.

Page 3 of the Smart Corridor Schedule shows the remainder of the  Local Roads Phase 1 and 2 Design and Local Roads Construction tasks.

Page 4 of the Smart Corridor Schedule shows the Caltrans Portion and the Equipment Procurement tasks.

Project Schedule for San Mateo County SMART Corridor ProjectProject Schedule




Appendix 2

Glossary and Abbreviations



Architecture – A framework within which a system can be built. Architecture functionally defines the pieces of the system and the information that is exchanged between them.

ARTI -  Alternate Route for Traffic Incident Guide that identifies arterial streets that would best serve as alternate routes during incidents (has been superceded)

Broadband – higher data transfer rate (> T-1, typically 10Mbps or higher) and/or broader bandwidth of frequencies.

Configuration Management – A process developed to control change in complex information technology based systems.

Concept of Operations – The stakeholders’ vision of how the system will operate in actual practice (standard operating procedure). The concept of operation is a document that defines, in sequence, how the subsystems and institutions will operate with each other for each incident or situation. It identifies and defines the roles and responsibilities of the systems and subsystems of each agency, and the physical environment. It is very useful as a starting point for the development of an ITS project. The concept of operations is frequently drawn up as a flow diagram.

Data Flows – They represent data flowing between processes or between processes and a terminator. A data flow is shown as an arrow on a data flow diagram and is defined in a data dictionary entry. Data flows are aggregated together to form high-level architecture flows in the physical architecture view of the NA. See Data Flow diagram.

Dedicated Short Range Communications (DSRC) – A wireless communications channel used for close-proximity communications between vehicles and the immediate infrastructure. It supports location-specific communications for ITS services such as toll collection, transit vehicle management, driver information, and automated commercial vehicle operations.

Deployment – An act of placing strategically.

Element – The basic building block of an ITS architecture. The name used by stakeholders to describe a system or piece of a system.

Ethernet Bandwidth – Refers to 10Mbps (Ethernet), 100Mbps (Fast Ethernet), 1000Mbps (Gigabit Ethernet). The actual bandwidth will depend on the type of interface you have (i.e., your 10Mbps Ethernet may be connected to another network type, say a DSL network, that may limit your effective bandwidth). Hence, the actual effective bandwidth may be less than the stated bandwidth.

Federal Highway Administration (FHWA) – An agency of the USDoT that funds and regulates highway projects.

Federal Transit Administration (FTA) – An agency of the USDoT that funds and regulates transit projects.

Functional Requirements – What a system must do to address the needs or provide the services that have been identified for the region. In a regional ITS architecture, the functional requirements focus on the high-level requirements for providing desired service to the user.

Information Flow – Information that is exchanged between subsystems. The terms “information flow” and “architecture flow” are used interchangeably.

Infrastructure – The underlying foundation or basic framework of a system or an organization.

Institutional Integration – Represents the process of combining existing and emerging institutional constraints and arrangements.

Integrate – To incorporate into a larger system. Includes combining, interconnecting, or interfacing different systems and jurisdictions.

Intelligent Transportation System (ITS) – Electronics, communications, or information processing used singly or in combination to improve the efficiency or safety of a transportation system.

Interchangeability – The capability to exchange devices of the same type from any vendor without changing the software.

Interconnect – Communication paths that carry information between subsystems. Also applies to traffic signal interconnect.

Interface – The place at which independent systems meet and act on or communicate with each other. The means by which interaction or communication is effected.

Interoperability – The capability to operate devices from different manufacturers or different device types (e.g., signal controllers and dynamic message signs on the same communication channel).

ITS Architecture – Defines how systems functionally operate and the interconnection of information exchanges that must take place between these systems to accomplish transportation services.

Legacy System – Existing transportation systems, communication systems or institutional systems.

Life cycle – Denotes the strategic cycle or sequencing of a specific process.

Narrowband – Lower data transfer rate (typically < T-1) and/or lower bandwidth of frequencies

National ITS Architecture (NA) – A common established national framework for ITS interconnectivity and interoperability.

Operational Concept – Describes how the system will work by identifying in sequence the roles and responsibilities of participating agencies and stakeholders for a given scenario(s).

Project ITS Architecture (PIA) – A framework that identifies the institutional agreement and technical integration necessary to define an ITS project and its interface with other ITS projects and systems.

Project Sequencing – The order in which projects are deployed. An efficient sequencing can allow projects to incrementally build on each other.

Protocol Communications – A set of rules for how messages are coded and transmitted between electronic devices. The equipment at each end of a data transmission must use the same protocol to successfully communicate. It is like human language that has an alphabet, vocabulary, and grammar rules used by everyone who speaks that language.

Region – The geographical area that identifies the boundaries of the regional architecture based on the needs of the participating agencies and stakeholders. In metropolitan areas, a region should be no less than the boundaries of the metropolitan planning area. In the case of this project, the region is the 9-county San Francisco Bay Area.

Regional ITS Architecture (RA) – A regional or state level framework for ensuring institutional agreement and technical integration for the implementation of ITS projects or groups of projects. It defines what pieces of the system are linked to others and what information is exchanged between them.

Requirements Definitions – A total set of considerations that govern what is to be accomplished, how well and under what conditions. Associated with system requirements.

San Mateo County Hub  – The communication hub within the City of San Mateo that concentrates the communications network in the immediate area. This is also the location of a workstation that can serve as a backup to the Caltrans D4 TMC that operates the San Mateo Smart Corridor

Stakeholders – Anyone with a vested interest or “stake” in the regional ITS architecture. This includes public agencies, private organizations, special interest groups and traveling public.

Standards – Established and documented technical specifications sponsored by a Standards Development Organization (SDO) to be used consistently by industries or government for interoperability, compatibility, interconnect ability, interchangeability and expandability.

Systems Engineering Analysis – Is a structured process for arriving at a final design of a system. The final design is selected from a number of alternatives that would accomplish the same objectives and considers the total life-cycle of the project including not only the technical merits of potential solutions but also the costs and relative value of alternatives.

Uptime – Defined/measured as the percent of time a system or a subsystem is operational and providing the functionality in accordance with the performance requirements for availability.

User – Typically an operator, typically in a traffic management center.

Vehicle-to-Vehicle Communications – Dedicated wireless system handling high data rate, low probability of error, line-of-sight communications between vehicles. Advanced vehicle services may use this link in the future to support advanced collision avoidance implementations, road condition information sharing, and active coordination to advanced control systems.

Wide-Area Wireless communications – A communications link that provides communications via a wireless device between the user and an infrastructure based system. These links support a range of services including real time traveler information and various forms of fleet communications.

Wireline Communications – A communications link serving fixed locations. It uses a variety of public or private communications networks that may physically include wireless (e.g. microwave) as well as wireline infrastructure.

Work Breakdown Structure – A product oriented listing, in family tree order, of the hardware, software, services and other work tasks, which completely defines a product or program. The listing results form project engineering during the development and production of a material item. A WBS relates the elements of work to be accomplished to each other and to the end product.


AASHTO        American Association of State Highway and Transportation Officials

ADMS            Arterial Dynamic Message Sign

ANSI               American National Standards Institute

ASTM             American Society for Testing and Materials

ARTI              Alternate Routes for Traffic Incident (Guide)

ATMS             Advanced Transportation Management System

AVI                 Automated Vehicle Identification

AVL                Automated Vehicle Location

BRT                Bus Rapid Transit

C2C                 Center to Center

C2F                 Center to Field

C/CAG            City/County Association of Governments of San Mateo County

CCTV             Closed Circuit Television Camera

CD                  Compact Disk

CDMA            Code Division Multiple Access

CDPD             Cellular Digital Packet Data

CD-ROM       CD Read-only Memory

CHP                California Highway Patrol

CMA               Congestion Management Agency

CMS               Changeable Message Sign

COTS              Commercial off-the-Shelf

CVO                Commercial Vehicle Operations

D4TMC          Caltrans District 4 Transportation Management Center

DAB                Digital Audio Broadcast

DEN                Data Exchange Network Display System

DGPS              Differential Global Positioning System

DMS               Dynamic Message Sign

DMV              Department of Motor Vehicles

DOC               Department Operations Center

DSRC             Dedicated Short Range Communications

DTA                Dynamic Traffic Assignment

911                  Emergency 9-1-1

ECPA              Electronic Communications Privacy Act

EDI                 Electronic Data Interchange

EMS               Emergency Medical Services

EOC                Emergency Operations Center

ESMR            Enhanced Specialized Mobile Radio

ETA                Expected Time of Arrival

ETS                 Emergency Telephone Services

EVP                 Emergency Vehicle Preemption

FCC                Federal Communications Commission

FHWA            Federal Highway Administration

FMCSA          Federal Motor Carrier Safety Administration

FTA                 Federal Transit Administration

GIS                 Geographic Information System

GPS                 Global Positioning System

GUI                 Graphical User Interface

HAR               Highway Advisory Radio

HAZMAT       Hazardous Material

HOV               High-Occupancy Vehicle

HUD               Heads-Up Display

IEEE               Institute of Electrical and Electronics Engineers, Inc.

IEN                 Information Exchange Network

IP                    Internet Protocol

ISO                 International Standards Organization

ITE                  Institute of Transportation Engineers

ITN                 Integrated Transportation Network

ITS                  Intelligent Transportation Systems

LAN                Local Area Network

LCD                Liquid Crystal Display

LED                Light Emitting Diode

LEO                Low-Earth Orbit Satellite System

LRMS            Location Reference Messaging Standard

LRT                Light Rail Transit

MOE               Measure of Effectiveness

MPO               Metropolitan Planning Organization

MSC               Municipal Service Center

MTC               Metropolitan Transportation Commission

NEMA            National Electrical Manufacturers Association

NHTSA           National Highway Traffic Safety Administration

NTCIP            National Transportation Communications for ITS Protocol

O&M              Operations and Maintenance

OEM               Original Equipment Manufacturer

OSI                 Open Systems Interconnection

PAB                Police Administration Building

PC                   Personal Computer

PCS                 Personal Communications System

PDA                Personal Digital Assistant

PS&E              Plans, Specifications and Estimates

PSTN              Public Switched Telephone Network

PR                   Project Report

PSR                 Project Study Report

PWA               Public Works Agency

R & D             Research and Development

RDS                Radio Data Systems

RDSTMC       RDS incorporating a Traffic Message Channel

RFP                 Request for Proposal

SAE                 Society of Automotive Engineers

SDO                Standards Development Organization

SE                   Systems Engineering

SEMP             Systems Engineering Management Plan

SFO                 San Francisco International Airport

SMCTA          San Mateo County Transportation Authority

SMCHub        San Mateo County Hub

SMR               Specialized Mobile Radio

SNMP             Simple Network Management Protocol

SONET           Synchronous Optical Network

STIP                State Transportation Improvement Program

STMF             Simple Transportation Management Framework

STMP             Simple Transportation Management Protocol

SQL                Standard Query Language

SSR                 Spread Spectrum Radio

TCIP               Transit Communications Interface Profiles

TDMA            Time Division Multiple Access

TIMC             Traffic Incident Management Committee

TMC               Traffic Management Center

TOC                Traffic Operations Center

USDOT           United States Department of Transportation

WAN               Wide Area Network

WIM               Weigh-in-Motion

WWW             World Wide Web