SE Example - San Mateo County Smart Corridors Systems Engineering Management Plan (2024)

The City/County Association of Governments of San MateoCounty (C/CAG) and the San Mateo County Transportation Authority (SMCTA) inconjunction with the California Department of Transportation (Caltrans) hasinitiated an effort to address the operation of the freeway and arterial roadwaynetwork in San Mateo County. The San Mateo County Smart Corridor Program isintended to benefit a variety of users including commuters, local traffic, andcommercial vehicle and transit operators.

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

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

The mitigationof the impacts of non-recurring traffic congestion on local streets within SanMateo County during major freeway incidents on US-101 was identified as ahigh-priority project in the Smart Corridor Program. A Project Report (PR) waswritten that proposes the deployment of integrated Intelligent TransportationSystem (ITS) elements to provide local agencies and Caltrans the tools tomanage this congestion. The project includes the installation of the followingITS elements:

·Directional signs (trailblazer and turn prohibition) to directtraffic;

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

·Communications to provide interconnect between local agencytraffic signals on local streets and State operated traffic signals on Stateroutes;

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

·Arterial changeable message signs to inform motorists of trafficconditions (also referred to as Arterial Dynamic Message Signs in thisdocument);

·Center-to-center communications between the proposed San MateoCounty Hub (SMCHub) and the Caltrans District 4 Transportation ManagementCenter (D4TMC) (note where TMC is used in a general manner in this document, itrefers 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-blocklocations.

Many of thesesame elements can also be used to manage traffic along the corridor duringrecurrent congestion. In addition to the ITS elements noted above, thefollowing ITS elements were identified for possible deployment on futureprojects:

·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 theAlternate Routes for Traffic Incident (ARTI) Guide (April 2008) to identifyarterial streets that would best serve as alternative routes for moving trafficduring incidents on US-101 and minimizing the impacts of diverted traffic onthe local street network across multi-jurisdictional boundaries. During a majorfreeway incident on US-101, Caltrans operators at the D4 TMC will implementsignal timing plans and activate trailblazer signs along the appropriate ARTIroute(s) and notify the local agencies that the management of the alternateroute(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 beimplemented to manage traffic that has exited the freeway during incidents. Theproject is estimated to cost $30.71 million, with $22.37 million inconstruction 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 October2008 and updated in September 2009, with input from local agencies andCaltrans, and direction from the Federal Highway Administration (FHWA). Thisis 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.1Relevant Documents

Relevant documentsinclude:

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

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

·Draft Project Report in San Mateo County on US-101 and SR-82 fromI-380 to the Santa Clara County Line, San Mateo County Smart Corridors, EA4A9200, October 2008

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

·San Mateo County Smart Corridors Projects Traffic LightSynchronization 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 CorridorsProgram, version 12000.007, September 2009

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

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

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

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

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 theproject

The goals ofthe project identified in the Concept of Operations have been modified as shownin Table 1.

Table 1 – Project Goals

4.1Project Phasing

The complete deployment of the Smart Corridor programincludes the freeway network and parallel arterials of regional significance inSan Mateo County. The deployment will be completed in phases, with eachsubsequent phase building upon the elements of previous phases.

Figure 1 – Smart Corridor ProjectPhasing

As shown in Figure 1, there are three primaryphases currently planned for the Smart Corridors program with full buildoutincluding additional future phases when funding becomes available and policydictates. 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.2Stakeholder Roles

The stakeholders and their roles in this project arelisted in Table 2.

Table 2 – Project Stakeholdersand Current and Proposed Roles

The ARTI provides the stakeholders a guideline/processfor implementing route guidance and operational strategies to manage divertedtraffic 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 offthe freeway due to a major incident on US-101 or other freeway;

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

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

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

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

Through installation of ITS equipment along the alternateroutes, the stakeholders will have tools and strategies that will enable themto do the following:

·Change route guidance signs to guide incident traffic along aspecific alternate route to avoid a situation where drivers seek unknownroutes;

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

·Monitor traffic on local streets;

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

·Coordinate operations between Caltrans and local agencies duringmajor incidents.

Caltrans will be required to commit to active operationand control of the Smart Corridor tools by the D4TMC operators with supportfrom local agencies. Active operation during major freeway incidents willinclude implementing alternate route signage and monitoring CCTV camera imagesto optimize the flow of traffic along alternate routes. If necessary, it willalso require adjusting alternate routes device parameters in response tochanging conditions. The system will also require communication andcoordination between agencies, adjustment of signal timing, notifications totravelers, and other operational strategies implementation along the affectedportion of the corridor in an event of major freeway incident.

The segment of US-101 within the County of San Mateo ispart of the National Highway System, classified as a strategic highway network routeto provide defense access, continuity, and emergency capability fortransporting personnel, materials, and equipments during both peace and wartimes.

4.3Technical 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 localroadways

·Providing aesthetically pleasing equipment in an urban setting

·Potential use of a hybrid communications system

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

·Future integration of the local systems into the Caltrans ATMS

5.1System Engineering Planning Process

The systems engineering planning process is aninterdisciplinary approach that helps to enable the realization of successfulsystems. It focuses on defining customer needs and required functionality earlyin the development cycle, documenting requirements and proceeding with designsynthesis and system validation while considering the complete problem:

·Operations

·Performance

·Test

·Manufacturing

·Cost & Schedule

·Training and Support

·Disposal

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

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

FHWA Federal Rule 940, Intelligent Transportation SystemsArchitecture and Standards, which implements Section 5206 (e) of theTransportation Equity Act of the 21^st Century (TEA – 21), requiresagencies implementing projects with ITS elements utilizing federal funds todevelop regional architectures and adopt a SE approach for project deploymentsin order to qualify for ITS grants.

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

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

Table 3 – Systems Engineeringand Rule 940

The systems engineering process shall follow theguidelines in the “System Engineering Guidebook for ITS”, version 2.0 datedJanuary 2, 2007 published by the Federal Highway Administration/CaliforniaDivision 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 involvesconcept exploration and identification of regional architecture requirements. Thenext phase includes developing a SEMP (this document) and a Concept of Operationsfor the proposed system. Once those are completed, the system requirements(both functional and performance) are able to be determined, and a matrix isdeveloped that ties all requirements to their origin in the Concept ofOperations document. This matrix will later be used as a System Verificationplan. This is followed by high-level design, which develops requirements forsubsystems and begins to detail the architecture of the system. The next phaseis detailed design, which draws from all the previous documents to identifyeach piece of the system and produce plans for construction. During all stagesof construction and installation, the process is used to test, validate, andaccept systems and subsystems to ensure that the final product will meet orexceed the expectations written out during the planning and design phases.

Figure 2 – System “V” Diagram

At each stage of the above noted figure, applicabledocuments will be developed. A typical project would include but not be limitedto 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 specificdocuments 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 requirementsdefined should be based on the ConOps developed previously. When consideredagainst the requirements of Federal Rule 940, this step of the processrelates to the requirements definition aspect of the systems engineeringanalysis.

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

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

5.2Regional System Architecture

The proposed system shall be compatible with the Bay AreaRegional Architecture.

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

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

5.3Standards

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

Equipment compatibility will be confirmed in severalways:

·Specifying the required compatibility with the D4 TMC

·Specifying equipment that is either similar or identical to thatwhich 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 befollowed in the design, implementation, testing, operation and maintenance ofthe proposed system.

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

Table 5 – Device Interfaces andStandards

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

6.1WBS Structure

A Work Breakdown Structure (WBS) is a hierarchicalstructure 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 canbe elsewhere)

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

·The roles and responsibilities of those parties involved in thetask

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

The WBS structure and overall project schedule are shownin Appendix 1.

6.2Task Deliverables

The systems engineering process as applied to the currentproject 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 asproject progresses)

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

All documents will be first circulated as a draft.

Written comments will be requested within one week ofsubmission.

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

Documents will be circulated to appropriate parties andagencies as necessary to ensure that a complete and timely review has beenperformed.

6.3Schedule

A copy of the Smart Corridors System Engineering ServicesProject Schedule is included in Appendix 1. The systems engineering processwill be applied throughout the entire project, and a table of key projectmilestones is shown below.

Table 7 – Project ScheduleMilestones (Systems Engineering Only)

The work breakdown structure shown in Appendix 1 will beused to track project progress. This schedule will be maintained and updated byCaltrans and C/CAG. As the systems engineering process creates additionalinputs, the schedule will be revised.

6.4Interface Control Plan Guidelines

Interfaces are the relationships among system componentsin which the components share, provide, or exchange data. Interface designshall include both interfaces among major components and their interfaces withexternal entities such as regional hubs, subsystems, operators, and generalpublic users.

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

The identification shall also state which entities havefixed interface characteristics (and therefore impose interface requirements oninterfacing entities) and which are being developed or modified (thus havinginterface requirements imposed on them).

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

For each interface, the description shall include, asapplicable, the following with more details in the Interface Control Planprovided 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 interfacingentities 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 interfacingentities will use for the interface

·Characteristics of protocols that the interfacing entities will usefor the interface

·Other characteristics, such as physical compatibility of theinterfacing entities (dimensions, tolerance, loads, voltages, plugcompatibility, etc.)

An interface control requirements document will bedeveloped. This document will recommend:

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

·Both the hardware and software interface standards to befollowed. 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, trailblazersigns, vehicle detection systems and other traffic control systems (i.e. thoseassociated with the Smart Corridor-other cities and Caltrans ATMS)

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

6.5Technical Review Plan

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

All comments received are to be tracked. If, during thereview process, conflicting comments are made by various parties, the documentoriginator will attempt to resolve them by working with each commenterindividually. If this process does not take place reasonably quickly, or asolution does not appear to be simple and straightforward, then a meeting willbe scheduled between all affected parties with the purpose of resolving theconflict.

During system implementation a formal review process willbe 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 withresolution first being attempted by technical staff. If that is not successful,the item in question is to be directed to a steering committee composed ofsenior stakeholders.

6.6System Integration Plan

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

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

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

·Equipment and software quality and reliability is enhanced

·Management visibility into the equipment development and softwarecoordination is improved

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

·Project risk, cost and schedule are reduced

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

System integration will involve the use of a buildingblock approach starting with elements combined into components which are thencombined into subsystems and thence into a system. At each stage, testing willoccur.

Testing Methodology-Allsystem configuration items will undergo and successfully pass appropriatetesting before it is released. Testing will include subsystem testing andintegration testing. Pre-installation testing relates to tests of all materialand equipment in a test environment prior to delivery to the Project Site. Equipmentthat is provided by Caltrans will undergo pre-installation testing/benchtesting by Caltrans.

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

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

Testing will be documented at all stages withpass/fail/comments.

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

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

Failures will be classified as major or minor.

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

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

Testing equipment to be utilized will includeoscilloscopes, OTDR, voltmeters and other test equipment appropriate to theapplication. Inputs to the item being tested may be simulated, historical dataor real time data.

System testing and designcovers the integration testing which is required to validate the operationalperformance of equipment and software. For the Project, at least for theinitial phase, there is expected to be little or no software creation orhardware development. To reduce project costs and risk, all software andhardware scheduled to be used is commercial off the shelf applications for at least the initial phase of the Project. This maychange for subsequent phases.

Testing will be performed tovalidate the functionality of the field devices. This functionality will be end-to-endand will show that the devices can be controlled and monitored by the local andregional TMCs and eventually the Caltrans ATMS. The exact testing to beperformed will be detailed in the individual device acceptance test plans andin the system acceptance test plan. If amalfunction is determined, the responsibility for correcting that malfunctionwill 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 thecamera is at fault, the installation contractor will fix the camera; if it isdetermined there is a problem with the communications lines between theMillbrae BART station and the D4 TMC, then the responsibility is Caltrans’.)

6.7Verification Plan Guidelines

Acceptance testing for the Project will consist of avariety of tests ranging from tests at the factory on the proposed equipmentthrough system acceptance testing.

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

Factory tests – As part of the Project, a variety ofequipment/material will be required. To ensure this equipment/material issuitable for this project and meets the specifications, it will be necessarythat tests be performed at the factory. These tests will range from compliancewith environmental requirements (i.e., the operating and storage temperatureranges) to the loss per meter in fiber optic cabling.

Delivery tests – Upon delivery of material to theselected 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 andwhat was specified. Additionally, other tests such as noise loss of fiber opticcable on the reel will be required.

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

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

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

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

Test plans will be developed by Caltrans or theirdesignated representative to verify the system provided meets the requirementsof the specifications.

6.8Deployment Plan

The deployment of the ITS elements for the San MateoSmart 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 toCaltrans

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

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

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

§A System Integrator will have overall responsibility tocoordinate the work of multiple Contractors and integrate and test the entireSmart 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 nextimplementation will be Phases I and II (see Figure 1) with implementationoccurring from I-380 south.

§The final implementation will be Phase III

·Procurement

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

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

§All procurements should be competitive.

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

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

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

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

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

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

§Special attention will bedirected to prevent unnecessary use of materials that may impact the scheduleor the implementation of the project.

§The Specifications shall require the use of standard andcommercial parts.

§Where possible, hardware components are to be interchangeable andreplaceable.

·Implementation

§The Contractor shall provide a deployment plan/schedule forreview by Caltrans/ C/CAG / SMCTA. This deployment plan/schedule is to beupdated at least monthly.

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

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

§Training on the system is to be provided before system acceptancetesting.

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

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

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

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

§The Contractor is responsible for obtaining and complying withall permits.

·Maintenance and Operations

§Once the Contractor accesses a cabinet, he is then responsiblefor maintenance of that cabinet and associated equipment until systemacceptance

§New equipment provided by public agencies will be maintained bythese public agencies to the extent these public agencies will be viewed as amanufacturer. The Contractor will be responsible for identifying malfunctionsand replacement of equipment.

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

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

6.9Operations and Maintenance Plan

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

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

The owner of the equipment shall be responsible formaintaining a suitable supply of spares that can be provided in a timelymanner.

Maintenance shall be provided in accordance with themanufacturer’s recommendations.

Operations and maintenance shall be in accordance withthe Deployment Plan.

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

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

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

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

·This Plan will be followed after the warranty period.

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

·A system activity log will be kept, which will include systemdeficiency 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 theinterruption to normal system operations. Any maintenance activities that causemajor interruption shall be discussed with and approved by the affectedagencies prior to implementation.

·All system support and maintenance activities shall bedocumented.

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

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

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

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

6.10Training Plan

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

·As equipment is installed and upgraded on this project, trainingin operation as well as maintenance and repair will be required. Whereverpossible, this training should include hands-on experience, either in the fieldor in the TMC, and be provided by the equipment manufacturer or other qualifiedpersonnel.

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

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

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

·At least one location of each type of field equipment shall be inplace 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 endof each session to verify necessary knowledge and skill levels.

·Written manuals should be provided as part of each trainingworkshop.

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

·Training must be satisfactorily completed prior to assumption ofmaintenance responsibilities.

6.11Configuration Management Plan

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

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

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

The general responsibilities of the change control boardshall 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 managementplan for approval by Caltrans, C/CAG and SMCTA.

Configuration identification shall identify each criticalcomponent, including software unit, documentation, and other supportinginformation that is to be put under the configuration control. Any such componentis termed a Configuration Item (CI). Configuration identification also consistsof defining baselines and releases that are time-phased to the developmentschedules.

Each CI shall be assigned a unique identification. Forexample, a document may be assigned the number 1300 and the name SystemReview Procedures. The document will be referred to as Document #1300. Versioncontrol shall maintain individual versions of the CIs. The CI and versioncontrol shall be maintained in each document.

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

Major versions of CIs shall be established when the CIsare accepted by the CCB and enter a baseline. Minor versions of CIs shall beestablished as necessary to indicate a new level of available functionality orinformation. Temporary versions shall be used by individual development teamswhere desired.

Change control (CC) is intended to assure a disciplinedprocess for handling problems and changes of CIs. Any change to any CI underCCB control shall go through change control. Change control starts from achange request originated by a change request originator, who can be thedeveloper, user, Independent V&V tester, or one of the stakeholders. Thisrequest shall include the description of the problem (if any), the proposedchange, and the impact of the change (both cost and benefit) from the point ofview of the party proposing the change. If deemed necessary, the CCB shallidentify parties that might be affected by the change and distribute the changerequest for their review. CCB members will then combine their assessments andprioritize the change request. The CCB may decide to accept, reject, or deferthe change request. If a change request is accepted, the change tasks will beallocated. The CCB shall notify all concerned parties about its decision. Theoriginator shall document this request in a CI Change Request Form (CRF) andsubmit 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 thechange proposed in the CRF. The implementation of changes shall follow theregular CI development procedures. Successful testing must be conducted beforethe CI is released to the CCB to be put under CCB control.

A change request tracking tool shall be evaluated andselected prior to the Initial Build. This tool will be used by the developmentteam 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 willconsist of the following:

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

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

·A description of the integrated functionality to be accomplishedduring baseline integration

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

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

·A development schedule for each CI and subsystem

·A development schedule for baseline integration

6.12Risk Management Plan

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

Table 8 – Potential ProjectRisks and Proposed Mitigation

6.13System Procurement Plan

See Deployment Plan.

6.14System Development Plan

The Contractor shall provide a deployment plan forapproval by C/CAG, Caltrans and the SMCTA. The plan shall meet the requirementsin this section.

To ensure that all system development activities areconducted in an organized way, the planning process is carried out throughoutthe entire system development life cycle. The planning encompasses the systemrequirements analysis, system design, system implementation, system testing andsystem transition. System development planning is a dynamic process and isperiodically modified based on the feedback from the execution of the plannedactivities.

Configuration management will be exercised to ensure thatthe system construction follows an incremental approach. This will bedocumented in a configuration management plan.

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

A series of systematic tests will be performed at variousstages of the system development to ensure the developed system performs asexpected. These tests include subsystem testing, incremental integrationtesting, internal system testing, and system verification and validation (V&V)testing. Among other testing techniques, regression testing and stress testingwill be used whenever applicable. For baseline testing, subsystem testing andincremental integration testing, the contractor will be responsible to performthe tests, but the test design will be reviewed and the testing will bewitnessed by CCB or designated representatives. To ensure independence of thesystem V&V testing, an independent system Verification and Validation Group(V&VG) will be established to perform the testing. Members of the V&VGare 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 andimplementation, and maintain consistency between components, subsystems andsystem and documents.

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

The subsystem implementation will be performedincrementally. Various incremental internal baselines will be defined. A set ofactivities such as coding, documentation, integration, and testing will beperformed for each baseline until the final baseline.

As part of an incremental development cycle, the smallestand most meaningful part of the system shall be implemented first andestablished as a baseline. Then iterative improvements to that baseline shallbe performed which shall result in the complete system. This approach, alsocalled iterative prototyping, helps insure coordination among parts of thesystem.

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

As part of an iterative development strategy, it isunderstood that as system construction proceeds, changes appropriate to the analysisand design stages may become apparent. As changes to system architecture anddesign are indicated through the iterative development and implementationprocess, the team shall modify the appropriate analysis and designdocumentation to reflect the change. For each such change, an analysis of theresults of that change on the other components of the system shall beperformed.

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

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

6.15Quality Management Plan

While each agency associated with this Project isresponsible for following their own in-house quality management plan, theContractor shall develop a project-wide Quality Management Plan conforming tothe requirements of this section.

This SEMPdefines the interdisciplinary tasks required throughout a system’s lifecycle to transform stakeholder needs, requirements, and constraints into anintelligent transportation system (ITS) solution. Quality management (QM) is acritical element of the back-end phase of a systems engineering process (SEP).The QM element is essential to the verification and validation process of allsystem requirements identified in the front-end systems engineering phase.

This section provides guidance for the Contractor toimplement 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 managementfunctions that determine and implement quality policy. Through an effective QAprogram, 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 andconfiguration management (CM) processes, and are tailored to meet theguidelines and recommendations in the ANSI/EIA-649 standard, the ISO 10007 configurationmanagement guidelines, and the IS09000 family of international QM standards.

The organizational structures, responsibilities,procedures, processes, and resources for implementing a QM system should onlybe as comprehensive as needed to meet the quality objectives and contractualpurposes. The QM system is the overall management of the collective body ofprocesses, operating procedures, objectives, responsibilities, resources, andinfrastructure to implement an effective quality policy. To be successful, itrequires the commitment and participation of all stakeholders, including thefull commitment and responsibility of top management.

The first step for the Contractor in setting up a QMsystem is to generate a “quality manual.” This should be done before anyquality procedures or specifications are written. The quality manual is adocument that states in a concise format the organization’s high-level policiesand objectives that are required to achieve the desired level of qualitycompliance. It should also show how the organization’s overall documentation ofspecifications is structured.

Each ISO quality sectionor element the quality manual addresses should be written with a minimum of thefollowing three sections:

·A Scope sectionthat simply states the purpose of the covered area

·A Policy sectionthat states company policy regarding the applicable ISO clause

·A Responsibilitysection that states who is responsible for thepolicy 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 exceedwhat is needed to meet the desired quality objectives. A quality system shouldencompass not only the quality of the finished product, but also the quality ofoperational processes as well. It is therefore essential to clearly documentthe desired quality objectives, and the processes by which these objectiveswill be achieved. The essence of these quality objectives is the “qualitystandard,” and it is up to the quality system to ensure that the documentedprocedures, actual operation, and quality records all conform to this standard.

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

Typically, the QA Engineer has been delegated the overalloperational authority to implement the project QA program in accordance withproject requirements. The QA Engineer or his/her designee has responsibilityfor delivering a system that meets quality expectations. Specificresponsibilities include:

·Determining quality objectives

·Assigning quality objectives to subordinate system stakeholders

·Developing the QA plan

·Periodically reviewing project performance against qualityobjectives

·Developing remediation plans when quality performance is not inline with objectives

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

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

Table 9 – Quality AssuranceMatrix

6.16Documentation

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

Documents shall be developed that describe theresponsibilities and requirements for the identification, preparation, andmaintenance of records that furnish documentary evidence of the processundertaken, the design of the system, the implementation of the system, and theoperation and maintenance of the system. The term "records" usedthroughout this section refers to records attesting to the achievement of therequirements 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 willbe identified. A record is defined as a completed document that furnishesevidence of the quality of items and/or activities affecting quality. A recordsretention and distribution system will be established by C/CAG and Caltrans.The scope of the records retention and distribution system will be described ininstructions and procedures.

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

Corrections to records will be controlled. Controls willprovide for appropriate review or approval by the originating organization. Allcorrections will include the date and the identification of the personauthorized to issue the correction.

Previously developed records shall be updated when majorchanges 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) (developedunder the current contract)

·Functional Requirements (12000 series) (developed under thecurrent contract)

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

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

·Interface Control Requirements (14000 series) (developed underthe current contract)

·Configuration Management Plan (15000 series) (to be developedby 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 theContractor)

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

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

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

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

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

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

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

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

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

6.17Systems Engineering Management Plan

The Systems Engineering Management Plan (SEMP) willinclude the following:

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

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

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

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

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

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

·The work breakdown structure/overall project schedule (to beprovided 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 ofOperations (ConOps) to the final implementation

·Methodology for identifying and selecting critical technologies

6.18Requirements Documentation

The functional requirementswill be based on:

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

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

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

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

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

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

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

·Identification of the functionality desired between the existingCaltrans ATMS and the proposed systems

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

·The functional requirements shall be traced to the ConOps wherepossible

·The functional requirements will be further detailed in futuredocuments

·Each requirement will have a method of verification

·Constraints resulting from technology, standards or policies

The high-level requirementswill 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 orcomponents 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 bebased on the following;

·High level requirementspreviously developed

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

·Identification of thelogical architecture

·Further definition of thedata, performance measures and interface requirements

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

·Evaluation of alternative communication systems along El CaminoReal and other proposed alternate routes (this effort will involveinvestigation of alternative protocols, alternative physical interfaces,alternative recommended equipment and the use of interim communicationtechnologies if needed)

Critical technologies are those technologies whichprevent the system from meeting its goals/objectives and providing thefunctionality required. There are no backups to critical technologies. Withthis definition, all technologies in the proposed system are critical.

DEFINITIONS

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

ARTI- Alternate Route for Traffic Incident Guide that identifies arterialstreets that would best serve as alternate routes during incidents (has beensuperceded)

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

ConfigurationManagement – A process developed to control change in complexinformation technology based systems.

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

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

DedicatedShort Range Communications (DSRC) – A wireless communications channelused for close-proximity communications between vehicles and the immediateinfrastructure. It supports location-specific communications for ITS servicessuch as toll collection, transit vehicle management, driver information, andautomated commercial vehicle operations.

Deployment– An act of placing strategically.

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

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

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

FederalTransit Administration (FTA) – An agency of the USDoT that funds andregulates transit projects.

FunctionalRequirements – What a system must do to address the needs or providethe services that have been identified for the region. In a regional ITSarchitecture, the functional requirements focus on the high-level requirementsfor providing desired service to the user.

InformationFlow – 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 anorganization.

InstitutionalIntegration – Represents the process of combining existing and emerginginstitutional constraints and arrangements.

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

IntelligentTransportation System (ITS) – Electronics, communications, orinformation processing used singly or in combination to improve the efficiencyor safety of a transportation system.

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

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

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

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

ITSArchitecture – Defines how systems functionally operate and theinterconnection of information exchanges that must take place between thesesystems to accomplish transportation services.

LegacySystem – Existing transportation systems, communication systems orinstitutional systems.

Lifecycle – Denotes the strategic cycle or sequencing of a specificprocess.

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

NationalITS Architecture (NA) – A common established national framework for ITSinterconnectivity and interoperability.

OperationalConcept – Describes how the system will work by identifying in sequencethe roles and responsibilities of participating agencies and stakeholders for agiven scenario(s).

Projectit* Architecture (PIA) – A framework that identifies the institutionalagreement and technical integration necessary to define an ITS project and itsinterface with other ITS projects and systems.

ProjectSequencing – The order in which projects are deployed. An efficientsequencing can allow projects to incrementally build on each other.

ProtocolCommunications – A set of rules for how messages are coded andtransmitted between electronic devices. The equipment at each end of a datatransmission must use the same protocol to successfully communicate. It is likehuman language that has an alphabet, vocabulary, and grammar rules used byeveryone who speaks that language.

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

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

RequirementsDefinitions – A total set of considerations that govern what is to beaccomplished, how well and under what conditions. Associated with systemrequirements.

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

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

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

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

Uptime– Defined/measured as the percent of time a system or a subsystem isoperational and providing the functionality in accordance with the performancerequirements for availability.

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

Vehicle-to-VehicleCommunications – Dedicated wireless system handling high data rate, lowprobability of error, line-of-sight communications between vehicles. Advancedvehicle services may use this link in the future to support advanced collisionavoidance implementations, road condition information sharing, and active coordinationto advanced control systems.

Wide-AreaWireless communications – A communications link that providescommunications via a wireless device between the user and an infrastructurebased system. These links support a range of services including real timetraveler information and various forms of fleet communications.

WirelineCommunications – A communications link serving fixed locations. It usesa variety of public or private communications networks that may physicallyinclude wireless (e.g. microwave) as well as wireline infrastructure.

WorkBreakdown Structure – A product oriented listing, in family tree order,of the hardware, software, services and other work tasks, which completelydefines a product or program. The listing results form project engineeringduring the development and production of a material item. A WBS relates theelements of work to be accomplished to each other and to the end product.

Acronyms

AASHTO American Association of State Highway and Transportation Officials

ADMS Arterial Dynamic Message Sign

ANSI American National StandardsInstitute

ASTM American Society for Testing andMaterials

ARTI Alternate Routes for TrafficIncident (Guide)

ATMS Advanced Transportation ManagementSystem

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 ofGovernments 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 DisplaySystem

DGPS Differential Global PositioningSystem

DMS Dynamic Message Sign

DMV Department of Motor Vehicles

DOC Department Operations Center

DSRC Dedicated Short RangeCommunications

DTA Dynamic Traffic Assignment

911 Emergency 9-1-1

ECPA Electronic Communications PrivacyAct

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 SafetyAdministration

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 andElectronics Engineers, Inc.

IEN Information Exchange Network

IP Internet Protocol

ISO International StandardsOrganization

ITE Institute of TransportationEngineers

ITN Integrated TransportationNetwork

ITS Intelligent TransportationSystems

LAN Local Area Network

LCD Liquid Crystal Display

LED Light Emitting Diode

LEO Low-Earth Orbit Satellite System

LRMS Location Reference MessagingStandard

LRT Light Rail Transit

MOE Measure of Effectiveness

MPO Metropolitan Planning Organization

MSC Municipal Service Center

MTC Metropolitan Transportation Commission

NEMA National Electrical ManufacturersAssociation

NHTSA National Highway Traffic SafetyAdministration

NTCIP National TransportationCommunications 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 andEstimates

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 MessageChannel

RFP Request for Proposal

SAE Society of Automotive Engineers

SDO Standards DevelopmentOrganization

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 ImprovementProgram

STMF Simple Transportation ManagementFramework

STMP Simple Transportation ManagementProtocol

SQL Standard Query Language

SSR Spread Spectrum Radio

TCIP Transit Communications InterfaceProfiles

TDMA Time Division Multiple Access

TIMC Traffic Incident ManagementCommittee

TMC Traffic Management Center

TOC Traffic Operations Center

USDOT United States Department ofTransportation

WAN Wide Area Network

WIM Weigh-in-Motion

WWW World Wide Web