Developing Traffic Signal Control Systems

Using the National ITS Architecture

U. S. Department of Transportation
Intelligent Transportation Systems Joint Program Office

February 1998
1. Report No. 2. Government Accession No. 3. Recipient’s Catalog No.

FHWA-JPO-98-026
4. Title and Subtitle 5. Report Date
Developing Traffic Signal Control Systems Using the National ITS February, 1998
Architecture
6. Performing Organization Code

7. Author(s) 8. Performing Organization Report

Various No.

9. Performing Organization Name and Address 10. Work Unit No. (TRAIS)

Mitretek Systems
600 Maryland Avenue SW, Suite 755 11. Contract or Grant No.
Washington, DC 20024 DTFH61-95-C-00040

TransCore, Inc.
th
251 Park Avenue South, 14 Floor
New York, NY 10010
(See Acknowledgments)
12. Sponsoring Agency Name and Address 13. Type of Report and Period
Covered
Federal Highway Administration
ITS Joint Program Office
400 Seventh Street, S.W. 14. Sponsoring Agency Code
Washington, DC 20590 HVH-1
15. Supplementary Notes

Sponsoring Agency Task Manager — Lee Simmons

16. Abstract
This is one of a series of documents providing support for deploying Intelligent Transportation Systems (ITS). This series
addresses Traffic Signal Control Systems, Freeway and Incident Management Systems , Transit Management Systems, and
Traveler Information Systems. The National ITS Architecture provides a common structure for deploying these systems. An
important point of these documents is that you can reap operational benefits while saving staff hours and design costs by using
the National ITS Architecture as a deployment guide.

This document focuses on traffic signal control systems, a component of ITS. It aims to provide practical help for the traffic
engineering community with deploying traffic signal control systems in an integrated, multimodal environment using the National
ITS Architecture. ITS is the application of management strategies and technologies to increase the efficiency and safety of
national, regional, and local surface transportation systems.

This document covers the basics of traffic signal control ITS applications, the role the National ITS Architecture can play in traffic
signal control system project development, the development process for a regional architecture, some challenges faced by traffic
management agencies, and some best practices and lessons learned for developing and deploying of advanced traffic signal
control systems. The regional architecture will indicate how current and future systems in the region may be integrated to obtain
the added benefits available through integration of these systems.
17. Key Words 18. Distribution Statement
National ITS Architecture, traffic signal control, No restrictions. This document is available to the
Intelligent Transportation Systems, ITS, integration, public from:
Regional ITS Planning National Technical Information Service
Springfield, Virginia 22161
19. Security Classif. (of this report) 20. Security Classif. (of this page) 21. No of Pages 22. Price

Unclassified Unclassified 160

Form DOT F 1700.7 (8-72) Reproduction of completed page authorized
 Notice

This document is disseminated under the sponsorship

of the Department of Transportation in the interest of
information exchange. The United States Government
assumes no liability for its contents or use thereof.
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Table of Contents
Section Page

1. Introduction and Intended Audience 1-1

1.1 Purpose and Intended Audience 1-1
1.1.1 Intended Purpose 1-1
1.1.2 What is the National ITS Architecture? 1-2
1.1.3 Intended Audience 1-2
1.2 Advanced Traffic Signal Control 1-3
1.2.1 Traffic Signal Control Functions 1-3
1.2.2 Benefits of Advanced Traffic Signal Control Systems 1-4
1.2.3 Integration Challenges and Needs 1-5
1.3 The National ITS Architecture Can Help You 1-7
1.3.1 Help for ITS Traffic Management Implementers 1-7
1.3.2 ITS Standards 1-9
1.4 Document Organization and Summary 1-10
1.4.1 Document Organization 1-10
1.4.2 Document Summary 1-10

2. Use of the National ITS Architecture Tools in Traffic Signal Control Projects 2-1
2.1 Overview 2-1
2.2 Traffic Signal Control System Operations 2-1
2.2.1 Control and Coordination of Traffic Signals 2-2
2.2.2 Surveillance and Monitoring of Traffic 2-2
2.2.3 Monitor Faults and Malfunctions 2-3
2.3 Development of Traffic Signal Control Projects 2-3
2.3.1 Identification of Needs or Problems 2-3
2.3.2 Identification of Solutions 2-3
2.3.3 Planning and Design of the Solution 2-4
2.3.4 Funding, Procurement and Implementation 2-4
2.4 Key Concepts of the National ITS Architecture 2-4
2.4.1 User Services and User Service Requirements 2-5
2.4.2 Logical Architecture 2-7
2.4.3 Physical Architecture 2-10
2.4.4 Equipment Packages 2-16
2.4.5 Market Packages 2-16
2.4.6 National ITS Architecture Documents 2-19

iii
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Section Page

2.5 Using the National ITS Architecture to Develop Traffic Signal Control Projects 2-22
2.5.1 Identification of Needs or Problems 2-26
2.5.2 Identification of Solutions 2-27
2.5.3 Planning and Design of the Solution 2-31
2.5.4 Funding, Procurement, and Implementation 2-36
2.6 Traffic Signal Control Project Application Scenarios 2-37
2.6.1 System Upgrade Scenario (Using Market Packages) 2-37
2.6.2 Freeway-Arterial Coordination (Using User Service Requirements) 2-48
2.6.3 Transit Vehicle Priority (Using Market Packages) 2-56
2.7 Summary 2-66

3. Regional ITS Planning 3-1

3.1 Concept Planning 3-2
3.1.1 Stakeholder Identification 3-3
3.1.2 Identification of Existing ITS or Transportation Management Functions 3-3
3.1.3 Identification of Regional Needs 3-4
3.1.4 Identification of Needed ITS Functions and Improvements 3-4
3.1.5 Concept Planning Products 3-4
3.2 Implementation Planning 3-6
3.2.1 Stakeholder Identification 3-6
3.2.2 Development of a Regional Architecture 3-6
3.2.3 Operations Requirements 3-10
3.2.4 Linkage to the Transportation Plan 3-10
3.2.5 Time Phasing 3-11
3.2.6 Regional Technology Agreements 3-12
3.3 Project Deployment 3-13
3.4 Evaluation 3-13

4. Lessons Learned / Best Practices 4-1

4.1 Teamwork and Coordination 4-1
4.1.1 Regional Coordination 4-1
4.1.2 The Program Development Team 4-2
4.1.3 The Program Manager 4-3
4.1.4 Staffing the Program 4-3
4.2 Project Development Process 4-4
4.2.1 Identification of Needs or Problems 4-4
4.2.2 Identification of Solutions 4-4
4.2.3 Planning and Design of the Solution 4-5
4.2.4 Funding, Procurement, and Implementation 4-8

iv
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Section Page

4.3 Procurement and Contracting 4-12

4.3.1 Autonomy in the Procurement Process 4-12
4.3.2 Selection of the Contracting Approach 4-12
4.3.3 Procurement Rules and Regulations 4-15
4.3.4 Procuring Software 4-15
4.3.5 Procuring Telecommunications 4-16

5. How Can I Find Out More? 5-1

5.1 How Can I Find Out More About ITS? 5-1
5.2 How Can I Find Out More About the National ITS Architecture? 5-2
5.3 How Can I Find Out More About ITS Standards? 5-3

Acknowledgements AK-1

References RE-1

Appendix A ITS Standards A-1

Appendix B Glossary B-1

Appendix C Physical Architecture Data Flows Associated With Traffic Signal

Control C-1

Appendix D National ITS Architecture Products D-1

v
Developing Traffic Signal Control Systems Using the National ITS Architecture

vi
 Developing Traffic Signal Control Systems Using the National ITS Architecture

List of Figures
Figure Page

1.2-1 Regional Coordination 1-5

1.2-2 Intermodal Coordination 1-6

1.4-1 Document Organization 1-10

2.4-1 The Eight Major Processes within the Logical Architecture 2-8

2.4-2 Example of Logical Architecture Functional Decomposition 2-9

2.4-3 Representative Logical and Physical Architecture 2-11

2.4-4 National ITS Architecture Subsystems and Communications 2-12

2.4-5 Basic Traffic Signal Control System Architecture Depication 2-13

2.4-6 Center Subsystems May Be Implemented in Various Regional 2-15

Configurations

2.4-7 Surface Street Control Market Package 2-17

2.4-8 Market Package Elements 2-18

2.5-1 National ITS Architecture Hypertext View 2-24

2.5-2 Example Physical Data Flows for Traffic Management 2-33

2.5-3 Aggregation of Surface Street Control and Incident Management Systems 2-35

2.5-4 Modification of Aggregated Market Package Architecture 2-36

2.6-1 Surface Street Control Market Package 2-39

2.6-2 Network Surveillance Market Package 2-39

2.6-3 Traffic Information Dissemination 2-40

2.6-4 NTCIP Standard 2-42

vii
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Figure Page

2.6-5 Traffic Signal Control System Upgrade Scenario 2-45

2.6-6 Freeway-Arterial Coordination Scenario 2-50

2.6-7 Freeway-Arterial Coordination 2-55

2.6-8 Signal for Priority for Transit Vehicles Scenario - Center-to-Center Approach 2-57

2.6-9 Signal Priority for Transit Vehicles - Local Coordination Approach 2-58

2.6-10 Multi-modal Coordination Market Package 2-60

2.6-11 Probe Surveillance Market Package 2-62

3.1-1 Example Strawman Regional Architecture 3-5

3.2-1 Example Regional Physical Architecture 3-8

3.2-2 Regional Traffic Control Architecture Flows Applied in the Anytown Region 3-8

A-1 OSI Layers A-3

C-1 Physical Data Flows for Traffic Management C-1

viii
 Developing Traffic Signal Control Systems Using the National ITS Architecture

List of Tables
Table Page

1.2-1 Summary of ITS Traffic Signal Control System Benefits 1-4

2.4-1 User Services for the National ITS Architecture 2-6

2.4-2 Example of User Service Requirements: Excerpt from Traffic Control 2-7

2.4-3 Example Process Specifications (Overview Descriptions) 2-10

2.4-4 ITS Market Packages 2-19

2.5-1 Connecting Problems, Solutions, and the National Architecture 2-31

2.6-1 Cost for System Upgrade Scenario 2-46

2.6-2 Cost for Surface Street Control Market Package 2-46

2.6-3 Cost for Network Surveillance Market Package 2-47

2.6-4 Cost for Traffic Information Dissemination Market Package 2-47

2.6-5 Summary Cost for Transit Vehicle Priority Scenario 2-65

ix
Developing Traffic Signal Control Systems Using the National ITS Architecture

1
 Developing Traffic Signal Control Systems Using the National ITS Architecture

1. Introduction and Summary

1.1 Purpose and Intended Audience
This is one of a series of documents providing support for deploying Intelligent
Transportation Systems (ITS). This series addresses:

♦ Traffic Signal Control Systems

♦ Freeway and Incident Management Systems

♦ Transit Management Systems

♦ Traveler Information Systems

The National ITS Architecture provides a common structure for deploying these systems.
An important point of these documents is that you can reap operational benefits while
saving staff hours and design costs by using the National ITS Architecture as a
deployment guide.

1.1.1 Intended Purpose

This document focuses on traffic signal control systems, a component of ITS. It aims to
provide practical help for the traffic engineering community with deploying traffic signal
control systems in an integrated, multimodal environment using the National ITS
Architecture. ITS is the application of management strategies and technologies to
increase the efficiency and safety of national, regional, and local surface transportation
systems. Intelligent Transportation Systems form the basis for a new way of doing
business in addressing the nation’s surface transportation needs. Rather than solving
transportation challenges solely by building additional roadway capacity, ITS strategies
strive to use existing facilities more efficiently by applying technology and effective
management strategies to collect, transfer, process, and share historic and real-time
transportation information. This includes the use of computer, communications, sensor,
information, and control technologies and a structured approach to manage the planning,
development, deployment, operations, and maintenance of ITS systems and projects.

This document is designed as a guide for how the National ITS Architecture can be used
in the process of designing, developing, and implementing effective traffic signal control
systems. Development of the National ITS Architecture arose out of a need to provide a
common framework for deployment of ITS across the nation. The National ITS
Architecture contains the information you need to develop a regional architecture, to be
assured you haven’t overlooked anything important, and to ensure you are preparing an
efficient deployment. This document shows how to enhance existing and emerging traffic
signal control systems, facilitate design and upgrade of future systems, and help
overcome challenges commonly faced by traffic management personnel. It does not

1-1
 Developing Traffic Signal Control Systems Using the National ITS Architecture

describe traffic signal control systems fundamentals, since that background already exists
in the Traffic Control Systems Handbook [FHWA, February 1996]. This document covers
the basics of traffic signal control ITS applications, the role the National ITS Architecture
can play in traffic signal control system project development, the development process for
a regional architecture, some challenges faced by traffic management agencies, and
some best practices and lessons learned for developing and deploying of advanced traffic
signal control systems. The regional architecture will indicate how current and future
systems in the region may be integrated to obtain the added benefits available through
integration of these systems.

1.1.2 What is the National ITS Architecture?

The National ITS Architecture defines the components of the surface transportation
system, how they interact and work together, and what information they exchange to
provide 30 ITS user services. These 30 user services have been identified by the U.S.
ITS community as part of the National ITS Program to guide the development of ITS and
are listed in Section 2. A key requirement for development of the National ITS
Architecture [FHWA, January 1997] was that it include the transportation functions
necessary to provide the 30 user services.

Using the National ITS Architecture will save implementers time and money because it
contains much of the up front analysis and planning information necessary to deploy ITS,
including project definition and requirements, information exchange requirements, system
evaluation criteria, cost development information, communications analysis, and benefits
of deployment of specific ITS applications.

1.1.3 Intended Audience

The intended audience of this document includes:

♦ Transportation engineers, planners, and mid-level administrators for state, local,

and regional transportation agencies, including metropolitan planning organizations
and regional transportation authorities, involved in planning, designing,
implementing, operating and maintaining traffic signal control systems.

♦ Transportation professionals and others interested in understanding traffic signal

control systems challenges and solutions based on the Architecture.

The audience is assumed to be reasonably knowledgeable in traffic management

operations and maintenance, particularly traffic signal control, and to have had some
practical experience in this field. More specifically, if your work involves planning,
designing, implementing, operating or maintaining traffic signal control systems, and you
perform one of the following functions within your organization, this document is intended
for you:

1-2
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Regional Transportation Planning Project Implementation

Traffic Engineering ITS Project Definition

Identification and Allocation of Project Funds Preliminary and Final Design

Procurement of Services and Equipment Project Acceptance Testing

Project Approval System Evaluation

Project Management Operations, Maintenance

Training

1.2 Advanced Traffic Signal Control

Advanced traffic signal control systems provide traffic control through traffic management
strategies that are responsive to changing traffic demand and benefit the public with
improved traffic flow. Additionally, they are easy to maintain, expand, upgrade, and
coordinate with other transportation systems in their region.

1.2.1 Traffic Signal Control Functions

Effective traffic signal control systems provide control, surveillance, and maintenance
functions: control of traffic by adjusting and coordinating traffic signals at intersections;
surveillance by monitoring traffic conditions with vehicle detectors and cameras; and
maintenance of equipment by monitoring for equipment failures. These functions allow a
traffic management agency to service traffic demand, share traffic status with other
agencies and with the traveling public, and operate and maintain the traffic signal control
system.

♦ Control and Coordination of Traffic Signals - Traffic signal control systems control
signal timing at individual signal controllers to coordinate surface traffic flow. In the
most advanced systems, traffic flow information is used as input data by
algorithms in traffic control programs which automatically adjust signal timing plans
in response to current traffic demand.

♦ Surveillance and Monitoring of Traffic - The most common type of detection device
used today is the inductive loop vehicle sensor. An emerging trend in traffic signal
control systems is the use of closed-circuit television (CCTV) cameras, possibly
with image processing to derive traffic flow data, to enable traffic managers to
monitor the video. Information collected in this fashion is used to determine road

1-3
 Developing Traffic Signal Control Systems Using the National ITS Architecture

conditions, identify and verify incidents, and verify traffic information collected
through other methods.

♦ Monitor Faults And Malfunctions - An effective traffic signal control system

monitors equipment for faults or malfunctions that may affect the system’s ability to
properly control traffic flow. The objective is to identify system and equipment
operational problems and quickly initiate corrective actions and repair responses
to return the equipment to its proper operating condition in order to keep traffic flow
interruptions to a minimum.

The above are descriptions only of the top level functions performed in advanced traffic
signal control systems. These top level functions can also support many other functions
such as incident detection, EMS response, transit operations, and traveler information
systems.

1.2.2 Benefits of Advanced Traffic Signal Control Systems

In general, each traffic signal control system is designed to meet the specific social and
political objectives of each community. Fundamentally, however, traffic signal control
systems strive to achieve the following:

♦ Maximize traffic flow efficiency and public safety.

♦ Accurately monitor traffic flows and make appropriate traffic control decisions in a
timely manner.

♦ Moderate fuel consumption and environmental impact of stop-and-go traffic

through improvements to traffic flow efficiency.

Advanced traffic signal control systems have demonstrated benefits in several areas
including travel time, speeds, vehicle stops, delays, energy consumption, and
environmental impacts. In addition, they have been shown to reduce congestion and the
number of accidents on roadways. Table 1.2-1 summarizes the range of traffic signal
control system benefits as reported by the U.S. Department of Transportation [Mitretek,
1997].

Table 1.2-1. Summary of ITS Traffic Signal Control System Benefits

Travel Time Decreased by 8% - 25%

Travel Speed Increased by 14% - 22%

Vehicle Stops Decreased by up to 41%

Delay Decreased by 17% - 44%

1-4
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Fuel Consumption Decreased fuel used by 6% - 13%

Emissions Decreased HC emissions by 4% - 10%

Decreased CO emissions by 5% - 15%

1.2.3 Integration Challenges and Needs

While advanced traffic signal control systems provide many important benefits, the
benefits can be increased by using the National ITS Architecture to guide integration with
other parts of the transportation system. The subsystems of the National ITS Architecture
are integrated, meaning that they are interconnected with each other by communications
links and are therefore able to exchange information with one another. The various
subsystems exchange information to coordinate their operation within a region, and to
provide transportation functions to each other. An important aspect of this sharing is that
operations in each center may be improved by smoothing the transitions between
agencies and jurisdictions.

Regional Coordination
Increasingly, managers of traffic signal control systems are being faced with challenges
related to integration and coordination with other local transportation operating agencies.
For example, integration of traffic signal control systems with freeway management
systems is illustrated in Figure 1.2-1.

Traditionally, traffic signal control systems have been

designed to optimize traffic flow on the surface street
network, often without considering other transportation
systems. The advent of advanced computer,
communication, and traffic signal controller
technology, however, has made it possible to integrate
transportation systems operated by different agencies
(e.g. freeways, transit), including traffic signal
agencies in other jurisdictions.

One example of this is the adjustment of signal timing

in the vicinity of an incident. This can help to clear
traffic nearby and decrease the flow of vehicles
entering the area before surface street congestion
from the incident is compounded. Another example is
the adjustment of signal timing along the service road
of a freeway if there is congestion on the mainline, to
encourage motorists to use the surface streets before

Figure 1.2-1. Regional Coordination

1-5
 Developing Traffic Signal Control Systems Using the National ITS Architecture

mainline congestion worsens and spills onto the streets. These examples illustrate the
coordination of a traffic signal control system with an incident management system.

1-6
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Intermodal Coordination

Traffic signal control systems

can provide priority or
preemption to vehicles by
adjusting traffic signals. Three
examples of Intermodal
Coordination illustrated in Figure
1.2-2 are emergency vehicle
preemption, transit vehicle
priority, and highway-rail
intersection coordination. These Figure 1.2-2. Intermodal Coordination
examples of Intermodal
Coordination use vehicle location and identification information to dynamically adjust traffic
signals and illustrate the potential coordination of a variety of systems with traffic signal
control systems.

Emergency Vehicle Preemption

A traffic signal control system can provide traffic signal preemption to emergency
vehicles. An emergency management center can track vehicles with automated vehicle
location equipment and coordinate the signal preemption with a traffic management
center. Alternatively, the emergency vehicle can communicate directly with a traffic signal
controller and coordinate the preemption locally. Similarly, route guidance, using Global
Positioning System (GPS) and map technology, allows safe and efficient routing of
emergency vehicles to the site of the emergency, and from the emergency to a medical
facility.

Transit Vehicle Priority

Transit and traffic control agencies can cooperate to provide selected transit vehicles
priority at signalized intersections. Selected bus routes can be granted priority at traffic
signals to assist the buses in adhering to their schedules. This can improve transit on-
time service and may help convert automobile drivers to transit use. Transit vehicles, in
turn, can be used as probes to provide current traffic flow conditions to the traffic signal
control system.

Highway-Rail Intersection Coordination

Traditional active warning systems, such as flashing lights and control gates at highway-
rail intersections, are a fully automatic and train-responsive operation. Early warning of
the approach of trains with automated vehicle location capabilities to highway-rail
intersections provide the traffic management center with time to adjust local control at
adjacent signalized intersections to improve intersection safety. Vehicle operators can

1-7
 Developing Traffic Signal Control Systems Using the National ITS Architecture

also be informed in advance (through the use of variable message signs, for example) of
an approaching train.

1.3 The National ITS Architecture Can Help You

1.3.1 Help for ITS Traffic Management Implementers

Similar to a model home blueprint, the National ITS Architecture provides a common
structure for the design and implementation of ITS. The National ITS Architecture defines
the functions (e.g., gather traffic information) that must be performed by components or
subsystems, where these functions reside (i.e., roadside, traffic management subsystem,
in-vehicle, etc.), the interfaces and information flows between subsystems, and the
communications requirements for the information flows (e.g., wireline or wireless). Just as
the model home design is often changed to meet the needs and living space requirements
of individual families, the common structure provided by the National ITS Architecture can
be tailored to meet a region’s unique transportation needs.

In addition, the National ITS Architecture identifies and specifies requirements for
standards needed to support national and regional interoperability, as well as product
standards needed to support economy of scale considerations in deployment. These
standards will include the formal definition of the physical interfaces and information
exchange requirements of the National ITS Architecture.

A lot of time and effort went into developing the National ITS Architecture --for a
very good reason -- to make the process of designing and implementing these
systems easier for you.

YOU CAN SAVE STAFF HOURS AND ENGINEERING DESIGN COSTS BY USING IT.

An agency using the National ITS Architecture can save time and money in the
development of a project from its inception through its implementation. Some capabilities
of the National ITS Architecture that will be particularly important to your development of
an effective traffic signal control ITS application are listed below.

♦ Correlates services and requirements to subsystems and data flows, thus

providing traceability for a project to the selected architecture.

♦ Illustrates the benefits that can be obtained through efficient grouping of ITS
functions plus sharing of information for multiple purposes across the
transportation system, avoiding redundancy and saving money.

♦ Provides a view into the future to identify services and functionality that may not
have been initially considered, currently needed, or even feasible. This provides a
checklist of future capabilities that could be planned for now in anticipation of future

1-8
 Developing Traffic Signal Control Systems Using the National ITS Architecture

needs. Planning for these future needs in database and interface designs will save
substantial costs of modifications needed for these later additions.

♦ Provides an extensive list of the transportation agencies (by matching the functions
they perform with the corresponding subsystem names in the National ITS
Architecture) that your agency should consider talking to during initial planning of an
implementation (i.e., the stakeholders).

♦ Defines the kind of information one should consider sharing among these
agencies. Your agency can use this information as a checklist in planning the
project and in discussions with other stakeholders to show how they can participate
through sharing of the information.

♦ Serves as a good starting point or template (which can be tailored) for developing
the regional architecture that will drive the designs for specific project s. Starting
with the National ITS Architecture, one can merely delete the functions and
information flows that do not apply and then incorporate any specific local
requirements and considerations. This is more fully addressed in section 3.

♦ Provides a departure point for developing functional requirements and system

specifications to be included in a procurement package, including identification of
the interfaces (some of which may have approved standards or standards work
under way) and data exchanges that must be included.

♦ Provides ballpark estimates of costs for a wide range of ITS-related equipment and
services that can be used for initial project costing.

♦ Can support a check on the product being provided by a design contractor (if the
contractor is asked to demonstrate the use of the National ITS Architecture and its
relationship to the design being offered).

For many of the reasons stated above, the National ITS Architecture can serve as a good
starting point for developing a regional architecture in the transportation planning arena.
Gathering a wide range of stakeholders and developing a regional architecture which
responds to local transportation needs and problems can serve as a guiding framework
for coordinated development of ITS within a region and will evoke the discussion of
operations roles and responsibilities, phasing considerations for planned ITS
enhancements, and regional agreements on technology and standards.

Using the National ITS Architecture and ITS standards will provide broad, long
term benefits:
♦ Interoperability: The National ITS Architecture has identified where standards
are needed for system interoperability (interfaces and products). Because the
National ITS Architecture is serving as the common foundation for ongoing ITS
standards development work, factoring it into your current system enhancements
will facilitate the transition to a sta ndard interface definition in the future. Using

1-9
 Developing Traffic Signal Control Systems Using the National ITS Architecture

standard interfaces will provide a foundation for national and regional

interoperability and even interchangeability of some devices used in ITS traffic
management, even though they may be from different manufacturers.

♦ Increased competition: By requiring use of open standards (non-proprietary),

multiple vendors will be able meet the standards and be able to respond to RFPs.
Support and upgrades will also be available from multiple potential sources,
avoiding the problems of being locked in to one source (e.g., the vendor goes out
of business).

♦ Future expandability: By designing within a common framework and using open

standards, you will create an environment that integrates legacy systems with new
ITS applications and allows more functionality to be added as needed.

♦ Lower costs: ITS equipment and device compatibility will create larger total
markets attracting more suppliers resulting in more capable products at lower
prices. The resulting long-term costs of deployment will be pushed down by these
economies of scale for off-the-shelf ITS equipment and products and by
competition through open-system enabling of multiple vendors.

♦ Increased transportation system integration: The open nature and structure of

the National ITS Architecture and use of standards-compliant components will
make integration of complex traffic management components and regional
systems easier. Improved integration of systems operated by different agencies
will permit effective information sharing and more effective use of resources.
Seamless traveler services across agency lines will become a reality.

♦ Assistance in project development and regional planning activities: As

evidenced from the above discussion, the National ITS Architecture can be
usefully applied to both project development and longer term regional planning
activities. Accordingly, this document will address these activities in two separate
sections for clarity and ease of reference for the reader.

1.3.2 ITS Standards

Using the National ITS Architecture to plan, design, deploy, and integrate traffic signal
control systems will help ensure that your system will be compatible with existing, planned,
and future systems in your region. Your traffic signal control system will also have an
open systems architecture, use industry-accepted standards and interfaces wherever
they exit, and will minimize reliance on proprietary information, interfaces, and protocols.
Ultimately, these standards will promote national interoperability of some key services to
ensure that travelers from outside your region will also be able to benefit from the ITS
services you provide. Consistent with the National ITS Architecture, the U.S. DOT is
supporting and guiding development of selected ITS standards by funding Standards
Development Organizations (SDOs).

1-10
 Developing Traffic Signal Control Systems Using the National ITS Architecture

1.4 Document Organization and Summary

1.4.1 Document Organization

This document is divided into five major sections with the content of the document as
illustrated in Figure 1.4-1.

Section 1: Section 2: Section 3:

Using Architecture Regional ITS
Introduction
Tools in Traffic Signal Planning
Control Projects

What is ITS? How are traffic signal control How do you plan for ITS in a Region?
What is the National ITS Architecture? functions represented in the How do you deploy an ITS Project?
architecture?

How do you use the architecture

to develop traffic control projects?

Section 4: Section 5: Appendices

Best Practices How do I Find Out More?
Lessons Learned
A: ITS Standards

B: Glossary
Teamwork and Coordination ITS
C: Applicable Physical
Project Development Process National ITS Architecture
Architecture Data Flows
Procurement and Contracting ITS Standards
D: National ITS Architecture
Products

Figure 1.4-1. Document Organization

1.4.2 Document Summary

This document covers many important areas and you are encouraged to read the entire
document. However, if you are unable to do so, the summary presented below will point
you in the right direction to find the information you are seeking.

For example:
♦ If you are beginning a major traffic signal control system project, proceeding to
review sections 2 and 4 might be best.

♦ If you are involved in long-term planning of your transportation system, starting

your review with section 3 might be best.

Section 1: Introduction and Summary

Section 1 briefly discusses ITS, the National ITS Architecture, benefits of traffic signal
control ITS applications, traffic signal control functions, and briefly discusses capabilities
provided by the National ITS Architecture and why you should use it.

1-11
 Developing Traffic Signal Control Systems Using the National ITS Architecture

√ ITS uses a combination of management strategies and computer, communications,

surveillance, and control technologies to increase the efficiency of national, regional,
and local surface transportation systems.

√ There are a growing number of successful ITS traffic signal control system projects
yielding benefits with very encouraging cost/benefit ratios.

√ Using the National ITS Architecture as a tool in developing your traffic signal control
systems will help provide for ease of future functionality additions and of adding
interfaces to future subsystems.

√ The Architecture supports integration of surface transportation systems. This

includes, for example, the integration of traffic signal control systems with freeway
management, incident management, transit management, and highway-rail
coordination systems.

Section 2: Use of the National ITS Architecture Tools in Traffic Signal Control
Projects
Section 2 identifies the functions of traffic signal control systems as defined by the
National ITS Architecture. The section then explains how the Architecture can be used to
develop traffic signal control ITS applications. Some representative scenarios are used
as examples to help you use the National ITS Architecture.

√ The National ITS Architecture provides a common structure for the deployment of ITS;
It defines 19 interconnected physical subsystems, the transportation functions each
subsystem performs, and the information subsystems exchange with each other to
provide 30 user services.

√ The functions associated with basic traffic signal control systems reside in 2
subsystems of the National ITS Architecture: the Traffic Management Subsystem and
the Roadway Subsystem.

√ The National ITS Architecture can be applied to most project development steps, and
is particularly helpful in the identification of solutions and the planning and design of the
solution.

√ The Architecture only defines the transportation management functions that each
physical subsystem performs plus the interfaces and data flows between them.
Designers have complete freedom in deciding which functions are required for their
needs, what equipment to use to implement the transportation management functions,
and what technologies will be used. Designers are encouraged to be compatible with
the Architecture and with ITS standards to achieve interoperability, to provide for
future enhancements and expandability, and to obtain the long-term benefits of higher
quality and lower costs from economies of scale.

Section 3: Regional ITS Planning

Section 3 describes planning for ITS applications and formulating ITS projects in a
regional context.

1-12
 Developing Traffic Signal Control Systems Using the National ITS Architecture

√ Using the National ITS Architecture provides a good starting point for developing a
regional architecture in the transportation planning arena.

√ Involving comprehensive representation of regional transportation stakeholders in

developing a regional architecture to address needs and problems can produce broad
cooperation.

√ Developing a regional architecture can guide development of ITS within a region and
produce agreement on roles and responsibilities, phasing considerations for
implementation of planned ITS capabilities, and regional agreements on technology
and standards thus promoting interoperability and higher levels of benefits.

Section 4: Lessons Learned / Best Practices

Section 4 provides advice on developing and implementing traffic signal control ITS
projects using lessons from agencies that have developed and implemented ITS systems,
or are currently developing and implementing ITS projects. Information is provided on
various topics in ITS relevant to the deployment of traffic signal control systems.

Section 5: How Do I Find Out More?

Sections 5 shows readily accessible places to find additional information on ITS, the
National ITS Architecture, and ITS Standards.

References
These references pages provide a brief listing of references that may be important to
those involved in any of the key roles or activities involved in planning, development and
deployment of a traffic management system.

Appendices
Finally, this document contains four appendices: Appendix A discusses ITS Standards;
Appendix B provides a Glossary; Appendix C presents the Physical Architecture Data
Flows Associated With traffic signal control systems; and Appendix D is a synopsis of
each of the 16 volumes that make up the National ITS Architecture documentation.

√ ITS Standards described in Appendix A are those applicable to traffic signal control
systems. ITS standards have been and are being developed to support the integration
of transportation systems. ITS standards should be used to help ensure
interoperability of ITS subsystems and devices plus interchangeability of like devices

√ Physical Architecture Data Flows listed in Appendix C indicate the information that is
intended by the National ITS Architecture to flow across interfaces of traffic signal
control systems with other transportation systems, including traffic signal control
systems in adjacent jurisdictions.

1-13
 Developing Traffic Signal Control Systems Using the National ITS Architecture

2. Use of the National ITS Architecture Tools in

Traffic Signal Control Projects
2.1 Overview
This chapter presents the details of how the National ITS Architecture can be applied to traffic
signal control project development activities. An overview of traffic signal control system
operations and a general project development process is presented first to establish the context
for this chapter. Next, the key concepts of the National ITS Architecture are discussed to ensure
that the reader understands the fundamentals and structure of the tool. The following section then
shows how to apply the National ITS Architecture concepts and databases to the various steps
presented in the general project development process. Lastly, a set of three project application
scenarios are presented which use realistic examples to illustrate the points made in the previous
sections.

2.2 Traffic Signal Control System Operations

Traffic signal control systems benefit the public with improved traffic flow by optimizing available
capacity on surface streets. They achieve this by providing control of traffic by adjusting and
coordinating traffic signals at intersections; surveillance by monitoring traffic conditions with
vehicle detectors and cameras; and maintenance of equipment by monitoring for equipment
failures.

These functions allow a public agency to service traffic demand, share traffic status with other
agencies and with the traveling public, and operate and maintain the traffic signal control system.

Traffic Signal Control System Configurations

Computerized traffic signal control systems have been in place for the past three decades, and it
is not uncommon to find signal systems in operation that are more than 20 years old. Historically,
traffic control system configurations have clustered around the three basic design alternatives
listed below:

♦ Central (Urban Traffic Control System–UTCS)

♦ Interconnected Time Base Coordinated without Field Master (two level distributed control)

♦ “Closed Loop”System with Field Masters (three level distributed control)

It is important to note that the National ITS Architecture and the ITS standards development
efforts underway are compatible with these control alternatives. The advent of ITS and the
National ITS Architecture does not jeopardize any current investments in existing traffic signal
control systems. As long as they provide the desired functionality, controllers, field devices, and
other system components do not have to be replaced until they have reached their useful life.

2-1
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Ultimately, your agency may want to replace or change controller technology to accommodate ITS
standards. The National Transportation Communications for ITS Protocol (NTCIP) is an example
of such a standard. In the future, NTCIP standards are expected to ensure the compatibility of
communications protocols among the National Electrical Manufacturer’s Association (NEMA)
type (TS-1 and TS-2) and 170 type (Models 170, 179, and 2070) controllers.

Components of a typical traffic signal control system include a control center, system software,
centralized computer hardware, signal controllers, on-street masters, a communications system,
vehicle detection and surveillance, and other field devices to support various other functions
particular to an area. Together the central, field, and communications equipment provide the
control, surveillance, and maintenance functions associated with traffic control systems.

2.2.1 Control and Coordination of Traffic Signals

Traffic signal control systems enable an agency to implement a variety of control strategies.
Common strategies include operating signals so as to minimize overall vehicle delay or providing
preferential treatment in a direction of travel. These strategies are often implemented from a
central or remote location.

Traffic signal control systems allow an agency to coordinate surface street traffic flow along an
arterial, or for a group of intersections, by controlling the signal timing at individual signal
controllers. Many traffic signal systems select signal timing patterns based on a time-of-day/day-
of-week schedule. Rudimentary traffic signal controllers are pre-timed; that is, the cycle lengths,
signal phasing, and splits are fixed. These signal parameters are not determined by the existing
demand or the type of vehicles at the traffic signal; they are determined by historical traffic
demand data. Although the pre-selected patterns are optimized for typical traffic flow conditions,
traffic signal control systems allow operators to select alternate signal timing plans more
appropriate for the actual traffic demand and traffic flow conditions. These adjustments are
generally necessary to accommodate non-recurring events, such as traffic accidents, sporting
events, concerts, or inclement weather.

In more sophisticated traffic signal control systems, the traffic flow information collected by
surveillance equipment allows master controllers or central computers to run traffic responsive
control programs. Thus, control of traffic signals can be adjusted automatically (without the need
for operator input) to service actual traffic demand in the network.

2.2.2 Surveillance and Monitoring of Traffic

Most traffic signal systems include traffic detection and surveillance equipment. Often the
monitoring equipment is connected to traffic signal controllers (either through a module or
separate field unit). The most common type of detection device used today is the inductive loop
vehicle sensor which allows the traffic signal controller to provide semi-actuated or fully actuated
control to the intersection. Traffic flow information provided by the detection devices includes
traffic speed, volume, and occupancy.

2-2
 Developing Traffic Signal Control Systems Using the National ITS Architecture

An emerging trend in traffic signal control systems is the use of closed-circuit television (CCTV)
cameras on roadways and at major intersections. These cameras allow operators in a central
control center to directly monitor traffic, and traffic managers to monitor road conditions, identify
and verify incidents, and verify traffic information collected through other methods.

2.2.3 Monitor Faults and Malfunctions

A traffic signal control system monitors equipment for faults or malfunctions that may affect the
system’s or controller’s ability to properly control traffic flow through an intersection. Such
malfunctions might include a signal head indicator failure, detector failure, conflict in signal
indications, a broken communications link, or a power failure in a field device. Once the location
of the problem has been identified, the proper personnel can be dispatched to repair the problem
and return the equipment to its proper operating condition. The objective of monitoring is to
identify system and equipment operational problems and initiate corrective actions and repair
responses to return the equipment to its proper operating condition as quickly as possible in order
to keep traffic flow interruptions to a minimum.

2.3 Development of Traffic Signal Control Projects

Transportation agencies go through a variety of steps and processes in developing and deploying
transportation improvement projects. The nature and level of formality of these processes
depends on the scope of the project, state and local procedures, funding requirements, and
legislative requirements, among other things. However, there are certain fundamental steps that
are fairly common across these processes. These basic steps include:

1) Identification of transportation needs or problems

2) Identification of potential solutions to the problem

3) Planning and design of solutions to the problem

4) Funding, procurement, and implementation of the solution to the problem

Each step of this development process is briefly described below as it relates to transportation
issues that agencies or public works departments involved with traffic signal control may
experience.

2.3.1 Identification of Needs or Problems

Typically the first step an agency takes in developing and implementing a project is the
identification of existing transportation needs, objectives, or problems. These may be identified
through a number of activities, whether through a traditional transportation planning process,
public questionnaire, a problems/needs identification study, or an ITS Early Deployment Planning
(EDP) process. For example, an agency may identify a particular arterial corridor with several

2-3
 Developing Traffic Signal Control Systems Using the National ITS Architecture

intersections that has frequent delays due to traffic volumes and an unusually high rate of
incidents.

2.3.2 Identification of Solutions

Based on the identified problem, in this example delays on a section of arterial with a high
occurrence of incidents, the agency will identify potential solutions to the problem. Potential
solutions to this particular problem may include:

♦ Implementing a traffic responsive signal control system that can respond to changes due
to incidents

♦ Establishing more service patrols for quicker incident response

♦ Implementing CCTVs at key locations for quicker, more accurate detection, verification,
and response to incidents

♦ Developing and implementing a cellular call-in solution

When evaluating the potential solutions, it is important to keep in mind institutional considerations
and implications for operations and maintenance.

2.3.3 Planning and Design of the Solution

Once an optimal solution to the problem has been identified, the agency typically begins a process
of planning and designing the solution or system. The planning phase may include activities such
as determining implementation and phasing strategies, and identifying and securing of funding
sources. The design phase may include activities such as preparing detailed specifications (for
hardware, software and communications) and designing systems configurations.

2.3.4 Funding, Procurement and Implementation

Once the agency has identified the most feasible solution to the transportation challenge, the
system or portion of a system is procured. The traditional approach to procurement is a two-step
process: (1) the letting and completion of a contract to retain architect/engineering services to
prepare detailed design specifications for the facility and (2) the letting and completion of a
separate contract for the construction of the project. Due to the rapidly changing and
technological nature of ITS, the system manager approach to procurement can also be used. In
this case, the system manager performs the design and writes the specifications. The hardware
and construction is bid in the conventional manner, but the system manager remains to develop
the software, integrate all the different components, and provide documentation and training for
the operating personnel. See section 4 for a discussion of these and other procurement
alternatives.

2-4
 Developing Traffic Signal Control Systems Using the National ITS Architecture

A successful process will result in the desired objectives ( which respond to the problems and
needs that are identified in the first step) being satisfied by the implemented system. Successful
operations of the system (often overlooked during the project development process) over a
sustained period of time is the true indicator of how well the overall process worked.

2.4 Key Concepts of the National ITS Architecture

The National ITS Architecture is available as a resource for any region and will continue to be
maintained by the U.S. DOT independently of any specific system design or region in the nation. It
represents the work and collective thinking of a broad cross-section of the ITS community
(systems engineers, transportation practitioners, technology specialists, system developers,
consultants, etc.) over several years. As such, the National ITS Architecture contains material
that will assist agencies at each step of project development (which will be presented next in
section 2.5) and in thinking about how an individual project, such as a traffic signal control project,
fits into a larger regional transportation management context (to be discussed further in section
3).

Because of the extensive geographic and functional scope of the National ITS Architecture and
the requirements which drove its development, it is structured somewhat differently and uses
different terminology than is typically used today in the transportation community. It was developed
to support ITS implementations over a 20-year time period in urban, interurban, and rural
environments across the country. Accordingly, general names were given to the physical
transportation system components and locations in order to accommodate a variety of local
design choices and changes in technology or institutional arrangements over time. This allows the
general structure of the National ITS Architecture to remain stable while still allowing flexibility and
tailoring at the local implementation level. This difference in language can be easily overcome with
a better understanding of how the National ITS Architecture is organized and how it relates to
familiar systems of today.

As background, this section explains the essential terminology and concepts needed to
understand, navigate, and use the National ITS Architecture and then provides a summary of the
key documents produced under the National ITS Architecture development effort which will be
referred to in the next section. The portions of the material which are particularly relevant to traffic
signal control are also highlighted. The reader who is already familiar with the National ITS
Architecture may wish to skip ahead to the next section for information on how to use this
information and methodology in the context of project development. The following concepts and
terms are explained in this section:

♦ User Services and User Service Requirements (2.4.1)

♦ Logical Architecture (2.4.2)

♦ Physical Architecture (2.4.3)

♦ Equipment Packages (2.4.4)

2-5
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Market Packages (2.4.5)

2.4.1 User Services and User Service Requirements

User services represent what the system will do from the perspective of the user. A user might
be the public or a system operator.

Table 2.4-1 presents the 30 user services which formed the basis for the National ITS
Architecture development effort, grouped into seven bundles for convenience. These user
services were jointly defined by a collaborative process involving USDOT and ITS America with
significant stakeholder input. Clearly, a different set could have been defined. The important
point is that the concept of user services allows the process of system or project definition to
begin by thinking about what high level services will be provided to address identified problems and
needs. The bolded entries in the table are most relevant to traffic signal control systems.

A number of functions are required to accomplish each user service. To reflect this, each of the
user services was broken down into successively more detailed functional statements, called
user service requirements, which formed the fundamental requirements for the National ITS
Architecture development effort. For example, the traffic control user service is actually defined
by over 40 “functions”(the hierarchy of functional requirements makes it difficult to provide an
exact number). In the Traceability Matrix of the National ITS Architecture documentation, the user
service requirements can be reviewed. Many of these user service requirements can be
implemented today, although some of them may be more representative of future capabilities and
should be deferred for now. These requirements can be used as a departure point for the
development of project functional requirements and system specifications, as will be discussed in
section 2.5.

2-6
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Table 2.4-1. User Services for the National ITS Architecture

User Service Bundle User Service

Travel and Transportation En-Route Driver Information
Management Route Guidance
Traveler Services Information
Traffic Control
Incident Management
Emissions Testing and Mitigation
Highway-Rail Intersection
Travel Demand Management Pre-Trip Travel Information
Ride Matching and Reservation
Demand Management and Operations
Public Transportation Operations Public Transportation Management
En-Route Transit Information
Personalized Public Transit
Public Travel Security
Electronic Payment Services Electronic Payment Services
Commercial Vehicle Operations Commercial Vehicle Electronic Clearance
Automated Roadside Safety Inspection
On-Board Safety Monitoring
Commercial Vehicle Administrative Processes
Hazardous Material Incident Response
Commercial Fleet Management
Emergency Management Emergency Notification and Personal Security
Emergency Vehicle Management
Advanced Vehicle Control and Longitudinal Collision Avoidance
Safety Systems Lateral Collision Avoidance
Intersection Collision Avoidance
Vision Enhancement for Crash Avoidance
Safety Readiness
Pre-Crash Restraint Deployment
Automated Highway Systems

Table 2.4-2 provides an illustration of user service requirements using an excerpt from the traffic
control user service.

2-7
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Table 2.4-2. Example of User Service Requirements: Excerpt from Traffic Control

1.6.0 (ITS) shall provide a Traffic Control capability. Traffic Control provides the capability to efficiently manage the movement
of traffic on streets and highways. Four functions are provided which are (1) Traffic Flow Optimization, (2) Traffic Surveillance,
(3)Control Function, and (4) Provide Information. This will also include control of network signal systems with eventual integration
of freeway control.

1.6.1 Traffic Control shall include a Flow Optimize function to provide the capability to optimize traffic flow.
[Link] The Flow Optimize function shall employ control strategies that seek to maximize traffic-movement efficiency.
[Link] The Flow Optimize function shall include a Wide Area optimization capability, to include several jurisdictions.
[Link].1 Wide area optimization shall integrate the control of network signal systems with the control of freeways.
[Link].2 Wide area optimization shall include features that provide preferential treatment for transit vehicles.

1.6.2 Traffic Control shall include a Traffic Surveillance function.

2.4.2 Logical Architecture

A logical architecture is best described as a tool that assists in organizing complex entities and
relationships. It focuses on the functional processes and information flows of a system.
Developing a logical architecture helps identify the system functions and information flows, and
guides development of functional requirements for new systems and improvements. A logical
architecture should be independent of institutions and technology, i.e., it should not define where
or by whom functions are performed in the system, nor should it identify how functions are to be
implemented.

The logical architecture of the National ITS Architecture defined a set of functions (or processes)
and information flows (or data flows) that respond to the user service requirements discussed
above. Processes and data flows are grouped to form particular transportation management
functions (e.g., manage traffic) and are represented graphically by data flow diagrams (DFDs), or
bubble charts, which decompose into several levels of detail. In these diagrams, processes are
represented as bubbles and data flows as arrows. Figures 2.4-1 and 2.4-2 depict simplified data
flow diagrams from the National ITS Architecture documents. Note that each bubble in the logical
architecture is a process that describes some logical function to be performed.

2-8
 Developing Traffic Signal Control Systems Using the National ITS Architecture

For example, as shown in figure 2.4-1, at the highest level of the National ITS Architecture, the
manage traffic process (which includes traffic signal control functions) interacts with seven other
processes.

Manage
Emergenc Manage
Provide y
Driver Services
Commercial
and Vehicles
Traveler

Provide
Plan System
Electronic Deployment
Payment and
Services Implementation

Provide
Vehicle Manage
Monitoring Manage
and Control Traffic Transit

Figure 2.4-1 The Eight Major Processes within the Logical Architecture

Figure 2.4-2 illustrates how the manage traffic process is then further broken down into five sub-
processes; how one of those processes, Provide Traffic Surveillance, is broken down into seven
sub-processes; and so on. Each of these processes are then broken down even further so that a
complete functional view of a system emerges. At the lowest level of detail in the functional
hierarchy are the process specifications (referred to as P-specs in the documentation). Figure
2.4-2 shows an example of a process specification (Process Traffic Data) within the functional
decomposition. These process specifications can be thought of as the elemental functions to be
performed in order to satisfy the user service requirements (i.e., they are not broken out any
further). The information exchanges between processes and between P-specs are called the
(logical) data flows.

2-9
 Process Specification
(See Table 2.4-3)

Process
Traffic Data
[Link] Exchange
Process Data with Manage
and Store Other Traffic Travel
Data Centers Demand
Process
Traffic Data Provide
Update for Storage Traffic
Surveillance
Data Source
Static
Manage
Data Generate Incidents
Predictive
Process Traffic
Process Traffic Model
Sensor Provide
Tag Data
Device
Monitor for Link Data Control
HOV Lane Manage
Time Data
Emissions
Use Display
Process Collect and Output
Collect Traffic
Collected Vehicle Vehicle Tag
Vehicle Smart Data
Smart Probe Data for
Probe Data
Data Link Time
Calculations Data Flow Diagram (DFD 1) Manage Traffic

Data Flow Diagram (DFD 1.1) Provide Traffic Surveillance

Data Flow Diagram (DFD 1.1.2) Process and Store Data

Decomposition Flow to the P-Spec Level

Figure 2.4-2. Example of Logical Architecture Functional Decomposition

 Developing Traffic Signal Control Systems Using the National ITS Architecture

Example overview descriptions of process specifications relevant to traffic signal control systems
are given below:

Table 2.4-3. Example Process Specifications (Overview Descriptions)

Process Traffic Data ( P-Spec [Link] )

Overview: This process shall be responsible for collecting all of the processed data supplied from traffic sensors and from sensors at HRIs.
The process shall distribute it to processes in the Provide Device Control facility responsible for freeway, highway rail intersections, parking
lot, ramp and road management. It shall also send the data to another process in the Provide Traffic Surveillance facility for loading into the
stores of current and long term data.

Select Strategy ( P-Spec 1.2.1 )

Overview: This process shall be responsible for selecting the appropriate traffic control strategy to be implemented over the road and freeway
network served by the Manage Traffic function. The strategy shall be selected by the process from a number that are available, e.g. adaptive
control, fixed time control, local operations, etc. The selected strategy shall be passed by the process to the actual control processes for
implementation according to the part of the network to which it is to be applied, i.e. roads, freeways, ramps and parking lots. When part of the
selected strategy, or at the request of the traffic operations personnel, the process shall send commands to the traffic sensor data process to
change the operating parameters of video cameras used to provide traffic data. The process shall make it possible for the current strategy
selection to be modified to accommodate the effects of such things as incidents, emergency vehicle green waves, the passage of commercial
vehicles with unusual loads, equipment faults and overrides from the traffic operations personnel. The selected strategy shall be sent to the
process within the Provide Traffic Surveillance facility responsible for maintaining the store of long term data.

Determine Indicator State for Road Management ( P-Spec [Link] )

Overview: This process shall be responsible for implementing selected traffic control strategies and transit priority on some or all of the
indicators covering the road (surface street) network served by the Manage Traffic function. It shall implement the strategies only using the
indicators (intersection and pedestrian controllers, variable message signs (vms), etc.) that are specified in the implementation request and
shall coordinate its actions with those of the processes that control the freeway network and the ramps that give access to the freeway network.

Output Control Data for Roads ( P-Spec [Link] )

Overview: This process shall be responsible for the transfer of data to processes responsible for controlling equipment located at the roadside
within the road (surface street) network served by the Manage Traffic function. This data shall contain outputs for use by roadside indicators,
such as intersection and pedestrian controllers, variable message signs (vms), etc. Data for use by in-vehicle signage equipment shall be sent to
another process for output to roadside processes. All data shall have been sent to this process by processes within the Manage Traffic function.
This process shall also be responsible for the monitoring of input data showing the way in which the indicators are responding to the data that
they are being sent, and the reporting of any errors in their responses as faults to the Collect and Process Indicator Fault Data facility within the
Manage Traffic function. All output and input data shall be sent by the process to another process in the Manage Traffic function to be loaded
into the store of long term data.

2.4.3 Physical Architecture

A physical architecture is the physical (versus functional) view of a system. A physical
architecture provides agencies with a physical representation (though not a detailed design) of
how the system should provide the required functionality. A physical architecture takes the
processes (or P-specs) identified in the logical architecture and assigns them to physical entities
(called subsystems in the National ITS Architecture). In addition, the data flows (from the logical
architecture) that originate from one subsystem and end at another are grouped together into
(physical) architecture flows. In other words, one architecture flow may contain a number of more
detailed data flows. These architecture flows and their communication requirements define the
interfaces required between subsystems, which form the basis for much of the ongoing standards
work in the ITS program. Development of a physical architecture will identify the desired
communications and interactions between different transportation management organizations.
Figure 2.4-3 depicts the relationship between the logical and physical architecture.

2-11
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Logical Architecture - Dataflows

What has to be done Function Function
(functions) A C
Function
B
Function
D

Physical Architecture - Interface

Subsystem A Subsystem B
(Group functions
together)

Figure 2.4-3 Representative Logical and Physical Architecture

In the National ITS Architecture, the physical architecture is described by two layers: the
transportation layer and the communications layer. Each of these is briefly described below.

Transportation Layer

The transportation layer of the physical architecture shows the relationships among the
transportation-management-related elements. It is composed of subsystems for travelers,
vehicles, transportation management centers, and field devices, as well as external system
interfaces at the boundaries (called terminators in the documentation). It may include:

♦ Field devices for traffic surveillance and motorist information dissemination

♦ Traffic signal and ramp metering controllers

♦ Transportation management centers

♦ Emergency management centers

Communications Layer

The communications layer of the physical architecture shows the flow of information and data
transfer for the transportation layer components. This layer depicts all of the communications
necessary to transfer information and data among transportation entities, traveler information and
emergency service providers, and other service providers such as towing and recovery. The
communications layer clearly identifies system interface points where national standards and
communications protocols can be used.

Institutional Implications

While an institutional layer is not actually part of the physical architecture, the physical
architecture cannot be fully defined in a region without some decisions being made regarding the
jurisdictional structure and working relationships that will provide a framework for ITS planning and
implementation. These institutional decisions should lead to depiction of who should communicate

2-12
 Developing Traffic Signal Control Systems Using the National ITS Architecture

with whom, and what information should be communicated in the transportation and
communications layers, and will vary based on the unique needs and characteristics of a region.

Figure 2.4-4 from the National ITS Architecture, shows the 19 transportation subsystems (white
rectangles) and the 4 general communication links (ovals) used to exchange information between
subsystems. This figure represents the highest level view of the transportation and
communications layers of the physical architecture. The subsystems roughly correspond to
physical elements of transportation management systems and are grouped into 4 classes (gray
rectangles): Centers, Roadside, Vehicles and Travelers.

Travelers Centers

Fleet and Freight Management

Information Service Provider

Emergency Management
Emissions Management

Commercial Veh Admin

Transit Management
Traffic Management

Toll Administration
Remote Traveler
Support

Planning
Personal Information
Access

Wide Area Wireless

Wireline Communications
Communications
Dedicated Short Range

Roadside
Vehicle to Vehicle
Communications

Vehicle Roadway
Communications

Transit Toll Collection

Commercial Parking Management

Emergency Commercial Vehicle Check

Vehicles

Figure 2.4-4. National ITS Architecture Subsystems and Communications

Basic traffic signal control systems are represented by functions within 2 of the 19 subsystems:
the Traffic Management subsystem and the Roadway subsystem. This is illustrated in figure 2.4-
5, which depicts traffic signal control related elements as an overlay to the diagram just
presented.

2-13
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Traffic Management Subsystem

Traffic Management Center

Roadway Subsystem

Signal Control
Central Computer
System
Communications

Controller
Cabinet
Travelers Centers
Fleet and Freight Management
Information Service Provider

Emergency Management

Loops
Emissions Management

Commercial Veh Admin

Transit Management
Traffic Management

Toll Administration

Remote Traveler
Support
Surveillance
Planning

Personal Information
Access

Wide Area Wireless

Wireline Communications
Communications
Dedicated Short Range

Roadside
Vehicle to Vehicle
Communications

Vehicle Roadway
Communications

Transit Toll Collection

Commercial Parking Management

Emergency Commercial Vehicle Check

Vehicles

Figure 2.4-5. Basic Traffic Signal Control System Architecture Depiction

These 2 subsystems, together with the necessary communications to exchange control and
surveillance information, provide the following capabilities typically associated with traffic signal
control systems:

♦ Area-wide signal coordination

♦ Arterial network traffic conditions

♦ A range of adaptive control strategies

♦ Integration with freeway management, incident and emergency management, transit

management, etc.

2-14
 Developing Traffic Signal Control Systems Using the National ITS Architecture

The Traffic Management subsystem functions are implemented with central equipment typically
found in traffic management centers; e.g., computers, traffic control consoles, and video switching
and display systems.

The Roadway subsystem functions are implemented with equipment typically found in the field;
e.g. traffic signal controllers and traffic lights, vehicle detectors (e.g., inductive loop, radar, video),
and video cameras.

Wireline Communications includes the equipment necessary for the various subsystems of the
architecture, including the Traffic Management and Roadway subsystems, to exchange data to
perform their transportation functions. These communications services may be provided by
agency-owned communications plants (e.g. twisted pair, coaxial, fiber, or spread-spectrum radio),
or may be leased from a communications service provider. It should be noted that the term
“wireline communication”as used in the National ITS Architecture, refers to communication
between stationary points, (e.g. traffic signal control central and field equipment). In this context,
wireline communication may include wireless communication.

The Traffic Management and Roadway subsystems also provide other functions not typically
associated with traffic signal control systems. These include the following transportation system
functions:

Freeway Management Systems

♦ Monitor Freeway Conditions

♦ Identify Flow Impediments

♦ Ramp Metering/Lane Controls

♦ Highway Advisory Radios/Variable Message Signs

Incident Management Systems

♦ Incident Detection/Verification

♦ Incident Response/Clearance

Railroad Grade Crossing Systems

♦ Improve and automate Highway-Railroad Intersection warnings and Traffic Signal Control

♦ Provide advanced warning of closures

♦ Coordinate traffic signal control with rail movements

An important concept to understand from the physical architecture is that of support for combining
subsystems together (or functionality from multiple subsystems) in an actual implementation. This

2-15
 Developing Traffic Signal Control Systems Using the National ITS Architecture

is particularly important for the “center”subsystems, which should not be immediately thought of
as separate buildings. In simplest terms, the center subsystems are not “brick and mortar”. Each
subsystem is a cohesive set of functional definitions with required interfaces to other subsystems;
subsystems are functionally defined, not physically defined. A regional implementation may
include a single physical center that collocates and integrates the capabilities from several of the
center subsystems. For instance, a single Transportation Management Center may include
Traffic Management Subsystem, Transit Management Subsystem, Emergency Management
Subsystem, and Information Service Provider subsystem capabilities. Conversely, a single
subsystem may be replicated in many different physical centers in a complex metropolitan area
system. For instance, the traffic management subsystem may be implemented in a traffic
management center for freeway control in addition to several distinct city traffic management
centers that cooperatively control the arterials. Figure 2.4-6 provides an indication of the range
of ways that center subsystems may be implemented in physical centers.

Center Subsystems
Information Transit
Service Management
Provider Subsystem
: Subsystem
: Physical
Center Traffic Emergency
Management Management
Subsystem Subsystem

Sample Implementations
Information Transit Information Transit
Service Management Service Management
Provider Subsystem Provider Subsystem

Traffic Emergency Traffic Emergency

Management Management Management Management
Subsystem Subsystem Subsystem Subsystem
Co-located in Single Center Distributed Across Multiple Centers

Figure 2.4-6. Center Subsystems May Be Implemented In Various Regional

Configurations
(Source: National ITS Architecture Implementation Strategy)

2-16
 Developing Traffic Signal Control Systems Using the National ITS Architecture

2.4.4 Equipment Packages

The logical and physical architectures contain all of the essential architecture elements needed
to provide the user services (and their more detailed requirements). Although the formal
definition of the National ITS Architecture stops there, other categorizations of the architecture
elements were made for the purposes of evaluation and to better understand the deployment
implications. Sections 2.4.4 and 2.4.5 discuss the alternative views gained by grouping sets of
key functionality together. These perspectives, which are grounded in (or tied back to) the formal
definition, can be used as additional entry points into the National ITS Architecture.

The term “equipment package” was used in the National ITS Architecture development effort to
group like functions (P-specs) of a particular subsystem together into an “implementable”
package of hardware and software capabilities. The grouping of functions also took into account
the user services and the need to accommodate various levels of functionality within them. The
equipment packages are associated closely with market packages (which will be discussed next)
and were used as a basis for estimating deployment costs (as part of the evaluation that was
performed). The specific set of equipment packages defined is merely illustrative and is does not
represent the only way to combine the functions within a subsystem. The National ITS
Architecture has defined approximately 110 equipment packages in total; only about 25 of these
are relevant to traffic signal control.

An example of an equipment package that is relevant to traffic signal control is “TMC Basic Signal
Control”, which is comprised of 3 process specifications: Select Strategy, Determine Indicator
State for Road Management, and Output Control Data for Roads.

TMC Basic Signal Control Equipment Package (part of the Traffic Management Subsystem):

This Equipment package provides the capability to traffic managers to monitor and manage the traffic flow in major
intersections and on main highways for urban areas as well as alleviate traffic related problems of rural areas with the
primary concern of detecting and verifying incidents and providing this information to emergency management
service providers. This capability includes analyzing and reducing the collected data from traffic surveillance
equipment as feedback to control processes and for control strategies.

This equipment package consists of the following P-specs:

1.2.1 Select Strategy
[Link] Determine Indicator State for Road Management
[Link] Output Control Data for Roads

2.4.5 Market Packages

Some of the 30 user services are too broad in scope to be convenient in planning actual
deployments. Additionally, they often don’t translate easily into existing institutional environments
and don’t distinguish between major levels of functionality. In order to address these concerns (in
the context of providing a more meaning evaluation), a finer grained set of deployment-oriented
ITS service building blocks were defined from the original user services. These are called
“market packages”in the documentation.

2-17
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Market packages are defined by sets of equipment packages required to work together (typically
across different subsystems) to deliver a given transportation service and the major architecture
flows between them and other important external systems. In other words, they identify the
pieces of the National ITS Architecture required to implement a service. As such, they are
directly grounded in the definition of the Architecture. Most market packages are made up of
equipment packages in two or more subsystems. Market packages are designed to address
specific transportation problems and needs and can be related back to the 30 user services
(reference table 2.3-2 in the Implementation Strategy document) and their more detailed
requirements.

For example, the functionality of the broad user service named “traffic control” was broken up into
several market packages to allow for explicit consideration of:

♦ basic functions (such as surveillance, which is represented by the “network surveillance”

and “probe surveillance”market packages),

♦ institutional settings (by separating control functions typically performed by different

agencies into the “surface street control”and “freeway control”market packages), and

♦ functional levels of service (by including a “regional traffic control”market package that
provides for coordination of control strategies across jurisdictions).

In addition, a “multi-modal coordination”market package was defined that is comprised of

functionality for transit and emergency vehicle priority treatment at traffic signals.

Figure 2.4-7 provides an example of a market package related to traffic signal control and figure
2.4-8 explains the basic elements of the market package diagrams.

Surface Street Control (ATMS3)

This market package provides the communication links and the signal control equipment for local
surface street control and/or arterial traffic management control. An example would be arterial
signalization control. This market package is considered an intra-jurisdictional package since
coordination between adjacent cities is required to coordinate signal control along arterials. This
package is consistent with typical urban traffic signal control systems.

Traffic
M anagement signal control data Roadway
TMC Basic Signal
Control
Roadway
signal control status Signal Controls
Traffic
Maintenance

Figure 2.4-7. Surface Street Control Market Package

(Adapted From Appendix A of the Implementation Strategy)

2-18
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Subsystem contains equipment package(s) included in

Information
Service Provider market package.
Basic Information
Broadcast
Equipment package included in the market package.

Subsystem that participates in market package operation through

Traffic
Management data sharing.

Destination or source of information that participates in market

External package operation.
Source

Information flows that support market package operation.

Figure 2.4-8. Market Package Elements

(Adapted From Appendix A of the Implementation Strategy)

The National ITS Architecture development effort identified a total of 56 market packages that
reflect the current definition of ITS and the evolving technology market. Table 2.4-4 contains a
complete listing of these, grouped according to their respective major application areas. As with
equipment packages, the specific set of market packages defined is merely illustrative and does
not represent the only way to combine the functions and equipment in order to provide ITS
services. The market packages most closely related to traffic signal control are highlighted in the
table.

A given market package may provide only part of the functionality of a user service (supporting
multiple service levels), but often serves as a building block by allowing more advanced packages
to use its components. Market packages also allow early deployments to be separated form
higher risk services and can specifically address varied regional needs. Because they were
evaluated during the development process, supporting benefits and costs analyses were
conducted for the market packages which can also be accessed as a resource.

Market packages are not intended to be tied to specific technologies, but of course depend on the
current technology and product market in order to actually be implemented. As transportation
needs evolve, technology advances, and new devices are developed, market packages may
change and new market packages may be defined.

In short, market packages provide another method for entering into the National ITS Architecture
information and can be used as an alternative starting point for defining project functional
requirements and system specifications. The important point to remember is that they provide a
set of manageable, service-oriented views which allow the user to jump right into the physical
architecture definition.

2-19
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Table 2.4-4. ITS Market Packages

Traffic Management Advanced Vehicles

Network Surveillance Vehicle Safety Monitoring
Probe Surveillance Driver Safety Monitoring
Surface Street Control Longitudinal Safety Warning
Freeway Control Lateral Safety Warning
HOV and Reversible Lane Management Intersection Safety Warning
Traffic Information Dissemination Pre-Crash Restraint Deployment
Regional Traffic Control Driver Visibility Improvement
Incident Management System Advanced Vehicle Longitudinal Control
Traffic Network Performance Advanced Vehicle Lateral Control
Evaluation
Dynamic Toll/Parking Fee Management Intersection Collision Avoidance
Emissions and Environmental Hazards Automated Highway System
Sensing
Virtual TMC and Smart Probe Data
Standard Railroad Grade Crossing Commercial Vehicles
Advanced Railroad Grade Crossing Fleet Administration
Railroad Operations Coordination Freight Administration
Electronic Clearance
Transit Management Commercial Vehicle Administrative Processes
Transit Vehicle Tracking International Border Electronic Clearance
Transit Fixed-Route Operations Weigh-In-Motion
Demand Response Transit Operations Roadside CVO Safety
Transit Passenger and Fare Management On-board CVO Safety
Transit Security CVO Fleet Maintenance
Transit Maintenance HAZMAT Management
Multi-modal Coordination
Emergency Management
Traveler Information Emergency Response
Broadcast Traveler Information Emergency Routing
Interactive Traveler Information MAYDAY Support
Autonomous Route Guidance
Dynamic Route Guidance ITS Planning
Information Service Provider (ISP) Based ITS Planning
Route Guidance
Integrated Transportation
Management/Route Guidance
Yellow Pages and Reservation
Dynamic Ridesharing
In-Vehicle Signing

2.4.6 National ITS Architecture Documents

In summary, the National ITS Architecture provides a common structure for the design of ITS; it
defines the functions that must be performed by components or subsystems, where these

2-20
 Developing Traffic Signal Control Systems Using the National ITS Architecture

functions reside (e.g., roadside, traffic management center, or in-vehicle), the interfaces and
information flows between subsystems, and the communications requirements for the information
flows (e.g., wireline or wireless) in order to address the underlying user service requirements.
Since the National ITS Architecture is also the foundation for much of the ongoing ITS standards
work, consideration of the interface and information exchange requirements established by the
Architecture today will likely facilitate or ease the transition to incorporating standards-compliant
interfaces in the future (when approved standards are available).

The following are brief descriptions of the documents produced under the National ITS
Architecture Development Program that are referred to in subsequent sections. Paper copies of
these can be obtained and used as reference documents. Another way to access them is via
CD-ROM or on the Internet (see Section 5.1 of this document for information on how to obtain the
paper copies, the CD-ROM, and the Internet addresses). The CD-ROM and the Internet sites will
be more useful than hard copies when trying to access information rapidly. On the Internet,
logical links (called “hyperlinks”) between different parts of the architecture facilitate use of
information for the type of exercises described later in this section. The CD-ROM also contains
the underlying relational databases which define the Architecture (developed with Microsoft
Access TM), which can be useful for performing tailored searches or other advanced analyses. It is
important to remember that the key concepts and elements of the National ITS Architecture as
presented in sections 2.4.1-2.4.5 are interrelated and traceable in a variety of ways (forwards
and backwards).

Although the documentation at first can appear to be extensive, even overwhelming, keep in mind
that only a portion of the information will apply to the specific needs of an agency at any point in
time. Using the electronic tools with search capabilities and the linked HTML version of the
National ITS Architecture, finding the relevant information becomes even more manageable.

US DOT plans to update and maintain the National ITS Architecture over time to reflect changing
needs and correct any deficiencies that may be found through the experience of users.
Accordingly, critical portions of these documents, particularly those containing the Architecture
definition, will be updated over time (e.g., an update is planned for May 1998). Therefore, while
this document provides specific information and examples from the National ITS Architecture
(January 1997 version) for illustration purposes, the reader should always consult and defer to
the latest version of the National ITS Architecture. See
section 5 for more information on how to access the National ITS Architecture.

It is important to keep in mind that several of the documents that were produced were done so for
the purposes of evaluation; these documents can be used as additional resources (e.g., the Cost
Analysis) but are peripheral to the fundamental definition. A first time interested reader should find
the Executive Summary, Vision, and Implementation Strategy to be the most accessible starting
points for looking into the documentation. A complete listing of the documents can be found in
Appendix D.

2-21
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Vision
The vision is the starting point for developing an architecture and is the component that drives
everything else. The vision statement provides a description of the likely transportation system in
the next 5, 10, and 20 years based on the National ITS Architecture. In the vision, the ITS User
Services that the transportation system is to provide are identified in groups.

Mission
The Mission addresses the goals and objectives of a national intelligent transportation system. In
the Mission, user service requirements are defined, and benefits that the system is expected to
provide are identified. The mission definition ties the National ITS Architecture to the National ITS
Program Plan developed jointly by US DOT and ITS America.

Logical Architecture
The Logical Architecture document contains three volumes: Description (Volume 1), Process
Specifications (Volume 2), and Data Dictionary (Volume 3). These documents present a
functional view of the ITS user services, contain diagrams that show processes and data flows
among them, and define data elements, respectively.

Physical Architecture
The Physical Architecture document contains architecture flow diagrams that show data passing
among physical subsystems, and presents characteristics and constraints on the data flows.

Traceability
The Traceability document shows how the National ITS Architecture satisfies the user service
requirements. It contains tables that provide traceability of ITS user service requirements to
National ITS Architecture elements, and traceability between logical architecture elements and
physical architecture elements.

Theory Of Operations
This document provides a detailed narrative of how the architecture supports the ITS user
services, described in the Mission Definition. It is a technical document, intended for engineers,
operators, and others involved in detailed systems design.

Communications
The Communications document presents an analysis of the communications aspects of the
National ITS Architecture. It presents a technology assessment that covers several potential
communications technology alternatives. The alternatives are compared against ITS
requirements. This document proposes quantitative data loading requirements for a hypothetical
system design, and contains an extensive set of appendices that deal with a specific
communications study.

2-22
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Cost Analysis
The Cost Analysis provides typical unit costs for market packages and equipment packages.
Methodologies are delineated.

Performance and Benefits Study

The Performance and Benefits Study documents the results of evaluations of several hypothetical
ITS deployment scenarios. It also presents a discussion of the overall benefits of developing the
National ITS Architecture.

Standards Requirements
The Standards Requirements document contains detailed information on requirements for 12
high-priority standards packages. Standards interface packages that apply directly to traffic
signal control include:

♦ Traffic Management Center for Other Centers

♦ Traffic Management Center to Roadside Devices

♦ Digital map data exchange and location referencing

♦ Highway-Rail Intersections

♦ Signal priority for emergency and transit vehicles

Implementation Strategy
The Implementation Strategy document presents a process for implementing ITS services in a
phased approach. The process is part of an overall strategy that includes recommendations for
future research and development, operational tests, standards activities, and training.

The Implementation Strategy translates the National ITS Architecture to implementation through
market packages. It identifies the market packages that provide certain ITS services and
recommends a phased deployment of those market packages to provide the most needed and
most feasible user services initially, and less needed/feasible user services at a later date. The
Implementation Strategy considers several items and issues regarding deployment, such as
legacy systems, politics, funding, market package synergy, technology requirements, and
standards requirements.

2.5 Using the National ITS Architecture to Develop Traffic Signal

Control Projects
This section describes the specific ways that the National ITS Architecture can be used in each
of the general steps of the project development process presented in section 2.3, making use of
the key concepts described in section 2.4. This process addresses (1) needs or problem
identification, (2) solution identification, (3) solution planning and design, and (4) funding,

2-23
 Developing Traffic Signal Control Systems Using the National ITS Architecture

procurement, and implementation. Before discussing the specific ways it can be applied to the
project development process, some additional context and general guidance is provided below.

National ITS Architecture Application Guidance

The National ITS Architecture tools are intended to augment and support existing ITS project
development processes, and should be applied with engineering judgment in that context. The
National Architecture is not a process in and of itself. It contributes information and analysis to
existing processes (e.g., systems engineering). By providing a source for critical information early
in the development process, the National ITS Architecture can lower project risks and costs while
also improving the potential that the resulting deployment will have long term utility and support
regional ITS integration over time.

The National ITS Architecture tools are most applicable in the early stages of project
development. They fully support the rapid definition of a starting point for project definition, with
local requirements then driving the tailoring of that project for specific applications. Of course, the
tools do not contain all the information necessary to fully design and implement ITS projects.
While helpful information is sometimes available within the documentation (for example, in the
evaluation documents), specification of issues such as performance requirements, design
options, technology choices, existing system interfaces and constraints, detailed implementation
and operational decisions, and which standards to use needs to be carried out at the local level.
Awareness of how far into the project development process the National ITS Architecture tools
apply is important to being able to make the best use of them.

The National ITS Architecture can be used to provide project developers with additional options to
consider for information exchanges and functionality that may not have initially been conceived at
the outset of the project. As such, its utility is likely to be greater for larger projects with a variety
of possible interfaces. Using the National ITS Architecture should not be viewed as an all-or-
nothing requirement; rather, the material can be used as is, tailored, or dropped, as appropriate
for the situation. This will be discussed further in this section.

There are several ways to apply the National ITS Architecture; the most accessible of these
methods will be presented in this section. See section 5 for more information on how to gain
access to the various formats of the National ITS Architecture (including web sites).

Entry Points into the National ITS Architecture

The definition of the National ITS Architecture can be found in the logical and physical
architectures. These architecture definitions exist in several formats, including paper documents,
Microsoft Access TM relational databases, and a HyperText Mark-up Language (HTML) model,
which provides access through a linked model. The databases and the linked HTML model are
available on CD-ROM and the World Wide Web. The logical and physical architecture definitions
represent a breadth and depth of information that can seem overwhelming to access and apply.
However, there are tools to view the architecture definition that make the extraction of information
more efficient. These maps and tables provide access or “entry points”to the details of the
architecture in an organized fashion. Figure 2.5-1 shows the top-level of information shown for

2-24
 Developing Traffic Signal Control Systems Using the National ITS Architecture

the linked HTML model, which provides easy access to most of these entry points. Some of the
key entry points and their relevance to project development are discussed below.

ITS Architecture Browsing Site

January 1997 Edition

This presentation of the National Intelligent Transportation Systems (ITS) Architecture Definition
provides a hypertext view of the logical architecture, physical architecture, and
implementation-oriented components of the architecture definition. This hypertext view provides
access to all process specifications, data flows, subsystems, equipment packages, and terminators
that make up the architecture definition. Your entry to the architecture may be through a number of
different paths.

The National ITS Architecture was developed to support intelligent transportation systems extending
to the year 2012. The architecture Vision provides a general forecast of the ways in which
transportation improvements will be made over the next 20 years.

The architecture framework that supports this vision is made up of many physical entities
(Subsystems and Terminators ). By selecting a physical entity (either a subsystem or a terminator),
you can browse through the process specifications that define each subsystem’s functionality or the
data flows that connect the subsystems.

Near term plans and planned deployments include the Intelligent Transportation Infrastructure and
CVISN. The architecture structure for these near term deployments is provided in ITI and CVISN .

Another entry which is suitable for locally searching for data flows with particular text is a complete
file of Logical Architecture Data Flows (Note - this file is very big (200k bytes)) or Physical
Architecture Data Flows.

Yet another entry through the logical architecture is through the Pspec ( Process specification ) names.

Finally, a set of standards requirements packages has been created which bundle the dataflows into
sets of interest to standards organizations. The launch point for these packages is : Standards
Requirements packages (Cross references are provided for flows which reside in more than one
package).

The entire set of architecture documents are available on the ITS America Web Site .

Figure 2.5-1. National ITS Architecture Hypertext View

Note to the reader: As the National ITS Architecture is updated and maintained over time,
changes may be made to facilitate access to key information and allow greater flexibility for
the user. Thus, some of the specifics shown in figure 2.5-1 and the mechanics discussed in
subsequent text boxes for accessing the entry points may become dated. For example, in
future releases, it is likely that market packages will be given greater visibility at the top page
level of the HTML model.

♦ User Services are what drove the definition of the National ITS Architecture. They
represent high-level descriptions of the services to be provided by ITS, from the
perspective of the user. The National ITS Program Plan provides detailed descriptions of
the user services. User services can be related to general needs and higher-level goals
and objectives. Traceability exists to map user services to the underlying architecture

2-25
 Developing Traffic Signal Control Systems Using the National ITS Architecture

definition.

♦ User Service Requirements, as previously described in section 2.4.1, are the “shall”
statements that define the user services in detail and serve as the fundamental
requirements of the National ITS Architecture. By selecting those user service
requirements that apply to the definition of a specific system, traces can be made to the
physical and logical architectures. The user service requirements are listed in Appendix A
of the Traceability document on paper or CD-ROM.

♦ Logical Architecture describes “what” the National ITS Architecture must do to satisfy the
User Services by defining required functions and dataflows. These functions and
dataflows define the lower level details of the architecture. This tool is useful when
defining the functions required to satisfy a service, requirement, or need. It leverages the
extensive analysis already performed in the development of the National ITS Architecture.
It provides process specifications that can be tailored to fit local requirements. The logical
architecture is available on paper, CDROM, and the hyperlinked HTML model.

In the HTML model, click on “hypertext view”from the top page, then “Process
Specifications”(see figure 2.5-1) in order to see a list of the p-specs, which are organized
numerically according to their definition in the data flow diagram hierarchy. Or, you can click
on “Logical Architecture Data Flows”in order to see the alphabetized list of logical data flows
and get more information on them.

♦ Physical Architecture Elements are the subsystems and architecture flows that result
from a partitioning of the logical architecture. These subsystems and architecture flows
define a higher level of the architecture and can be aligned with high-level system functions
such as “traffic management”or “information service provider”. In this manner, a mapping
at the physical architecture subsystem level can be developed that provides the links to the
underlying logical architecture. The physical architecture is available on paper, CDROM,
and the linked HTML model.

In the HTML model, click on “hypertext view”from the top page, then “Subsystems and
Terminators”(see figure 2.5-1) in order to see a list of the subsystems, which are given
alphabetically. Clicking on one of the subsystems gives lots of information about the
subsystem, including a description, list of equipment packages it contains, corresponding
process specifications, and an architecture flow diagram. Some of these can be further
explored via additional links. You can also click on Physical Architecture Data Flows, as
shown on figure 2.5-1.

♦ Market Packages, as previously described in section 2.4.5, represent slices of the

architecture that address specific services such as surface street control. These physical
architecture subsets can be selected and aggregated to form a high-level architecture at
the subsystem level. The market packages can be traced further to equipment packages
and logical architecture functions. The market package definitions are available in the

2-26
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Implementation Strategy on paper and the CD-ROM, and also in the hyperlinked HTML
model.

In the HTML model, click on “hypertext view”from the top page, then “ITI and CVISN”(see
figure 2.5-1) in order to see a list of the market packages, which are organized into early,
additional, and advanced categories. Clicking on one of the market packages produces a
wealth of information on relevant subsystems, equipment packages, architecture flows,
related market packages, and evaluation information.

♦ ITS Infrastructure Elements are described in US DOT’s Operation Timesaver initiative

and define metropolitan, rural, and commercial vehicle infrastructure elements that form
the foundation of ITS. These elements represent high-level service categories (e.g.,
traffic signal control systems, freeway management systems, transit management
systems, multi-modal traveler information systems) that are mapped into the architecture.
This mapping provides the supporting architecture for the ITS Infrastructure in terms of the
logical and physical architecture.

Using the linked HTML model, a physical architecture flow diagram will be presented when
one of the ITS Infrastructure elements is clicked on (click on “hypertext view”from the top
page, then “ITI and CVISN”in order to see the ITS Infrastructure elements).

By using the CD-ROM with appropriate viewing software that can read “.pdf”files (such as the
Adobe Acrobat Reader), searches can be carried out on words of interest that might apply to a
specific project or functional area. In addition, textual information can be copied (using the “select
text”feature of the software) and pasted into a word processing application for further
modification. Graphics information can also be downloaded (using “select graphics”), although it
may not be as easy to modify these electronic tables or figures. Text and graphics information
can always be printed and the information manually entered as inputs to other software programs.

2.5.1 Identification of Needs or Problems

As discussed in section 2.3.1, most transportation needs and problems are identified through the
planning process as part of the ongoing process of improving transportation systems at the local
level. As such, the National ITS Architecture is unlikely to contribute much information to this initial
step. However, it can assist agencies in identifying ITS goals and objectives that are specific to
their needs. Both current and future needs should be identified. Goals and objectives identified in
the National ITS Architecture (Mission Definition) that pertain to traffic signal control systems
include:

• Increase operational efficiency and capacity of the transportation system

- Increase operational efficiency
- Increase speeds and reduce stops
- Reduce delays at intermodal transfer points
- Reduce operating costs of the infrastructure
- Increase private vehicle occupancy and transit usage

2-27
 Developing Traffic Signal Control Systems Using the National ITS Architecture

- Reduce private vehicle and transit operating costs

- Reduce freight operating costs and increase freight throughput
• Enhance personal mobility and the convenience and comfort of the transportation system
- Increase personal travel opportunities
- Decrease personal costs of travel including:
♦ Comfort, stress, fatigue, and confusion
♦ Safety and personal security
- Increase sense of control over one’s own life from predictable system operation
- Decrease cost of freight movement to shippers, including:
♦ More reliable “just-in-time”delivery
♦ Travel time and cost
♦ Driver fatigue and stress
♦ Safety (e.g., from tracking hazardous material)
• Improve the safety of the nation’s transportation system
- Reduce number and severity (cost) of accidents and vehicle thefts
- Reduce fatalities
• Reduce energy consumption and environmental costs
- Reduce vehicle emissions and fuel consumption due to congestion
- Reduce noise pollution
- Reduce neighborhood traffic intrusiveness
• Enhance present and future economic productivity of individuals, organizations, and the
economy as a whole
- Increase sharing of incident/congestion information
- Reduce information-gathering costs
- Increase coordination/integration of network operation, management, and investment

The National ITS Architecture documentation includes a Vision Statement, which describes ITS
capabilities now and into the future in magazine article style. The Vision can also serve to foster
general ideas about the types of local needs and problems that ITS can be used to address.

The National ITS Architecture also includes data collection subsystems, such as the planning
subsystem, to highlight the value of using ITS to collect long-term performance data on the
transportation system. Collecting and using this type of information can enhance and augment the
process of identifying needs and problems in the future.

Useful National ITS Architecture Documents: Mission Definition, Vision Statement

2.5.2 Identification of Solutions

There are at least two major ways that the National ITS Architecture can be applied to the
identification of alternative solutions to the given needs and problems, leading to the ultimate
selection of a preferred solution. During this step, traditional solutions to the problem or
combinations of traditional and ITS strategies may also be explored.

[Link] User Services

As discussed in Section 2.4.1, user services and associated user service requirements were
fundamental to the National ITS Architecture development effort. These user services were

2-28
 Developing Traffic Signal Control Systems Using the National ITS Architecture

designed to address surface transportation needs. Agencies may wish to review the list of user
services in their search for potential solutions to the given needs and problems. A list of user
services and those most relevant to traffic signal control systems was provided in table 2.4-1.

The following is a summary of the user service requirements most pertinent to traffic signal
control functions:

The traffic control user service is designed to:

♦ Optimize traffic flow

♦ Provide traffic surveillance

♦ Provide ramp metering

♦ Provide the ability to give priority to certain types of vehicles

♦ Provide device control capabilities

♦ Provide information to other functions

The incident management user service is designed to:

♦ Identify scheduled/planned incidents (e.g., construction activity)

♦ Detect incidents

♦ Formulate response actions

♦ Support coordinated implementation of response actions

♦ Support initialization of response actions

♦ Predict hazardous conditions

The highway-rail intersection user service is designed to:

♦ Control highway and rail traffic in at-grade highway-rail intersections(HRIs)

♦ Coordinate highway and rail management functions

♦ Manage traffic in the intersection at all HRIs with active railroad warning systems

♦ Provide advanced warning of closures

♦ Provide automatic collision notification at HRIs with active railroad warning systems

Under this approach for this step, agencies should select those user services and user service
requirements that are most relevant toward meeting the current and future needs previously
identified. Those user services and user service requirements that remain in the preferred
solution can be carried further into the next step of project development.

2-29
 Developing Traffic Signal Control Systems Using the National ITS Architecture

[Link] Market Packages

Reviewing and selecting market packages is another convenient approach that can be taken for
performing this step. As discussed in Section 2.4.5, market packages were defined in the
National ITS Architecture development effort to serve as deployment-oriented ITS service
“building blocks”. In general, the market packages offer a finer grained set of options than do
user services, offering more alternatives to choose from in this step of the process. In addition,
evaluation information (such as costs and benefits related material) is more readily available for
the market packages than for user services, which can provide added support to project planning.
As shown in table 2.4-4, the market packages identified in the National ITS Architecture that
support traffic signal control functions include:

♦ Network Surveillance – This market package provides the fixed roadside surveillance
elements that use a communications system to transmit surveillance data. It can be
completely local, such as loop detection connected with signal control, or it can be CCTVs
sending back images to traffic management centers. Surveillance enables traffic
managers to monitor road conditions, identify and verify incidents, analyze and reduce the
collected data, and make that data available to users and private information providers.

♦ Probe Surveillance – This is an alternative surveillance approach in which the travel times
of individual vehicles are tracked. Two general communications paths are possible: (1)
wide-area wireless communications between the vehicle and a traveler information service
provider can be used to transmit current vehicle location and status, and (2) a dedicated
short range communications link between the vehicle and roadside can be used to provide
equivalent information back to a traffic management system.

♦ Multi-modal Coordination – This market package establishes two way communications

between multiple transit and traffic agencies to improve service coordination. Intermodal
coordination between transit agencies can increase traveler convenience at transfer
points and also improve operating efficiency. Coordination between traffic and transit
management is intended to improve on-time performance of the transit system to the
extent that this can be accommodated without degrading overall performance of the traffic
network. More limited local coordination between the transit vehicle and the individual
intersection for signal priority is also supported by this package.

♦ Surface Street Control – This market package provides the communications links and the
signal control equipment for completely local surface street control and/or arterial traffic
management control. It provides for coordination between systems controlled by different
jurisdictions.

♦ Freeway Control -- This market package provides the communications and roadside
equipment to support ramp control, lane control, and interchange control for freeways.
Coordination and integration of ramp meters are included as part of this market package.

♦ Regional Traffic Control – This market package advances the surface street control and
freeway control market packages by allowing integrated inter-jurisdictional traffic control.

2-30
 Developing Traffic Signal Control Systems Using the National ITS Architecture

This market package provides for the sharing of traffic information and control among
traffic management centers to support a regional control strategy.

♦ Incident Management – This coordinates both predicted and unexpected incidents so that
the impact to the transportation network and traveler safety is minimized. Requisite
incident detection capabilities are included in the freeway control market package and
through regional coordination with other traffic management and emergency management
centers.

♦ Traffic Information Dissemination – This market package allows traffic information to be

disseminated using roadway equipment, such as changeable message signs, or highway
advisory radio. The emphasis is on provision of basic traffic information or other
advisories by means that require minimal or no in-vehicle equipment to receive the
information. This package provides a tool that can be used to notify drivers of incidents.
Careful placement of the roadway equipment provides the information at points in the
network where the drivers have recourse and can tailor their routes to account for the new
information.

♦ Traffic Network Performance Evaluation – This market package includes advanced

algorithms, processing, and mass storage capabilities that support historical evaluation,
real-time assessment, and forecasts of traffic network performance. This includes the
prediction of travel demand patterns to support better link travel time estimation for route
planning purposes.

♦ Standard Railroad Grade Crossing – This market package manages highway traffic at
highway-rail intersections (HRIs) where operational requirements do not dictate more
advanced features (e.g., where rail operational speeds are less than 80 miles per hour).
Both passive (e.g., the crossbuck sign) and active warning systems (e.g., flashing lights
and gates) are supported. These traditional HRI warning systems may also be augmented
with other standard traffic management devices. The warning systems are activated on
notification by interfaced wayside equipment of an approaching train. The equipment at the
HRI may also be interconnected with adjacent signalized intersections so that local control
can be adapted to highway-rail intersection activities.

♦ Advanced Railroad Grade Crossing – This market package manages highway traffic at
highway-rail intersections (HRIs) where operational requirements demand advanced
features (e.g., where rail operational speeds are greater than 80 miles per hour). This
market package includes all capabilities from the Standard Railroad Grade Crossing
Market Package and augments these with additional safety features to mitigate the risks
associated with higher rail speeds. This market package also includes additional detection
capabilities which enable it to detect an entrapped or otherwise immobilized vehicle within
the HRI and provide an immediate notification to highway and railroad officials.

♦ Railroad Operations Coordination – This market package provides an additional level of

strategic coordination between rail operations and traffic management centers. Rail

2-31
 Developing Traffic Signal Control Systems Using the National ITS Architecture

operations provides train schedules, maintenance schedules, and any other forecast
events which will result in highway-rail intersection (HRI) closures. This information is used
to develop forecast HRI closure times and durations which may be used in advanced
traffic control strategies or to enhance the quality of traveler information.

For additional help in connecting needs and problems with market packages, the Implementation
Strategy document contains a table that provides this kind of information. For illustration, the
excerpt of this table, shown as table 2.5-1, shows the market packages that best address the
problems of traffic congestion and air pollution.

In addition, the Performance and Benefits Study contains tables that relate the ITS system goals
to individual market packages (table 5.3-1 of the document) and the likely benefits of each market
packages (multiple tables in section 5.2 of the document). Agencies can use these as an aid in
determining which market packages best address local needs.

Useful National ITS Architecture Documents: Traceability Matrix, Implementation Strategy,

Performance and Benefits Study

Table 2.5-1. Connecting Problems, Solutions, and the National Architecture

(Excerpt from Table 4.2-1 of the Implementation Strategy)

2-32
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Conventional Advanced Systems Supporting

Problem Solution Approach Approach Market Packages
Traffic Increase • New roads • Advanced traffic control • Surface Street Control
Congestion roadway • New lanes • Freeway Control
capacity • Incident Management • Incident Management
(vehicular • Electronic Toll Collection System
throughput) • Dynamic toll/parking fee
• Corridor Management management
• Regional Traffic Control
• Railroad Operations
• Advanced vehicle systems Coordination
(Reduce headway) • Advanced vehicle
longitudinal control
• Automated highway system
Increase • HOV Lanes • Real-time ride matching • Dynamic Ridesharing
passenger • Car Pooling • Integrate Transit and • Multi-modal coordination
throughput • Fixed route transit Feeder Services
• Flexible route transit • Demand Response Transit
• New personalized public Operations
transit
Reduce • Flex Time • Telecommuting • Dynamic toll/parking fee
demand Programs • Other telesubstitutions management
• Transportation Pricing
Air Pollution Increase • More efficient • Remote sensing of • Emissions and
transportation conventional emissions environmental hazards
system vehicles sensing
efficiency, • Vehicle emissions • Advanced traffic • Surface Street Control
reduce travel inspections management to smooth • Freeway Control
and fuel • Promotion of flows • Regional Traffic Control
consumption alternatives to • Interactive Traveler
single occupant • Multi-modal pre-trip info Information
vehicle travel • Telecommuting
• Increased capacity • Other telesubstitutions
to reduce vehicle • Transportation Pricing • Dynamic Toll/Parking Fee
delay • Alternative fuel vehicles Management
• Regulations

2.5.3 Planning and Design of the Solution

Project planning and design, particularly in the early phases, is likely the most important step for
applying the National ITS Architecture information. There are a variety of ways to apply the
National ITS Architecture in this step; the most important of these are discussed below. By using
the various entry points described earlier in section 2.5, other methods for facilitating the design
process can be explored. The overall goal is for agencies to harness the analysis work already
performed and to have the opportunity to consider additional functions, interfaces, and
information sharing possibilities beyond the initial project scope, which can be planned for now in
anticipation of future needs.

The planning and design activities that are discussed in this section include:

♦ Determine Functional Requirements

♦ Identify Information Exchange Requirements

♦ Identify Standards

2-33
 Developing Traffic Signal Control Systems Using the National ITS Architecture

[Link] Determine Functional Requirements

The National ITS Architecture can be used as an input to defining project or system functional
requirements. This involves a more detailed look at the user service requirements or market
packages carried through from the previous step. Potential approaches include:

♦ User service requirements - The user service requirements associated with the proposed
solution can be evaluated for their applicability to the project. For example, they can be
used to augment the functional specification that may be put out in an RFP for detailed
design and procurement. Using the Traceability Matrix, the process specifications that are
associated with the relevant (selected) user service requirements can also be analyzed.
For those process specifications that are maintained in the system design, the data is
available to relate those functions to the rest of the logical and physical architecture.

♦ Market packages - The high-level architecture defined using the market packages can be
further refined by examining the logical architecture elements that support these
subsystems and architecture flows. The linked model can provide the maps to the
underlying functions and data flows of the logical architecture. The process specifications
associated with the market packages can be tailored to satisfy more closely the local
needs or requirements that the solution must address. As originally defined, the market
packages may identify more subsystems, equipment packages, or terminators than are
required to satisfy the identified needs. While this presents a chance to drop unneeded
features, it should also be viewed as an opportunity to consider additional capabilities that
may satisfy other needs at marginal cost. During the process of designing the project,
expansion capability may also be identified that can be planned for in future solutions. See
section [Link] for an example of how to aggregate and tailor market packages to meet
local needs.

♦ Physical Architecture Subsystems - Even if the user service or market package approach
isn’t followed initially, agencies should be able to determine the relevant subsystems
associated with a given project. Given a list of these subsystems, the physical architecture
entry point can be used to determine the associated equipment packages, process
specifications, and information flows. The underlying process specifications can be
evaluated for their applicability and potential contribution to the functional needs of the
given project (or future ones). This entry point is particularly useful for projects with a
substantial amount of central equipment and software costs, such as a TMC upgrade.

For each alternative presented above, the National ITS Architecture material can be used as is,
dropped, modified, or added to as appropriate to the situation. In most cases, additional
performance requirements and other types of decisions will need to be included in the
specification of a system before it can be procured (even if the detailed design work is to be put
out for bid). It is important to recognize that the National ITS Architecture does not address
reliability, availability, or maintainability. These and other operational and maintenance needs
must be added to any requirements definition or system specification.

2-34
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Unique local needs that are not covered as part of the 30 user services will also require the
addition of subsystems or functions that are outside the National ITS Architecture. These types
of elements may represent legacy system functions or portions of legacy systems. The addition
of functionality, subsystems, and external interfaces (terminators) that are not part of the National
ITS Architecture is part of the process of tailoring the solution architecture to satisfy the identified
needs.

[Link] Identify Information Exchange Requirements

The physical architecture identifies the physical subsystems and data flows among subsystems
that will support the communications requirements of a given project. It is important to identify
physical data flows because they are the actual representation of communication ties among
agencies and subsystems. Figure 2.5-2 illustrates a simplified physical architecture data flow
diagram for traffic management. Appendix C contains a more detailed listing and explanation of
the physical architecture flows that are relevant to traffic signal control functions.

Event Map Update

Promoters Provider
Construction & Other Traffic
Management
Maintenance

DMV Traffic Operations

Personnel

Roadway
Enforcement
Subsystem Agency
Traffic
Management
Weather
Service Emergency
Management

Transit
Management Planning
Subsystem

Information
Service Toll Emissions
Provider Administration Management

Figure 2.5-2. Example Physical Data Flows for Traffic Management

In the process of specifying the information exchange requirements for the project, the underlying
logical data flows associated with the identified physical information flows should be evaluated for
their inclusion in the definition of communication messages. In cases where data flows are not
currently available (but might be in the future), accommodation of extra message fields in the
software development for the project should be considered. This will likely be done more
economically if it is carried out now instead of having to modify the software later to handle the
increased and changed needs for communications.

2-35
 Developing Traffic Signal Control Systems Using the National ITS Architecture

The Theory of Operations document can be used to obtain a better understanding of how the
physical architecture elements work together to provide ITS services. For example, it provides
diagrams and descriptions indicating the intended sequencing of messages for particular user
services. These diagrams illustrate the sharing of information between subsystems which is
relevant in determining the working relationships needed between different agencies for a given
project. This type of information can be invaluable in developing a concept of operations for a
project.

During the process of analyzing the possible information requirements contained in the National
ITS Architecture, information exchanges beyond what was originally planned may become
desirable additions to the project. This could entail establishing working relationships and
agreements with agencies that were not originally part of the project planning effort, which could
lead to an expansion of the project steering team. The information exchanges identified in the
National ITS Architecture can stimulate the discussion of operational roles and responsibilities
and are therefore critical to establishing the operations requirements for the project.

[Link] Identify Standards

The rapid pace of progress in technology will introduce many new systems and devices into
transportation systems. As transportation systems incorporate advanced technology, there will be
a need for standards to promote multi-vendor interoperability and ease of integration. With
standards, it is simpler to share data and communicate between transportation systems,
particularly between agencies within the same region. Without standards, it is more difficult to
integrate transportation systems with each other, and consequently there is a danger of isolating
systems and limiting their potential effectiveness in solving a region’s transportation needs and
problems.

One of the major reasons for developing the National ITS Architecture was to identify where
standard system interfaces were needed. Because the National ITS Architecture is serving as
the common foundation for the ongoing ITS standards development work, factoring it into your
current system enhancements will facilitate the transition to a sta ndard interface definition in the
future. The Standards Requirements document contains detailed information on the requirements
for 12 high-priority standards packages.

Agencies can take advantage of these standards as they emerge by specifying their use in
procurement packages. Among the pertinent national ITS standards development activities in
process are the suite of standards being developed under the National Transportation
Communications ITS Protocol (NTCIP) effort, and Dedicated Short Range Communications
(DSRC) standards. Appendix A contains sources for additional information on these and other
relevant standards development activities.

Agencies should also keep in mind that a variety of existing communications and information-
based standards, which may have been created for other reasons, are applicable to ITS projects
and are being used in systems today.

2-36
 Developing Traffic Signal Control Systems Using the National ITS Architecture

[Link] Market Package Aggregation and Modification Illustration

To illustrate some of the concepts of section 2.5.3, this subsection illustrates the use of market
packages as a way to create a high-level physical architecture that can be further tailored to
address local requirements.

As market packages are selected to address the given problems and needs, they may be
aggregated by connecting or overlapping duplicate subsystems. The subsystems are connected
by architecture flows that define subsystem interfaces. The aggregation of market packages will
result in a high-level physical architecture that has been extracted from the National ITS
Architecture and will represent a starting point for refinement and tailoring to unique local needs or
requirements. For example, the Surface Street Control and Incident Management System market
packages might be found to be the most applicable solutions to the identified problem.

The aggregation of these two market packages would result in the architecture illustrated in figure
2.5-3. This diagram shows the aggregation of the equipment packages (shown as white boxes
inside the gray subsystems) and physical architecture flows (shown as arrows) of both market
packages. Compared to the original Surface Street Control market package diagram (shown as
figure 2.4-7), the traffic management subsystem has accumulated more functionality in the
aggregated market package since the equipment packages from the individual market packages
for that subsystem have been aggregated as well. In addition, more architecture flows have been
identified between the traffic management and roadway subsystems resulting in an expanded

Information
Service Provider

traffic
information

Emergency incident notification Traffic incident data

Management Management Roadway
Emergency Response incident information TMC Incident Dispatch signage data
Management Coord/Communication
Roadway
TMC Basic Signal Signal Controls
emergency vehicle Control
signal control data
driver status update Traffic
signal control status
Maintenance
Emergency
Vehicle TMC
Coord

Other TM

Figure 2.5-3. Aggregation of Surface Street Control and Incident Management

Systems
interface definition.

The solution architecture should be analyzed to determine if it properly addresses the identified
needs. The solution architecture may have more subsystems than are required or it may be

2-37
 Developing Traffic Signal Control Systems Using the National ITS Architecture

missing subsystems or terminators required to satisfy the needs. If there are extraneous
subsystems or architecture flows, they can be dropped from the architecture. For instance, if
there was only one TMC in the area and no coordination was deemed necessary in the future, the
TMC Coordination architecture flow and the ‘Other TM’terminator would be dropped.

If a requirement is not satisfied by the architecture, subsystems and/or architecture flows should
be added. The physical architecture should be reviewed for additional subsystems or terminators
and their associated architecture flows to satisfy any missing elements in the solution
architecture. For example, if there were an additional requirement that a transit management
property be given direct traffic information on incidents, a subsystem would be added to include a
Transit Management subsystem and a ‘traffic information’architecture flow from the Traffic
Management Subsystem to exchange the information. Figure 2.5-4 illustrates this modification to
the architecture.

Transit Information
Management Service Provider

traffic traffic
information information

Emergency Traffic incident data

Management incident notification Management Roadway
Emergency Response TMC Incident Dispatch signage data
Management incident information Coord/Communication
Roadway
TMC Basic Signal Signal Controls
emergency vehicle signal control data
Control
driver status update Traffic
signal control status
Maintenance
Emergency
Vehicle

Figure 2.5-4. Modification of Aggregated Market Package Architecture

The high-level architecture defined using the market packages and physical architecture
subsystems can be further refined by examining the logical architecture elements that support
these subsystems and architecture flows. The process specifications can be tailored to satisfy
more closely the local needs or requirements that the solution must address. The solution
architecture will be refined to a point where it satisfies the identified needs in sufficient detail that
design specifications can be generated as inputs to the final design of the solution.

Useful National ITS Architecture Documents: Logical Architecture, Physical Architecture,

Traceability, Theory of Operations, Communications Document, Standards Requirements
Document

2-38
 Developing Traffic Signal Control Systems Using the National ITS Architecture

2.5.4 Funding, Procurement, and Implementation

The National ITS Architecture material is most useful in earlier steps of the system or project
development process. Nevertheless, it can also provide valuable information during this final
step, particularly in the area of cost estimation. The evaluation documents and the Implementation
Strategy can also be used as a general resource during this final phase of project development.

Cost Estimates

As a tool to assist in the estimation of costs for planning purposes, a series of spreadsheets that
contain approximate non-recurring (initial capital investments) and recurring (operation and
maintenance) costs of equipment packages was developed as part of the National ITS
Architecture effort. These are provided in the Cost Analysis document. These costs are provided
in 1995 U.S. dollars.

These costs should be applied cautiously and should not be used as a recipe for determining the
actual costs of ITS deployments, since these costs vary substantially over time and from region to
region. Consequently, current prices should be collected by anyone attempting to generate a
detailed cost estimate for an ITS application. However, the spreadsheets can be useful in
producing first order cost estimates for planning purposes. Moreover, they can be used to
determine which factors affect the cost of a particular equipment package.

Useful National ITS Architecture Documents: Physical Architecture, Implementation Strategy,

Cost Analysis

2.6 Traffic Signal Control Project Application Scenarios

This section will step through three representative traffic signal control scenarios to help illustrate
the guidance presented above on how the National ITS Architecture can be used to support the
design and deployment of ITS applications for traffic signal control systems. The three scenarios
are:

♦ System Upgrade (Section 2.6.1)

♦ Freeway-Arterial Coordination (Section 2.6.2)

♦ Transit Vehicle Priority (Section 2.6.3)

Each of the scenarios includes a brief presentation of each of the four general steps referenced
throughout this section, but is tailored to illustrate different aspects of the previously presented
guidance on applying the National ITS Architecture.

2.6.1 System Upgrade Scenario (Using Market Packages)

The major challenge facing managers of traffic signal control systems is that of operating,
maintaining, and expanding an existing system. It is not uncommon to find older traffic signal
control systems that have been in operation for more than 20 years. Maintaining these systems is

2-39
 Developing Traffic Signal Control Systems Using the National ITS Architecture

difficult and expensive because they often include equipment that is no longer being
manufactured, making it difficult to acquire spare parts necessary to repair or replace failed
equipment. Many older signal systems are also limited in their expansion capabilities and the
functions they perform. Thus, the benefits of upgrading an older system may include lower
maintenance costs, availability of spare parts, additional functionality, and the ability to easily
expand the system in the future.

This scenario illustrates the use and tailoring of market packages and their supporting cost
analysis and highlights the consideration of standards.

[Link] Identification of Needs or Problems

Existing System
A City currently operates a computerized traffic signal control system. Because of the central
computer equipment’s age, the system is running out of expansion capability. The central
computer equipment manufacturer has stated that it cannot continue to support the system in the
future. The field equipment is relatively new, and has not reached the end of its useful life.

Objectives
The City has decided to add more controllers and add new field devices (CCTV cameras and
variable message signs) to enhance the system’s surveillance and motorist information
capabilities. In addition, the City would like to migrate to a single communications infrastructure to
help reduce operations and maintenance costs in the future.

[Link] Identification of Solutions

The expansion of an older system is often expensive because the communication protocols and
equipment are outdated and often proprietary. Thus, the manager of the traffic system is
committed to a single supplier, or must develop software or equipment to translate protocols from
one vendor’s format to another. This potentially increases long term costs due to the lack of
competition among vendors.

One alternative is to replace the entire traffic signal control system. This approach is not feasible
since the City has stated that it wants to use the existing controllers in the field and the existing
communications infrastructure. The existing controllers provide the required functionality and
have many years of useful life remaining.

A more practical and achievable approach is to acquire and install new hardware and software in
phases over a period of years. This solution is economically viable and will allow the City to show
early results.

Traffic engineers from the City have attended a recent offering of the National ITS Architecture
training course and have chosen to review the list of market packages for their potential
application to this project. Based on a best match of their needs with the available market
packages, the Surface Street Control (figure 2.6-1, previously shown as figure 2.4-7 ), Network

2-40
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Surveillance (figure 2.6-2), and Traffic Information Dissemination (figure 2.6-3) market
packages were selected for further analysis.

2-41
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Surface Street Control (ATMS3)

This market package provides the communication links and the signal control equipment for local
surface street control and/or arterial traffic management control. An example would be arterial
signalization control. This market package is considered an intra-jurisdictional package since
coordination between adjacent cities is required to coordinate signal control along arterials. This
package is consistent with typical urban traffic signal control systems.

Traffic
M anagement signal control data Roadway
TMC Basic Signal
Control
Roadway
signal control status Signal Controls
Traffic
Maintenance

Figure 2.6-1. Surface Street Control Market Package

(Adapted From Appendix A of the Implementation Strategy)

Network Surveillance (ATMS1)

This basic market package provides the fixed roadside surveillance elements utilizing wireline
communication to transmit the surveillance data. It can be loop detection connected with traffic signal
control or it can be CCTVs sending back data to the traffic management centers. This enables traffic
managers to monitor road conditions, identify and verify incidents, analyze and reduce the collected
data, and make it available to users and private information providers.

request for Traffic local traffic flow Roadway

Information traffic information
Service Provider Management
Collect Traffic Roadway Basic
traffic Surveillance Surveillance Surveillance
information control

Figure 2.6-2. Network Surveillance Market Package

(Adapted From Appendix A of the Implementation Strategy)

2-42
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Traffic Information Dissemination (ATMS6)

This market package allows traffic information to be disseminated using roadway equipment like
variable message signs or highway advisory radio. The emphasis is on provision of basic traffic
information or other advisories which require minimal or no in-vehicle equipment to receive the
information. This package provides a tool that can be used to notify drivers of incidents; careful
placement of the roadway equipment provides the information at points in the network where the
drivers have recourse and can tailor their routes to account for the new information.

Traffic Roadway
M anagement signage data
TMC Traffic Info Roadway Traffic Info
Dissemination Dissemination

Figure 2.6-3. Traffic Information Dissemination

(Adapted From Appendix A of the Implementation Strategy)

[Link] Planning and Design of the Solution

As part of the planning and design process, the City analyzed the market packages previously
selected in order to determine the functions and information flows that need to be included
between the traffic management center and field components. Doing so also allowed the City to
determine if additional enhancements or modifications to the design were needed to meet local
requirements. This involved a review of the functionality (P-specs) of the applicable equipment
packages and the contents of the applicable physical architecture data flows (as shown in the
market package diagrams). In addition, the secondary flows associated with these market
packages were investigated on the linked HTML model on the Internet. The results of this process
are discussed below.

Market Package Tailoring Illustration

The following tables illustrate some of the modifications made during the process of analyzing the
market packages in light of the existing system configuration and future plans of the City and other
transportation operating agencies within the region. The City did not find that there were many
extraneous functions and information flows in the selected market packages. In fact, two
processes were added to the functional requirements of the project, and a physical data flow was
added to account for the desire between the City and State DOT to share the enhanced traffic
information that will be provided over existing links between traffic centers. A traffic information
service provider does exist in the region (fitting the role of the ISP subsystem), and will receive
the same information as the State.

2-43
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Functional Requirements Modifications (Example)

Subsystem Equipment Change Reason

Package

Traffic TMC Basic Signal ADD P-spec 1.1.5 (Exchange Create the hooks for future
Management Control data with other Traffic data sharing and regional
Centers) coordination

TMC Traffic ADD function: Provide Allows operator to create/

Information operator interface override VMS messages
Dissemination

Information Exchange Requirements Modifications (Example)

Subsystem: From -> To Physical data flow Change /Explanation

Traffic Management -> Signage data (MODIFY) Use existing system

Roadway protocols/message
conventions

Traffic Management -> Other traffic information (ADD) Share traffic information over
TM existing link between City and
State Freeway Management
Center

As part of the design of the project, the City has decided to investigate the potential availability of
standards for traffic signal controllers.

Identifying Applicable ITS Standards for Traffic Signal Controllers

There are two families of traffic signal controller standards currently in widespread use in the
United States today: National Electrical Manufacturers Association (NEMA) and Type 170. The
NEMA family includes the NEMA TS-1 and TS-2 controllers and the Type 170 includes the Model
170, Model 179, and model 2070.

The Model 170 and 179 and the NEMA controllers are heavily used throughout the nation, with the
Model 2070 quickly gaining acceptance. The selection of which controller standard to use is
dependent on the capabilities and functions needed. More in-depth coverage of signal controller
technologies and signal controller standards can be found in the Traffic Control Systems
Handbook (Referenced in Section 5).

2-44
 Developing Traffic Signal Control Systems Using the National ITS Architecture

National Transportation Communications for ITS

Protocol (NTCIP)
The National Transportation Communications for ITS
Protocol (NTCIP), one of the standards efforts being
developed in coordination with the National ITS
Architecture standards efforts, can make integration
easier by allowing the implementation of different
manufacturers’components and systems within a
common communications infrastructure, as illustrated
in figure 2.6-4. More background on the NTCIP family
of standards is provided in Appendix A.

Given the status of NTCIP development, the City has

decided to investigate incorporating it in the
specifications for new controllers for this project. A
major benefit of NTCIP will be the future ability it will
provide to control traffic signal controllers, variable
Figure 2.6-4. NTCIP Standard
message signs, video surveillance cameras, and traffic
sensors using the same communications channel.

Other Considerations
The biggest barrier to upgrading an existing system will likely be the upgrade to a new
communications protocol. The following points provide some guidelines, facts, and alternatives for
upgrading an existing system with NTCIP.

♦ NTCIP and non-NTCIP devices cannot be mixed on the same communications channel.

♦ In closed loop traffic signal systems, a central computer can communicate with field
masters using a different protocol than that used by the field master to communicate with
controllers. However, with NTCIP this alternative requires that the field master support
multiple protocols, and use a different communications port for NTCIP and non-NTCIP
devices. A straightforward solution is to limit each field master to one protocol. Only field
masters with NTCIP compatible controllers would need to be upgraded to support NTCIP.
This avoids the need for field masters to simultaneously support two protocols on two
separate ports.

♦ One approach to the introduction of NTCIP is to operate two totally separate systems—
one NTCIP and one non-NTCIP— during a transition period. Field devices can be
gradually switched over from one type of equipment to another as they are replaced or
their software is upgraded over time. This may be the only solution if the current system is
old and upgrading it to NTCIP is impractical.

♦ Even if a system continues to use proprietary protocols, new controllers and field masters
should be specified to support both NTCIP and the proprietary protocol to allow future
upgrades to NTCIP. It is expected that vendors will continue supporting both their existing

2-45
 Developing Traffic Signal Control Systems Using the National ITS Architecture

protocol and NTCIP in the same package. However, vendors will not want to support two
protocols (the proprietary and the NTCIP) indefinitely, and may eventually drop the old
protocol from future products. To avoid being left with unsupported and incompatible
protocols, users should ensure that all future products include support for NTCIP.

♦ Using NTCIP may involve more data overhead than existing proprietary protocols, and it
may not be possible to maintain the same polling cycle times with the same number of
controllers per channel.

NTCIP encompasses several protocols, or profiles. Two profiles relevant to this scenario are
presented below:

♦ Class B Profile - “B”asic Field Communications - Class B was the initial protocol
developed and is designed for direct communications between a master or central device
and multiple field devices on a single communications channel. Class B provides basic
NTCIP functionality and is intended for use on low speed communications channels such
as 1200 baud. The Class B profile has already been published.

♦ Class A Profile - “A”dvanced Field Communications - The contents of the Class A profile
is the same as the Class B profile. However, the Class A provides additional flexibility so
that its messages can be routed through intermediate devices, such as a field master, a
communications hub, or a network. However, this extra flexibility requires an additional
data overhead to the message, increasing the message’s size and delivery time. Thus, the
Class A profile is intended only for high speed communications links, or if frequent real-
time transmissions are not needed, such as monitoring or controlling a variable message
sign. Development work on the Class A profile is currently being completed.

♦ It is expected that the current generation of field controllers will support the Class B profile.
As controllers and the communications media of existing traffic signal control systems are
upgraded, it is likely that the traffic systems will migrate to the Class A profile because of
its flexibility.

[Link] Funding, Procurement, and Implementation

A staged upgrade approach has been selected and will take place in three stages.

♦ Stage 1: The City has decided to add new controllers and utilize the existing
communications infrastructure. The long range plan is to migrate equipment and
communications to NTCIP for all future ITS applications. NTCIP supports the City’s
existing system configuration. Nonetheless, the City has decided to replace the system at
a nominal cost relative to the cost of the entire system. The existing controller
manufacturer is planning to support both the proprietary non-NTCIP communications
protocol and the NTCIP in the same controller. These new controllers, running Class B
communications, can be upgraded in the future. Thus, the central hardware equipment and
software are upgraded to support the existing communications protocol and NTCIP.

2-46
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Stage 2: During this stage of deployment, the City will add surveillance cameras, and
variable message signs, based on the NTCIP Class A protocol. Initially, the cameras and
signs will be installed on communications lines separate from the existing controllers, since
NTCIP cannot coexist on the same communications channel with non-NTCIP protocols.
However, traffic signal controllers which support NTCIP may be added to the
communication lines supporting NTCIP as necessary.

♦ Stage 3: In the future non-NTCIP compliant controllers will be replaced with NTCIP Class
B signal controllers. Controllers will be replaced as they approach their useful life, as
dictated by maintenance costs or if new functionality is desired. The City will then upgrade
all of its communications software to support NTCIP.

This staged approach is shown in figure 2.6-5.

Cost Analysis
The Cost Analysis document from the National ITS Architecture provides information that can
help to generate an order-of-magnitude cost for this system upgrade scenario.

Cost Assumptions
− 50 Intersections will be upgraded.
− 10 Video Cameras will be deployed.
− 10 VMS will be deployed.
− Software is off-the-shelf.
− Communications are leased from a communications service provider.

To generate costs, one should list the equipment packages associated with each market
package; then, using the Cost Analysis document worksheets, calculate order-of-magnitude
costs. (All prices are in 1995 dollars. The costs shown in the tables below utilize the high unit
price cost.) These costs are used strictly for up-front planning purposes.

Costs for the system upgrade scenario are summarized in table 2.6-1. Tables 2.6-2 through table
2.6-4 show how each market package cost was calculated and built up from individual equipment
package cost. Cost information is separated into initial capital investment required and recurring
operations and maintenance costs. More detailed cost estimates will be prepared at each of the
program stages using actual vendor prices.

2-47
Developing Traffic Signal Control Systems Using the National ITS Architecture

Figure 2.6-5. Traffic Signal Control System Upgrade Scenario

2-48
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Table 2.6-1. Cost for System Upgrade Scenario

System Upgrade Scenario

Initial Capital Investment Equipment Package Roll-Up Cost
(By Market Package)
Surface Street Control Basic Signal Control (Table 2.6-2) $ 251,000
Surface Street Control Traffic Maintenance (Table 2.6-2) $ 35,000
Surface Street Control Roadway Signal Control (Table2.6-2) $ 400,000
Network Surveillance Collect Traffic Surveillance (Table 2.6-3) $ 425,000
Network Surveillance Roadway Basic Surveillance (Table 2.6-3) $1,200,000
Traffic Information Dissemination TMC Traffic Information Dissemination (Table 2.6-4) $ 145,000
Traffic Information Dissemination RW Traffic Information Dissemination (Table 2.6-4) $2,500,000
Total Capital Investment $4,956,000

Operations and Maintenance Equipment Package Roll-Up Cost

(By Market Package)
Surface Street Control Basic Signal Control (Table 2.6-2) $ 558,000
Surface Street Control Traffic Maintenance (Table 2.6-2) $ 50,000
Surface Street Control Roadway Signal Control (Table 2.6-2) $ 1,000
Network Surveillance Collect Traffic Surveillance (Table 2.6-3) $ 100,000
Network Surveillance Roadway Basic Surveillance (Table 2.6-3) $ 56,000
Traffic Information Dissemination TMC Traffic Information Dissemination (Table 2.6-4) $ 110,000
Traffic Information Dissemination RW Traffic Information Dissemination (Table 2.6-4) $ 125,000
Total Operations and Maintenance Cost / Year $1,000,000

Table 2.6-2. Cost for Surface Street Control Market Package

Surface Street Control Market Package (50 Intersections)

Initial Capital Investment Basic Signal Control Equipment Package Cost
- Software and Integration and 1 year $ 220,000
- Hardware (3 Workstations) $ 30,000
- TMC to Roadside Communications - DS 1 $ 1,000
Sub Total $ 251,000
Operations and Maintenance Basic Signal Control Equipment Package Cost
- TMC to Roadside Communication - DS 1 $ 8,000
- Operators (2 @ 50% time) $ 100,000
- Transportation Engineer (1 @ 50% time) $ 50,000
- Update Timing Plans $ 250,000
- Signal Maintenance Technicians (2 @ 75,000) $ 150,000
Sub Total $ 558,000
Initial Capital Investment Traffic Maintenance Equipment Price Cost
- Software and Database Add-on $ 35,000
Sub Total $ 35,000
Operations and Maintenance Traffic Maintenance Equipment Package Cost
- Transportation Engineer (1 @ 50% time) $ 50,000
Sub Total $ 50,000
Initial Capital Investment Roadway Signal Controls Cost
- Linked Signal System LAN $ 50,000
- Local Controller Upgrades - 50 x $7,000 $ 350,000
Sub Total $ 400,000
Operations and Maintenance Traffic Maintenance Equipment Package Cost
- LAN Maintenance $ 1,000
Sub Total $ 1,000

2-49
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Table 2.6-3. Cost for Network Surveillance Market Package

Network Surveillance Market Package (10 Cameras, 50 Intersections)

Capital Investment Collect Traffic Surveillance Equipment Cost
- Processor and Software $ 165,000
- Integration $ 250,000
- TMC to Roadside Communications - DS 3 $ 5,000
- Roadside to TMC Communication - DS 3 $ 5,000
Sub Total $ 425,000
Operations and Maintenance Collect Traffic Surveillance Equipment Cost
- TMC to Roadside Communication - DS 3 $ 50,000
- Roadside to TMC Communication - DS 3 $ 50,000
Sub Total $ 100,000
Capital Investment Roadway Basic Surveillance Equipment Cost
- 50 Loops @ $8,000 $ 400,000
- 10 Video Cameras @ $40,000 $ 400,000
- 10 Camera Poles @ $40,000 $ 400,000
Sub Total $ 1,200,000
Operations and Maintenance Roadway Basic Surveillance Equipment Cost
- Loop Maintenance @ 10% Capital Cost $ 40,000
- Camera Equipment Maintenance @ 2% Capital $ 16,000
Sub Total $ 56,000

Table 2.6-4. Cost for Traffic Information Dissemination Market Package

Traffic Information Dissemination Market Package (10VMS)

Capital Investment TMC Traffic Information Dissemination Cost
- Hardware (1 Workstation) $ 10,000
- Software $ 24,000
- Integration $ 110,000
- Roadside to TMC Communication - DS 0 $ 1,000
Sub Total $ 145,000
Operations and Maintenance TMC Traffic Information Dissemination Cost
- 1 Operator @ $100,000 $ 100,000
- Maintenance @ 5 Capital Cost $ 7,000
- Roadside to TMC Communication - DS 3 $ 3,000
Sub Total $ 110,000
Capital Investment Roadway Traffic Information Equipment Cost
- 10 Variable Message Signs @ $100,00 $ 1,000,000
- 10 VMS Support Structures @ $150,000 $ 1,500,000
Sub Total $ 2,500,000
Operations and Maintenance Roadway Traffic Information Equipment Cost
- Maintenance @ 5% Capital Cost $ 125,000
Sub Total $ 125,000

2-50
 Developing Traffic Signal Control Systems Using the National ITS Architecture

2.6.2 Freeway-Arterial Coordination (Using User Service Requirements)

In this scenario, the State and City traffic management agencies agreed to work together to better
manage traffic congestion situations. This scenario illustrates the use of user service
requirements as an approach for guiding the development of functional requirements for a
system.

Background
A major challenge to managers of traffic signal control systems is the coordination of traffic
control strategies across transportation facilities operated by different agencies. Coordination
between different transportation facilities includes: freeway and surface street coordination,
coordination of surface street networks in adjacent jurisdictions, and coordination of surface
streets and bridges and tunnels. When traffic flow in one portion of the transportation network
breaks down, delays and congestion can spill over into other transportation facilities. By
coordinating information and control strategies, traveler safety and travel times can be improved
while reducing delays and traffic congestion by balancing the traffic loads between resources.

Freeway-Arterial coordination is effective when the demand in one transportation facility which is
approaching capacity can be balanced with excess capacity available in an adjacent
transportation facility. By managing and balancing the traffic demand in both networks, delays and
congestion in both networks can be minimized. One issue related to freeway-arterial coordination
is that of non-recurring delays and traffic on the mainline freeway. Vehicles on the freeway will
tend to divert onto alternate routes to reach their destination when congestion occurs on the
mainline. These routes may include parallel service roads and arterials in the vicinity of the
freeway. This situation generally results in increased traffic demand on service roads and
arterials, possibly increasing beyond the capacity of the existing roadway and the signal timing
patterns, resulting in significant traffic congestion on the surface streets. The surface street
managers, unaware of the delays on the freeways, cannot adjust the signal timing patterns in time
to handle the increased volumes, and the resulting traffic congestion cannot be prevented from
spreading to other roadways within their jurisdiction.

Another problem which occurs is the ramp metering rate at a freeway entrance may not be able to
accommodate the traffic demand at the on-ramp, resulting in the queue on the ramp spilling back
onto the surface street network. The spill-back may cause a breakdown of the traffic flow on the
service road or of the signalized intersections upstream from the ramp entrance. With the latter
situation, vehicles are unable to enter the on-ramp because of the upstream queue. They might
block the intersection or create further spill-back on all the approaches to the signalized
intersection, resulting in further congestion and delays.

This Scenario
In this scenario, the City traffic engineering agency responsible for traffic management on the
parallel arterials met with the State DOT to discuss how they can better respond to incident-
related increased demand situations. The City operates a Traffic Management Center containing
a centralized computerized traffic signal control system. Timing plans are implemented on a time-

2-51
 Developing Traffic Signal Control Systems Using the National ITS Architecture

of-day, day-of-week basis. Currently, the City’s traffic signal control system operates
independently of the State’s Freeway Management System, i.e., it is wholly self-contained and
does not communicate with any other agency transportation management system.

The State DOT and City traffic engineering agency agreed in principle to improve
communications to better manage traffic during major incident situations. A task force was
appointed to investigate the situation and report back to decision-makers in both agencies. The
Freeway-Arterial scenario is illustrated in figure 2.6-6.

[Link] Identification of Problems and Needs

The first job of the joint task force was to identify and refine all of the relevant transportation
needs, objectives or problems.

Existing System
The State DOT operates a freeway management system which includes ramp meters at the
freeway entrances and detectors on the mainline. The traffic signals at the freeway exit ramps
are also operated by the State. The State’s freeway management system and the State’s traffic
signal control system do not currently communicate with each other. Additionally, the City traffic
engineering agency operates the traffic signals along an arterial that runs parallel to the freeway.
The City traffic signal system and the State’s freeway management systems do not currently
communicate with each other.

Objectives
The State and City agencies agreed to upgrade their systems to cooperate on handling of
incident traffic management. The task force identified the following needs:

♦ The City must know as soon as possible when a freeway incident has occurred that has
the potential to cause major traffic diversions from the freeway to parallel arterials.

♦ The City must develop incident response signal timing plans that will accommodate larger
through traffic volumes on the arterial. The timing at traffic signals downstream of freeway
ramp exits will be especially critical.

♦ Drivers need to be informed in advance of freeway entrance ramps when a major incident
exists on a nearby downstream freeway link so they may select alternative routes.

♦ Information on current arterial conditions needs to be disseminated to the public to avoid

inadvertently causing an even worse problem as a result of too much diversion to arterials.

♦ If sufficient capacity exists in the arterial system, traffic can be diverted from the freeway
to the arterial system to improve overall traffic flow through the corridor.

♦ The ramp metering rate can be adjusted to allow increased flow of vehicles onto the
freeway system (assuming there is sufficient available capacity), thus reducing congestion
on the arterial system.

2-52
Developing Traffic Signal Control Systems Using the National ITS Architecture

Figure 2.6-6 Freeway-Arterial Coordination Scenario

2-53
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ The signal timing of the traffic signal downstream of the exit ramp and the arterial signals
further downstream can be adjusted to increase the flow of vehicles onto the arterial
system, thus reducing queues at the freeway exit ramp.

In addition, the State and City agencies have been approached by an Information Service
Provider (ISP) who would like to disseminate real-time traffic information for the region to
travelers, via local radio and television broadcasters.

[Link] Identification of Solutions

Freeway-Arterial coordination is successful when the respective facility managers are aware of
traffic conditions on each other’s portion of the transportation network, and they coordinate a
timely response according to those conditions. Coordination between the two networks will
involve using the field devices (VMS, ramp meters, signal controllers, CCTV, etc.) on their
respective systems to implement cooperative responses.

One alternative to integrating the freeway management system and the arterial traffic signal
control system is to develop new software on both systems which would handle communications
and requests for signal timing or ramp meter adjustment. A second alternative is to introduce an
ancillary system which would manage communications between the State’s freeway management
system and the City’s traffic signal control system. A third alternative is to consider placing the
traffic signals at the freeway entrance and exit ramps, currently under control of the State, under
the jurisdiction of the City, which would enable the City to coordinate their operations. The third
alternative also requires that the City have access to the operational status of the freeway
system.

The task force also agreed to investigate the Traffic Control, Incident Management, and En-
Route Driver Information user services to determine if their underlying requirements and
physical and logical architecture definition could be used to support the planning and design of the
project.

Other Considerations

The task force also identified several capabilities that might be included in the solution.
♦ Inclusion of the arterial operations center as a node on a wide area network that will allow
freeway incident alarm messages to be received at the arterial operations center, and
allow the arterial operators to communicate with traveler information service providers

♦ Dial-in capability that will allow arterial signal system operators to monitor the freeway
status map and selected freeway video surveillance cameras on monitors

♦ Development of arterial incident response timing plans that incorporate gating (storing
traffic upstream of congested locations) and reverse progression (to clear queues and
help prevent intersection blockage) strategies

2-54
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Installation of variable message signs on key arterials in advance of freeway entrance

ramps

♦ Installation of video cameras at critical locations along arterials

♦ Agreement on information that will be exchanged (queue lengths, travel speeds, estimated
duration of delay, ramp metering rate, signal timing pattern in effect, signal splits, etc.), and
how information will be exchanged (communications media, protocol, data format, etc.)

♦ Development of operating agreements detailing responsibilities during incident situations.

This includes agreement on common control strategies for handling delays and problems
as they occur, agreement in advance on what thresholds will trigger certain control
strategies to be placed into effect, and agreement that control strategies should be
employed judiciously such that they provide an overall benefit to the transportation network.
For example, freeway managers should not encourage motorists to use the service roads
or arterials if excess capacity is not available on the surface street network. Conversely,
the ramp metering rate for the on-ramp should not be increased if it is determined that the
impact on the mainline freeway will have a significant adverse effect.

The State and City have agreed to investigate the use of ITS standards for communications. The
City has also agreed to allow the State to collect regional traffic data and provide it to an ISP in
the future – this deployment will be used as a model for the rest of the State.

[Link] Planning and Design

At this point, the State DOT, acting on behalf of the State and City, procured the services of a
consultant to plan, design and implement the solutions identified above. The State and City
agencies asked the consultant to use the selection and tailoring of user service requirements as
way to guide the development of functional requirements for the project. The Travel and
Transportation Management user services that apply to this scenario are Traffic Control, Incident
Management, and En-Route Driver Information. A Functional Description document was
prepared, along with an Operations Plan detailing the operating agreements referred to above.

User Service Requirements Illustration

User services are defined in the National ITS Architecture Traceability document. As an
example, a list of requirements from Appendix A of the Traceability document that defines the
“Traffic Control”user service in detail is provided below with the specific requirements selected to
be applied in this design shown as bolded. Similar tables were produced for the other two user
services that were investigated. Appendix B of the Traceability document was then used to select
the process specifications (P-specs) that correspond to the selected user service requirements.
These were used in the preparation of the Functional Description document, along with many
additional locally derived requirements and operational concepts forwarded from the task force.

The physical data flows needed to implement the necessary portions of the Traffic Control user
service were selected from Appendix A of the Physical Architecture document and were

2-55
 Developing Traffic Signal Control Systems Using the National ITS Architecture

incorporated into the procurement specification by the consultant. An example of this is provided
below.

TRAFFIC CONTROL (EXCERPT)

Traffic Control provides the capability to efficiently manage the movement of traffic on streets and highways. Four
functions are provided which are (1) Traffic Flow Optimization, (2) Traffic Surveillance, (3) Control Function, and
(4) Provide Information. This will also include control of network signal systems with eventual integration of
freeway control.
1.6.1 Traffic Control shall include a Flow Optimize function to provide the capability to optimize traffic flow.
[Link] The Flow Optimize function shall employ control strategies that seek to maximize traffic-movement
efficiency.
[Link].1 Traffic-movement control shall manage movement of traffic on streets.
[Link].2 Traffic-movement control shall manage movement of traffic on highways.
[Link].3 Traffic-movement control shall include the goal of minimizing delay times.
[Link].4 Traffic-movement control shall include the goal of minimizing energy use.
[Link].5 Traffic-movement control shall include the goal of minimizing air quality impacts due to traffic.
… … ..
[Link] Flow optimize shall be implemented in a manner that seeks to optimize traffic movement over a large
geographic area.
[Link] Flow optimize shall include a Control function that is responsive to both the current demand as well as the
expected demand.
[Link] Flow Optimize shall provide the capability to predict travel patterns.
[Link] The Control Function shall include the use of data acquired from traffic surveillance as feedback to the
control strategies.
[Link] Implementation of the Control Function shall include strategies that account for at least: Human factors and
Driver/traveler behavior and expectancies.
1.6.2 Traffic Control shall include a Traffic Surveillance function.
… … …
[Link] The Device Control Function shall include a "real-time" traffic-adaptive control capability.
[Link] The real-time traffic-adaptive control portion of the Control Function shall be an area wide control to
include several jurisdictions.
[Link].1 The area wide control shall be implemented in an integrated and consistent manner that avoids the
issuance of conflicting controls.
[Link].2 The area wide control shall be implemented in a manner that permits the following types of vehicles to have
preference over other vehicles being controlled; Transit, HOV, Emergency Medical Service Vehicles.
… … … .
[Link].1 Device Control shall include the capability to control traffic signalization, including rapid modification
of signalization parameters to respond to traffic requirements.
[Link].2 Device Control shall include the capability to control dynamically traffic signing .
[Link].3 Device Control shall include the capability to control freeway ramp metering.
[Link].4 Device Control shall include the capability to exercise dynamic control over the infrastructure (such as
reversible-lanes, turning restrictions, etc.).
… … … .
1.6.4 The Control Function shall provide traffic control information to other elements of the ITS, including but
not limited to: Independent Service Provider, In-vehicle navigation, Trip planning, En-Route Driver Information,
Routing systems, and Fleet management systems.

Physical Data Flows Required Selected from Appendix A of Physical Architecture. (Example)

2-56
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Traffic Management to Information Service Provider: traffic information messages

Traffic Management to Other Traffic Management Center: Traffic Management Center coordination
messages

Traffic Management to Roadway Subsystem: signage data messages

Traffic Management to Traffic Operations Personnel: traffic operations data messages

Traffic Operations Personnel to Traffic Management: traffic control commands messages

Applicable Standards - NTCIP Class E

The NTCIP Class E Profile - Center-to-Center “E”xchange - is intended for data exchange
between transportation management centers. The Class E profile will be compatible with Internet
community standards and is designed for high-speed communications. The NTCIP Class E
Profile addresses the need for a protocol that satisfies the communication requirements between
transportation management centers, and includes information service providers. The primary
feature of this profile is the reliable transfer of data and support for routing between network
nodes in a secure environment. The Class E Profile can also be used for the reliable exchange of
data between field devices and controllers that are on public data networks. (See Standard
Requirements Package 6: Traffic Management Subsystem to Other Centers.)

[Link] Funding, Procurement and Implemenation

In consultation with the task force, the consultant then completed preparation of the design Plans,
Specifications, and Cost Estimates (PS&Es). The State and County have decided to implement a
regional traffic control concept and will use the NTCIP Class E as a standard for communicating
information between systems. The State will fund the development and installation of a Regional
Traffic Control subsystem to act as a gateway between the Freeway Management System, the
Arterial Traffic Signal Control Systems, and the ISP. The County and State will upgrade their
computer systems to be compatible with the NTCIP Class E Profile. In addition, the Regional
Traffic Control subsystem will integrate communications and control between the State’s freeway
intersection control elements. Figure 2.6-7 depicts the integration of the two systems which will
enable the solutions identified by the task force.

2-57
Developing Traffic Signal Control Systems Using the National ITS Architecture

Figure 2.6-7 Freeway-Arterial Coordination

2-58
 Developing Traffic Signal Control Systems Using the National ITS Architecture

2.6.3 Transit Vehicle Priority (Using Market Packages)

Signal priority for transit vehicles can be of the greatest benefit to buses that are behind schedule,
providing a way for a bus to make up time along a route. When a bus is behind schedule, it can
request priority – extension of the green phase – allowing passage through the intersection.

Transit vehicle priority provides real-time coordination between the surface street traffic
management system and the transit management system. Integration of these two systems can
reduce overall delay, improve the consistency of transit travel times and headways, improve
traveler mobility, and increase economic productivity. The most obvious benefit, however, is to
travelers on buses who will experience more consistent travel times on routes, and fewer delays
at stops and transfer points. Benefit to the traffic signal control agency comes in the form of
additional surveillance data, including route travel times and vehicle probe data.

This scenario illustrates the use and tailoring of market packages and their supporting cost
analysis and highlights the integration of traffic and transit agency systems.

[Link] Identification of Needs or Problems

Existing Systems
The County Department of Transportation manages both a fleet of buses and the traffic signal
control system. Separate bureaus within the County operate the buses and the traffic signal
control system. Recently the county transit bureau has developed a prototype bus Automated
Vehicle Location (AVL) system based on Automated Vehicle Identification (AVI) technology. The
County’s traffic signal control system is being upgraded incrementally to NTCIP communications.

Objectives
♦ The county transit bureau would like to implement a bus priority system. A transportation
study has determined that coordinating the traffic signal control system and a transit
agency bus AVL system would lead to improved efficiency of the transportation network
and benefit the public.

♦ The traffic signal control bureau wants to investigate and potentially implement a system
that uses the buses as probes to collect traffic flow information and route travel times.

[Link] Identification of Solutions

A task force was formed within the County to improve coordination between the separate bureaus
and to investigate the feasibility of joint projects that would address the objectives of each. Given
the objectives, the task force decided to investigate National ITS Architecture market packages
as a method of identifying possible solutions while ensuring the desired level of functionality.

There are two distinct ways to handle priority systems and both of these methods are supported
by the National ITS Architecture. The first approach involves real-time communications between
the transit management center and the traffic management center (the center-to-center
approach). As the transit vehicle is tracked by the transit system (for example, using an AVL

2-59
 Developing Traffic Signal Control Systems Using the National ITS Architecture

system), its location and priority parameters are sent to the traffic management center. Traffic
signal control is then handled at the traffic management center which controls the signals. At the
transit management center, algorithms might compare the deviation of the transit vehicle from its
schedule and determine whether a signal priority request is warranted. Thresholds may be
instituted to optimize priority requests. These may include: priority when a transit vehicle is
behind schedule, time-of-day, or number of passengers on the bus. The signal priority request
and bus parameters are then sent to the traffic management center. At the traffic management
center, algorithms might determine the current status of the traffic signal controller (for example,
is a green phase already available?), and calculate the potential effects on traffic flow prior to
changing the signal timing pattern at the traffic signal controller. If the traffic algorithm determines
that a change at the signal controller will minimally impact traffic, the proper timing changes can be
sent to the controller. At the traffic signal controller, the timing changes are executed, the status of
the signal priority is sent back to the transit management center, and the bus proceeds through
the signalized intersection. A major advantage of this approach is that more sophisticated traffic
management strategies can be implemented. This approach is shown in figure 2.6-8.

Tag Reader /
Antenna

AVI
ket
ta Pac Controller
Da
Bus Traffic
Management
Transit Center
Management NTCIP
AB
Center
DSRC/
LRMS
Traffic
Signal
Controller

Bus with Transponder

and/ or GPS

Bus Priority Parameters/Probe Data

NTCIP
(Location, Direction of Travel, # of Passengers, E
Headways, Travel time)

= Standards

Figure 2.6-8. Signal Priority For Transit Vehicles Scenario - Center-to-Center Approach

A second approach involves using local communication between the transit vehicle and the
intersection controller (the local coordination approach). In this approach, a transit vehicle
communicates priority requests directly to the traffic signal controller, without involvement of the

2-60
 Developing Traffic Signal Control Systems Using the National ITS Architecture

traffic management center. Local coordination requires a device aboard the transit vehicle (such
as a tag or transponder) which will indicate the vehicle’s approach to the signal, a tag/transponder
reader, and a device at the traffic signal controller (an AVI interface module) that receives the
request and provides the signal priority. A major advantage of this approach is its relative
simplicity, and the costs are potentially lower, since communication with the traffic management
center is not necessary. A major disadvantage of this approach is that it may provide signal
priority whether it is needed or not and consequently may disrupt traffic. This approach is
illustrated in figure 2.6-9.

Local Intersection
Transit Controller Traffic
Loop Detector &
Management Signal Control Management
Module
Center Center

DSRC/
LRMS NTCIP
AB
AVI
Detection
Module
Loops

Bus with Transponder

Bus Parameters
NTCIP
(Location, Bus #, Direction of Travel, # of Passengers) E

= Standards

Figure 2.6-9. Signal Priority For Transit Vehicles - Local Coordination Approach

Based upon these identified solutions, two market packages were selected, Multi-modal
Coordination and Probe Surveillance. These are discussed in more detail in section [Link].
Taken in combination, these market packages will accomplish the transit vehicle priority solution
using local control and provide for future development of center-to-center coordination.

Other Considerations
AVI systems can be enhanced through the use of the Global Positioning System (GPS). A GPS
receiver in a vehicle uses a satellite constellation to determine the location of the vehicle. The

2-61
 Developing Traffic Signal Control Systems Using the National ITS Architecture

GPS receiver can provide the capability to continuously monitor the location of the vehicle.
However, GPS can only tell the vehicle where it (the vehicle) is; it cannot communicate the
vehicle’s location to the transit management center without a communications link. Therefore, an
agency considering a GPS-based solution must develop a wireless wide area communications
network to support the communication of information between the vehicle and the transit
management center.

When developing a transit priority system, regional standards need to be developed to ensure
inter-vendor interoperability and the ability to communicate. Adoption of standards by a region
can facilitate the use of transit vehicles or emergency vehicles across jurisdictional boundaries.
For transit vehicle priority, regional standards will be necessary if multiple traffic agencies or
multiple transit agencies exist within the region. A similar need exists for the adoption of
standards by a region if a single transit agency serves multiple jurisdictions.

Finally, agreements between agencies need to be developed to address when signal priority will
be granted. For example, the agreement may be that buses will only be granted priority if the
vehicle is more than a certain number of minutes behind schedule. Or, the traffic signal controller
will grant priority only if the traffic demand on the cross street is within a certain threshold, and
only after minimum traffic signal clearance intervals are met. Judicious application of transit
priority is necessary to avoid adverse impact to the transportation network.

[Link] Planning and Design of the Solution

After the County identified and selected the Multi-modal Coordination and Probe Surveillance
market packages, they had to tailor them to eliminate unnecessary equipment packages and data
flows that were not going to be implemented (as discussed below). Additionally, flows that may be
needed in the future were planned for, leaving in the necessary “hooks”for later implementation.

Market Package Tailoring Illustration

Multi-Modal Coordination Market Package
The transit vehicle priority function is provided in the National ITS Architecture by the Multi-Modal
Coordination market package. This market package supports communications between multiple
transit agencies and traffic agencies to improve the coordination between the different modes of
transportation and improve the performance of the overall transportation network. Further
descriptions of this market package can be found in the National ITS Architecture Implementation
Strategy document. Figure 2.6-10 shows the Multi-Modal Coordination Market Package.

2-62
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Multi-modal Coordination (APTS7)

Intermodal Trans.
Service Provider

intermodal
information

Transit Transit Vehicle

M anagement transit vehicle
Transit Center Multi- conditions On-board Vehicle
modal Coordination Signal Coordination

request
for local
transit signal
transit signal
system priority
signal priority
data status
priority request

Traffic signal Roadway

M anagement control data
TMC Multi-modal Roadside Signal
request for
Coordination Priority
right of way

Figure 2.6-10. Multi-modal Coordination Market Package

(From Appendix A of the Implementation Strategy)

Based on the functional requirements of the County, the Market Package, Equipment Packages,
and Data Flows were tailored as follows.

TAILORING APTS7
SUBSYSTEM EQUIPMENT PACKAGE IN/OUT/FUTURE
Transit Management Transit Center Multi-modal FUTURE
Coordination
Traffic Management TMC Multi-modal IN
Coordination
Transit Vehicle On-board Vehicle Signal IN
Coordination
Roadway Roadside Signal Priority IN
Intermodal Trans. Service N/A OUT
Provider - Terminator

2-63
 Developing Traffic Signal Control Systems Using the National ITS Architecture

TAILORING APTS7

SUBSYSTEM: FROM -> PHYSICAL DATA FLOW IN/OUT/FUTURE

TO

Transit Management -> transit system data FUTURE

Traffic Management

request for transit signal FUTURE

priority

Traffic Management -> signal priority status FUTURE

Transit Management

Traffic Management -> signal control data IN

Roadway

Roadway -> Traffic request for right of way IN

Management

Transit Vehicle -> Roadway local signal priority request IN

Transit Vehicle -> Transit transit vehicle conditions FUTURE

Management

Intermodal Trans. Service intermodal information OUT

Provider <-> Transit Mgmt

Probe Surveillance Market Package

The Probe Surveillance market package complements the Network Surveillance market package
and provides the same fundamental benefits. This market package, however, does not require an
extensive distributed roadside infrastructure to be deployed, as required by the network
surveillance package, and may be a cost-effective alternative. This market package consists of
transponders on vehicles, roadside beacons, dedicated short-range communications equipment
on vehicles and along the roadways, and communication lines to a traffic center. Other vehicles
with transponders may include emergency vehicles or transit vehicles. Communications media
required may include dedicated short-range communications (beacon-tag), cellular-based digital,
or analog cellular. Data collected from this market package include travel time, speed, and road
conditions. The Probe Surveillance Market Package is shown in figure 2.6-11.

2-64
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Probe Surveillance (ATMS2)

Traffic Roadway
Management vehicle probe data
TMC Probe Roadway Probe
Information Collection Beacons

road network vehicle probe

use data

Information Vehicle
Probe Vehicle
Service Provider Software
ISP Probe
Information Collection vehicle probe data Vehicle Toll/
Parking Interface
Interactive Infrastructure
Information Interactive Vehicle
Reception

position map
fix updates
Location Data Map Update
Source Provider

Figure 2.6-11. Probe Surveillance Market Package

(From Appendix A of the Implementation Strategy)

This market package contains some equipment packages which are not going to be implemented
based on current needs. However, future growth is not excluded by leaving in the “hooks”to
these equipment packages. Since there is no Information Service Provider, the ISP equipment
packages “ISP Probe Information Collection,”and “Interactive Infrastructure Information” are
disregarded. The equipment packages in the vehicle subsystem are reserved for future use as
GPS-based technology matures. Although not addressed in the figure, vehicle probe data or
traffic information flows can be provided directly from Traffic Management to Transit
Management.

The County tailored the Equipment Packages and physical data flows for this Transit Vehicle
Priority project to look like the following:

2-65
 Developing Traffic Signal Control Systems Using the National ITS Architecture

TAILORING ATMS2
SUBSYSTEM EQUIPMENT PACKAGE IN/OUT/FUTURE
Traffic Management TMC Probe Information IN
Collection
Information Service ISP Probe Information OUT
Provider Collection
Interactive Infrastructure OUT
Information
Roadway Roadway Probe Beacons FUTURE
Vehicle Probe Vehicle Software FUTURE
Vehicle Toll/Parking Interface FUTURE
Interactive Vehicle Reception FUTURE
Location Data Source - N/A FUTURE
Terminator
Map Update Provider - N/A OUT
Terminator

Having determined the appropriate equipment packages, the physical data flows were tailored.

TAILORING ATMS2
SUBSYSTEM: FROM -> TO PHYSICAL DATA FLOW IN/OUT/FUTURE
Roadway ->Traffic Management vehicle probe data FUTURE
Information Service Provider -> road network use OUT
Traffic Management
Vehicle -> Roadway vehicle probe data FUTURE
Vehicle -> Information Service vehicle probe data OUT
Provider
Location Data Source -> Vehicle position fix FUTURE

2-66
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Map Update Provider -> Vehicle map updates OUT

2-67
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Identify Standards
The following ITS Standards which may impact these market packages were identified.

National Transportation Communications for ITS Protocol (NTCIP)

At the traffic signal controller, NTCIP is emerging as the prevailing communications protocol
between the traffic management center and the controller. Standard types of controllers that can
currently support transit vehicle priority include the Model 170 controller, the NEMA controller, and
the 2070 controller either through preemption inputs or plug-in modules. A number of NEMA
controllers also offer several programmable control techniques to handle transit vehicle priority.

Transit Communications Interface Protocol (TCIP)

Another communication standard that may be applicable is the Transit Communications Interface
Profile (TCIP). TCIP standards development effort has been created to address the needs of
the transit community. The primary goal of TCIP is to define the data interfaces among transit-
related applications, and to facilitate the transmission of data between disparate departments,
agencies, and transportation management centers. The TCIP development will augment NTCIP
with transit-related information.

TCIP will define the information flows message sets and/or additional class profiles need to
exchange transit information among roadside devices, transit vehicles, and transit operations
centers. It is expected that the final set of specifications for TCIP will be completely compatible
with NTCIP.

Dedicated Short Range Communications (DSRC)

The DSRC standards define the command structures and communications requirements between
roadside beacons and on-board equipment such as transponders and tags. Technologies
available for DSRC include infrared (IR) and radio frequency (RF) beacons.

Location Reference Message Specification (LRMS)

LRMS is an emerging standard which will allow computer systems to share geographic location
information in a consistent manner. LRMS supports the communication of geographic location
data in a number of formats. A few examples include: point location (e.g. longitude, latitude), point
along a roadway or rail (e.g. milepost), landmark (e.g. at Exit 56), and intersection (e.g. at the
corner of Main and Broad Streets). LRMS has been developed to support both communications
in a wireless and non-wireless environment.

The County will keep abreast of these standards efforts during the design and implementation
phases to determine their readiness and applicability to the project.

[Link] Funding, Procurement and Implementation

The County has decided to implement a local coordination approach in the short-term. This is a
cost effective solution which will generate early results. However, the County has decided to
implement GPS technology for the future and has determined that a mix of GPS and AVI will

2-68
 Developing Traffic Signal Control Systems Using the National ITS Architecture

facilitate using the buses as surveillance probes. In the future, when the GPS capabilities have
been added, a center-to-center approach will be used to communicate bus location and priority
parameters.

Cost Analysis
To illustrate the short term solution cost for the traffic signal control bureau, only the portion
allocated to the traffic management center (versus the transit management center) and the traffic
signal control system will be estimated. The Cost Analysis document from the National ITS
Architecture provides an estimate of the costs, both capital and recurring, needed to enable the
Multi-Modal Coordination and Probe Surveillance market packages. These costs are summarized
in table 2.6-5. For more information on generating costs, please refer to section [Link].

Cost Assumptions
♦ 25 Intersections

♦ Software is off-the-shelf.

♦ Communications are leased from a communications service provider.

Table 2.6-5. Summary Cost for Transit Vehicle Priority Scenario

Transit Vehicle Priority Scenario

Initial Capital Investment Equipment Package Cost

(By Market Package)
Multi-modal Coordination - TMC Multi-modal Coordination $ 131,000
Multi-modal Coordination - Roadside Signal Priority $ 325,000
Probe Surveillance - TMC Probe Information Collection $ 180,000
Total Capital Investment $ 636,000

Operations and Equipment Package Cost

Maintenance
(By Market Package)
Multi-modal Coordination - TMC Multi-modal Coordination $ 158,000
Multi-modal Coordination - Roadside Signal Priority $ 1,000
Probe Surveillance - TMC Probe Information Collection $ 70,000
Total Operations & Maintenance Cost / $ 229,000
Year

2-69
 Developing Traffic Signal Control Systems Using the National ITS Architecture

2.7 Summary
This section presented the key concepts of the National ITS Architecture and discussed in some
detail how it can be applied to traffic signal control project development activities. A set of three
traffic signal project application scenarios were presented which used realistic examples to
illustrate these methods.

Some of the key themes of this section include:

♦ The key concepts and elements of the National ITS Architecture as presented in sections
2.4.1-2.4.5 are interrelated and traceable in a variety of ways.

♦ The National ITS Architecture tools are intended to augment and support existing ITS
project development processes, and should be applied with engineering judgment in that
context.

♦ There are many ways to apply the National ITS Architecture to the project development
process.

♦ The National ITS Architecture tools are most applicable in the early stages of project
development.

♦ The National ITS Architecture can be used to provide project developers with additional
options to consider for information exchanges and functionality that may not have initially
been conceived at the outset of the project.

♦ Using the National ITS Architecture should not be viewed as an all-or-nothing requirement;
rather, the material can be used as is, tailored, dropped, or added to as appropriate for the
situation.

♦ The National ITS Architecture is available in several formats, including paper documents,
Microsoft Access  relational databases, and a linked HTML model, which provides
access through a linked model.

♦ Several entry points or methods are also available which make accessing the applicable
information more convenient.

A summary of how the National ITS Architecture can be used to support project development
activities and the most relevant resource material is provided below:

Identification of Needs or Problems (Section 2.5.1)

√ The National ITS Architecture can assist agencies in identifying ITS goals and objectives that
are specific to their needs.

2-70
 Developing Traffic Signal Control Systems Using the National ITS Architecture

√ The Vision Statement can also serve to foster general ideas about the types of local needs
and problem that ITS can be used to address.

Useful National ITS Architecture Documents: Mission Definition, Vision Statement

Identification of Solutions (Section 2.5.2)

√ Agencies can use two major approaches for identifying possible solutions that are supported
by the National ITS Architecture.

♦ User Services

♦ Market Packages

√ Evaluation and Implementation Strategy documents have supporting information that can be
referenced.

Useful National ITS Architecture Documents: Traceability Matrix, Implementation Strategy,

Performance and Benefits Study

Planning and Design of the Solution (Section 2.5.3)

√ The National ITS Architecture can be used as an input to defining project or system functional
requirements. Potential approaches include:

♦ User service requirements - The user service requirements associated with the proposed
solution can be evaluated for their applicability to the project.

♦ Market packages - The high-level architecture defined using the market packages can be
further refined by examining the logical architecture elements that support these
subsystems and architecture flows.

♦ Physical Architecture Subsystems - Agencies can determine the relevant subsystems

associated with a given project and use this as an entry point to accessing the underlying
architecture definition.

√ The physical architecture can be used to support the definition of the information exchange
requirements for a given project.

√ The Standards Requirements document contains detailed information on the requirements for
12 high-priority standards packages, which can be helpful towards the identification of
standards for a given project.

2-71
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Useful National ITS Architecture Documents: Logical Architecture, Physical Architecture,

Traceability, Theory of Operations, Communications Document, Standards Requirements
Document

Funding, Procurement, and Implementation (Section 2.5.4)

√ The Cost Analysis can be used to help estimate planning-level costs for the project. These
costs should be applied cautiously and should not be used as a recipe for determining the
actual costs of ITS deployments.

√ The evaluation documents and the Implementation Strategy can also be used as a general
resource during this final phase of project development.

Useful National ITS Architecture Documents: Physical Architecture, Implementation Strategy,

Cost Analysis

2-72
 Developing Traffic Signal Control Systems Using the National ITS Architecture

3. Regional ITS Planning

Just as individual highways fit into a larger regional transportation system, individual systems that
support the functions of traffic signal control should fit into a larger regional transportation
management context. Because the sharing of information between agencies and the coordination
of operations are central characteristics of ITS, a regional approach is particularly desirable.
Regional ITS planning activities and investment decisions should be carried out within the
framework of the overall transportation planning process and need to be viewed in that context.

Why is regional ITS planning a good idea 1?

♦ It provides a mechanism for bringing stakeholders together to address transportation

operations and management issues of mutual concern.

♦ It promotes greater consideration of systems management and operations as part of a

region’s overall approach to meeting transportation needs.

♦ It facilitates decisions on which ITS services and strategies apply to local needs and
transportation problems.

♦ It allows agencies to coordinate efforts such that future projects will be compatible,
resulting in cost savings and easier integration of systems over time.

♦ It facilitates reaching agreements between agencies on future operational strategies and

information exchanges to be pursued.

♦ It fosters consideration of and attention to detail which is required to ensure coordinated

and cost-effective operation of ITS.

♦ It provides an opportunity to coordinate long term implementation of ITS and establish

general deployment strategies and priorities.

The National ITS Architecture provides an excellent departure point for those engaged in a
regional ITS planning process. The results of this process will set forth how individual
transportation management systems operated by different agencies in different jurisdictions
should work together to provide better transportation management services to the traveling public.
These activities provide a framework for thinking about the needed relationships among
institutions, as well as technical issues such as the information needs of each transportation
management agency, the sources of that information, and how that information can best be
exchanged between the different agencies.

The processes discussed below provide a way of approaching regional ITS planning in a
systematic way, using material from the National ITS Architecture as a guide and departure point.
Use of these or similar processes in regional ITS planning, and following the processes

1
Adapted from “Integrating Intelligent Transportation Systems within the Planning Process: An Interim Handbook”,
TransCore, August 1997, pages 2-8 and 5-2.

3-1
 Developing Traffic Signal Control Systems Using the National ITS Architecture

discussed in Chapter 2 to develop individual projects, allows for sensible evolution of an improved
regional transportation management system that will accommodate emerging national standards
and best practices.

Ideally, the planning activities discussed in this section would be carried out prior to the
implementation of individual projects as discussed in section 2. Projects that are developed after
regional ITS planning decisions have been made can be designed to implement a portion of the
overall ITS strategy and can make use of the information exchanges already decided upon.
However, regional ITS planning activities do not always occur prior to the implementation of
specific projects. Projects that are implemented without the guidance of regional ITS planning can
still make use of the National ITS Architecture as described in section 2.

This section is not intended to cover all aspects of the transportation planning process and the
activities and products which comprise it. For further information on how ITS should be included
within the planning process, refer to the Interim Handbook on Integrating Intelligent Transportation
Systems within the Planning Process (TransCore, August 1997).

Regional ITS planning can be done using a two-phase approach: 1) concept planning, and 2)
implementation planning. The material that follows discusses the activities that are involved in
each of these steps and points out where National ITS Architecture material can be helpful. For
completeness, short sections are then provided for project deployment and evaluation, which are
necessary to implement and monitor the effectiveness of the initiatives decided upon in the
planning process.

3.1 Concept Planning

Concept planning addresses the questions of what transportation management systems and
improvements are needed in the region, and how individual systems can be integrated so that
individual agencies can do a better job of providing services to the public. Concept planning
supports the development of a consensus for a regional transportation management strategy. A
useful analogy is to think of it as a strategic plan. Strategic plan development is typically a
participative process that results in a vision and strategy for the future for an organization.
Similarly, regional ITS concept planning should result in a vision and strategy that reflects the
needs of the various stakeholders in a region, and builds upon systems and relationships already
in place.

Concept planning should consider the problems as well as the existing transportation goals and
objectives of a region as determined through the transportation planning process, and use these
as a basis to compile a set of relevant ITS or transportation management goals, objectives, and
solutions. It may be advisable to revisit some of the assumptions in the existing plan, however, to
see whether new players can be identified who have a stake in ITS, and to broaden the definition
of transportation needs to account for the expanded capabilities of ITS. This periodic review and
revision fits with the overall regional transportation planning process.

Typical steps involved in concept planning include:

3-2
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Stakeholder identification
♦ Identification of existing ITS or transportation management functions
♦ Identification of regional needs
♦ Identification of needed ITS or transportation management functions and improvements

Products of concept planning may include:

♦ A mission statement
♦ A vision statement
♦ Needed transportation management functions and improvements
♦ Assessment measures
♦ A strawman regional architecture

3.1.1 Stakeholder Identification

The list of stakeholders will naturally include all of the traditional transportation management
agencies in a region, including the state highway or transportation department, county and city
operating agencies, and public transportation agencies. The Metropolitan Planning Organization
(MPO) is clearly also an important stakeholder. Effective transportation management planning
also includes consideration of the views of other agencies, such as emergency service providers
(ambulance, fire, police) and private traveler information service providers.

Concept planning provides stakeholders with a process for identifying transportation problems as
well as potential ITS or transportation management solutions to the problems. Identifying what is
needed before determining how to do it is an important aspect of both planning and systems
engineering. Looking at needs from the perspectives of different stakeholders is necessary to
ensure that the total requirements of a regional transportation management system are
considered as the system concept emerges and projects are planned and implemented.

3.1.2 Identification of Existing ITS or Transportation Management

Functions
This is a comprehensive inventory of existing and planned projects/systems in a region.
Information sharing or integration with other systems, whether existing or planned, should be
identified. Existing systems may be characterized by:

♦ The services provided

♦ The stakeholders involved and their responsibilities
♦ The technologies in place
♦ The control and communications structure within the system.
♦ The opportunity to include infrastructure into planned traditional transportation

3-3
 Developing Traffic Signal Control Systems Using the National ITS Architecture

improvement projects (e.g., incorporating conduit into roadway re-construction jobs)

♦ Information flows, including both information sources and recipients
♦ Operating characteristics and responsibilities

3.1.3 Identification of Regional Needs

Regional transportation problems and needs that can potentially be addressed through ITS or
transportation management solutions should be identified in the form of concise statements, such
as reduce accidents at freeway ramp entrances, or improve detection of ice on bridges. These
needs should be developed in the context of the needs, goals, and objectives already developed
as part of the region’s transportation planning process, because these have already been agreed
on by the region’s transportation stakeholders.

Specific objectives and measures of effectiveness ( MOEs) can also be identified at this stage for
use in future performance assessment. MOEs may be either qualitative or quantitative. Each
objective identified through the concept planning process should have at least one MOE
associated with it. The relative weights to be put on the MOEs by the various stakeholders may
be quite different. The explicit assessment of these weights can form the basis for consensus
building among the stakeholders to develop common goals and cooperative programs.

3.1.4 Identification of Needed ITS Functions and Improvements

Once needs have been determined, solutions can be identified. These solutions, or services,
should be detailed enough to be useful in defining projects, identifying their interdependencies,
and in guiding regional ITS architecture development. To facilitate the latter, the information
sharing possibilities associated with each service should be identified. As defined in Section 2.5,
ITS user services and market packages are useful categorizations that help identify
transportation management solutions.

3.1.5 Concept Planning Products

As a method for documenting the outcome of the various steps discussed above, possible
products from a concept planning effort include: a mission statement, vision statement, a regional
ITS improvement plan, and a strawman architecture. As steps in regional ITS planning, these
products begin to document the big picture of the future to guide future ITS project plans and
implementations.

A mission statement is a concise, unambiguous statement of the primary goal or goals of the
regional system. It should be brief, only a few paragraphs in length.

Useful National ITS Architecture Document: Mission Definition

A vision statement contains narrative text providing a non-technical description of the system
concept from the viewpoint of various key user groups. It describes what the system will be like in

3-4
 Developing Traffic Signal Control Systems Using the National ITS Architecture

the future, ranging anywhere from a 5- to 20-year period. It may highlight specific areas, such as
information and communications; public transit; commercial vehicles; cooperation and
coordination of systems; demand management; freeway management; incident management; and
emergency services. A vision statement should use layman’s language understandable to all
stakeholders and may include magazine-style vignettes to convey descriptions of future
scenarios for the general public.

Useful National ITS Architecture Document: Vision

A regional ITS improvement plan can be in the form of tables that depict the region’s
transportation management goals, objectives and assessment measures; existing ITS functions
or services that address these goals and objectives; new services or improvements to be
provided; and the information sharing characteristics of each.

Useful National ITS Architecture Documents: Mission Definition, Implementation Strategy,

Traceability

A strawman architecture is a concept that helps to spur communication among those involved in
the development of the regional transportation management system. It provides a starting point
for discussions, development, and definition. This can take many forms, but typically represents
an informal, immature view of the final implementation. It is based on experience and expertise
gained from earlier system implementations, as well as current and future system requirements
determined through the concept planning process.

A strawman architecture may illustrate:

♦ Transportation agencies and service providers involved with ITS deployment

♦ Applicable communications (center-to-center, center-to-roadside, center-to-vehicle, and
vehicle-to-roadside) required to facilitate effective ITS
♦ Field ITS devices, both existing and planned

Figure 3.1-1 shows an example of a portion of a strawman regional architecture.

3-5
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Commuter Trains
Transit
Management Train Station
Center
Buses

Emergency Vehicles

Signals
Police
Emergency
Management
Detectors Center

Traffic
VMS
Management
Center HAR

CCTV

Figure 3.1-1. Example Strawman Regional Architecture

Useful National ITS Architecture Documents: Physical Architecture, Implementation Strategy

3.2 Implementation Planning

Implementation planning addresses the questions of how the stakeholder organizations in a
region can organize to implement the results of the concept planning process. Just as strategic
plans typically spawn an action plan, so should a regional ITS concept planning process lead to
regional ITS implementation planning.

The steps involved in a typical implementation planning process may include:

♦ Stakeholder identification
♦ Development of a regional ITS architecture
♦ Identification of operational requirements
♦ Linking regional implementation plans with the region’s transportation plan
♦ Time phasing of projects
♦ Developing regional technology agreements

The results of implementation planning will provide aroadmap for how to deploy an integrated,
multi-modal transportation management system for a region. By identifying needed interfaces
among systems in a region, agencies and service providers can incorporate them into their
system requirements to accommodate integration with future ITS applications and systems. This
prevents time-consuming and costly retrofits that might otherwise occur.

3-6
 Developing Traffic Signal Control Systems Using the National ITS Architecture

3.2.1 Stakeholder Identification

The development of an implementation plan should be supported by the same stakeholder
organizations involved in concept planning. However, the representatives of these organizations
that should participate in this stage will typically be individuals knowledgeable about the operations
of the different transportation systems in the region. A structure that involves a steering
committee, consisting of senior representatives from stakeholder organizations, and a technical
committee, consisting of experienced operations personnel from these organizations, will serve
the implementation planning process well.

Active participation during this stage is critical. Support will be needed for inclusion of ITS
projects in the region’s capital plan and, most importantly, to achieve buy-in to the operational
concepts being formulated.

3.2.2 Development of a Regional Architecture

A regional architecture is a framework that provides a top-down approach for defining a regional
transportation management system. A regional architecture will foster a logical and organized
approach to regional ITS implementation and operation.

Regional ITS architecture development should build from the results of concept planning. The
architecture should meld existing systems and services with new systems, services and
improvements identified during concept planning. The regional architecture should:

♦ Identify the different transportation management systems in a region and how they will
interact
♦ Allow multiple agencies, service providers, and users to communicate
♦ Show the responsibilities of the different organizations and service providers involved in
the system
♦ Identify communications and data flows among participants
♦ Support development of open systems (i.e., systems with interfaces that use standard or
known communications protocols)
♦ Incorporate the use of existing or planned systems
♦ Enable synergy among the different systems
♦ Allow for accommodation of new technologies in the future
♦ Provide a framework for multiple design choices
♦ Minimize ambiguity of system design
♦ Provide structure for future planning and growth
♦ Facilitate future system compatibility and interoperability

The architecture should identify all important physical transportation subsystems (by stakeholder/
agency) and external system interfaces and should show information flows between them. A

3-7
 Developing Traffic Signal Control Systems Using the National ITS Architecture

functional description of each of the subsystems should also be developed. The architecture
representation(s) should reflect both the existing and the proposed future ITS situation.

Using the logical and physical architecture concepts discussed in section 2 and in the National
ITS Architecture documents will assist agencies in the process of developing a regional
architecture. Figure 3.2-1 shows how the physical architecture diagram from the National ITS
Architecture can be used as the starting point for a depiction of a regional physical architecture.

The process of implementation planning will require that more detail on the interface requirements
for each of the participating agencies be specified. Figure 3.2-2 shows an example of how the
overall interface requirements vary among the four traffic management systems in a hypothetical
region called Anytown. The architecture flows that are allocated are associated with the Network
Surveillance, Regional Traffic Control, and Traffic Information Dissemination Market Packages.
As can be seen, no two agencies have precisely the same set of allocated architecture flow
requirements since each agency has individual needs and resources for ITS applications.
Developing this level of detail will enable each participating agency to view how they fit into the
overall transportation management picture in the region.

Traveler Subsystems Center Subsystems

Remote
Traveler Traffic Emergency Transit Planning
Information
Support Management Management Management
Service
- Anytown RTA
- Anytown Transit Kiosks Provider
- FMC - Anytown Fire - Anytown Transit - Anytown University
- Traffic Update - Anytown TOC - Anytown Police - Suburbia Transit
- TransInfo - Suburbia TOC - Suburbia Fire
Personal - RBDS Systems - Smalltown TOC* - Suburbia Police
Information - Smalltown Fire
Access - Anytown E-911

Wide Area Wireless Communications Wireline Communications (Fiber Optic)

Dedicated Short Range Communications
Vehicle to Vehicle Communications

Vehicle Roadway
- CCTV
Transit - Loops
Vehicle - Ramp Meters
- VMS
- Anytown Transit AVL - Signals
- Suburbia Transit AVL* - Signal Priority System*

Emergency Parking
Vehicle Management

- City Lots
Vehicle Subsystems Roadside Subsystems - Parking4Cheap Inc.

* Indicates future (planned) system elements

Figure 3.2-1. Example Regional Physical Architecture

3-8
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Roadway surveillance control Traffic Management Traffic Management signal control data
Roadway
local traffic flow

Suburbia signal control data Anytown Smalltown Smalltown

Field Elements signal control status TOC TOC signal control status
Field Elements

TMC coordination

surveillance control surveillance control

Roadway Traffic Management Traffic Management Roadway
local traffic flow local traffic flow

signage data signage data

Anytown signal control data
Anytown State DOT freeway control data Freeway
Field Elements signal control status TOC FMC freeway control status Field Elements

Figure 3.2-2. Regional Traffic Control Architecture Flows Applied in the Anytown
Region

There are several ways to define the regional architecture at the appropriate level of detail by
using the National ITS Architecture information as a starting point. One potential method is
illustrated below:

3-9
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Using the National ITS Architecture to Guide Regional Architecture Development

1. Determine the general subsystems from the National ITS Architecture which roughly correspond to
regional stakeholders or service providers and populate with actual agency names. More than one
agency may be identified for each subsystem at this point. Figure 3.2-1 provides an example of this
initial step. (Step 4 handles the case where stakeholders or systems don’t map to - or are not
addressed by - the National ITS Architecture)

2. Create a top-level physical architecture based on the identification of major information flows
(architecture flows from the National ITS Architecture) between stakeholders that are consistent with
the existing systems and the regional ITS improvement plan. This can be accomplished in several
ways, depending on the extent of existing ITS services and information sharing and the level of detail
and organizational approach of the regional ITS improvement plan. Two potential ways to do this are:

(a) Look at the relevant interfaces contained in the physical architecture to determine and document
the architecture flows which roughly correspond to the regional ITS improvement plan. Combine
these into a single representation.

(b) Determine which market packages most closely represent the existing ITS situation and the
regional ITS improvement plan. Use the market package diagrams to identify and document the most
relevant subsystems, architecture flows, and important external interfaces. Combine and consolidate
these diagrams into a single view.

3. Reevaluate the physical architecture carried over from the previous step . Delete or modify the
portions of the National ITS Architecture (information flows, subsystems, or external interfaces, or
functions) which upon further review don’t apply to the region or are not consistent with the regional
ITS improvement plan.

4. Incorporate any auxiliary specific local requirements or issues ( information flows, subsystems,
external interfaces, or functions) which are not addressed by the National ITS Architecture that exist
or are a part of the regional ITS improvement plan.

5. Add detail or create diagrams that show the interactions and information exchanges of specific
agencies within the region, in accordance with the operations requirements or concept of operations
(roles and responsibilities) decided upon. (See 3.2.3 for more discussion of operations
requirements.) Figure 3.2-2 provides an example of this step.

6. Document the major functions carried out in each subsystem.

Useful National ITS Architecture Documents: Logical Architecture, Volumes 1 and 3, Physical
Architecture, Implementation Strategy, Cost Analysis

3-10
 Developing Traffic Signal Control Systems Using the National ITS Architecture

3.2.3 Operations Requirements

A critical part of implementation planning is the identification of operational requirements of the
planned systems prior to implementation. Development of operational requirements requires
forward thinking by agencies and service providers. Issues to be addressed may include: the
roles and responsibilities of the different organizations, development of a concept of operations,
identification of funding requirements, interactions during incidents or special events, and other
operations and maintenance (O&M) considerations. This includes establishing requirements or
agreements on information sharing and traffic device control responsibilities and authority (e.g.,
deciding if back-up control capability is desired given a loss of power or failure condition). These
decisions will be factored into the regional architecture and will also flow-down through ITS
deployment projects as they are phased in.

Because many ITS services and strategies involve communication and coordination, this step of
planning for operations cannot be overlooked. In the case of ITS, much more is involved than just
thinking about how an individual project is to be operated and maintained (by a single agency)
after it is constructed. The importance of this planning is that a shared operational concept will be
established that will facilitate the future working relationships between agencies and service
providers.

The concept of regional transportation management can significantly impact the O&M activities of
agencies and traveler information service providers. In some cases, it may increase operations
and maintenance costs with the introduction of additional equipment and new technology.
Increased costs may arise from the need for additional staff (or staff training) to operate the
systems and additional (and potentially more expensive) maintenance for these new systems.
The increased investment in operations and maintenance should eventually result in lower user
costs due to improved system efficiency.

Identification of O&M requirements is crucial to the success of a project. The development of

O&M requirements should involve those most knowledgeable about these issues, namely the
personnel responsible for day-to-day operations and maintenance activities in the different
agencies.

The Theory of Operations document can be used to illustrate the sharing of information between
subsystems which is relevant in determining the working relationships needed between different
agencies in order to implement the planned ITS improvements. This type of information can be
invaluable in developing an overall concept of operations.

Useful National ITS Architecture Document: Theory of Operations

3.2.4 Linkage to the Transportation Plan

Implementation planning describes how a regional transportation management system will evolve.
Vital to this characterization is how to package this gradual evolution in terms of projects and
funding. The transportation planning process addresses the relative priority of investments in

3-11
 Developing Traffic Signal Control Systems Using the National ITS Architecture

various transportation improvements, and it is imperative that relevant information from

implementation planning be considered as part that process. Potential opportunities for leveraging
resources, such as adding ITS surveillance and communications infrastructure to facility
reconstruction or capacity expansion projects already planned, should also be explored.

It is important that reasonable estimates of the benefits and costs of specific ITS or
transportation management improvements be provided so that these improvements can be
considered fairly as part of the transportation planning process. The National ITS Architecture
development effort produced information that can assist that process.

[Link] Benefits
The National ITS Architecture also contains material that identifies the likely benefits of integrating
market packages and the context where these benefits may accrue. Tables showing the likely
benefits and context where benefits may accrue for each market package are provided in the
Performance and Benefits Study and the Implementation Strategy. Additional resources for ITS
benefits information are listed in the References section.

Useful National ITS Architecture Documents: Performance Benefits Study, Implementation

Strategy

[Link] Costs
As a tool to assist in the estimation of costs, the National ITS Architecture documentation
contains a series of spreadsheets. Although these should not be used for actual project cost
estimation purposes, they are useful to help agencies estimate ballpark costs for planning
purposes. Examples of how these spreadsheets can be used to estimate costs of market
packages were provided in section 2.6.

Useful National ITS Architecture Document: Cost Analysis

Financial Opportunities and Constraints

Linkage with the capital plan will also require analysis of revenue sources and benefit streams
associated with the regional system implementation. This step is where the potential role for
public/private partnerships can be considered and weighed.

The physical architecture identifies the interconnections among different transportation

subsystems and can assist agencies in determining common components of systems. This may
point out opportunities for sharing resources. Common examples include a communications
infrastructure, surveillance devices, and traveler information systems. An individual agency may
be able to reduce costs by sharing these components while minimizing capital and operating
costs.

Useful National ITS Architecture Document: Implementation Strategy

3-12
 Developing Traffic Signal Control Systems Using the National ITS Architecture

3.2.5 Time Phasing

Because it is unlikely that an entire regional transportation management system will be deployed
under a single project, implementation planning should also address prioritization and time phasing
of projects. This can be based on a number of criteria such as political issues, cost, amount of
impact, and user visibility. The first components that should be implemented are generally those
that:

♦ Fulfill common functions such as surveillance and communications

♦ Have the potential to provide early visible benefits to the user such as reliable traveler
information

Projects need to be defined in sufficient detail so that benefits and costs can be reasonably
estimated. Other elements of the candidate project definition include identification of funding
sources, both for capital and recurring operations and maintenance costs, and identification of
potential implementation impediments.

3.2.6 Regional Technology Agreements

A review and assessment of existing and emerging technologies should also be conducted to
allow agencies to make good choices among the different technology or deployment options. For
example, regional choices on technologies or standards may be required for the
telecommunications infrastructure, electronic toll tags, signal controllers and interfaces, electronic
fare media, and specialized mobile radio systems.

Standards should be identified to provide for interoperability of systems and interchangeability of

components. Identification of standards should consider the current status of ITS standards
development activities, and determine how and when these can best be incorporated into the
designs of the regional system and individual projects. Establishing regional agreements prior to
the issuance of national standards allows for compatibility of systems to be realized sooner at the
local level. After national standards are completed for various interfaces, the regional
stakeholders are likely to want to eventually transition to them (although not all interfaces will be
the subject of a national standards activity and regional standardization may be sufficient in some
cases). The benefits of using national standards include:

♦ Compatible and interoperable ITS deployments

♦ Lower deployment risks, thus stimulating public and private interest in ITS
♦ Reduced product costs by providing an incentive for multiple suppliers
♦ Widened markets for suppliers

Standards development is an ongoing process. As agencies and vendors become educated in

the implementation of standards, the risk and cost associated with system integration should be
reduced.

3-13
 Developing Traffic Signal Control Systems Using the National ITS Architecture

It is sometimes difficult to identify which standards exist and are relevant. The following four-step
process is recommended for choosing the appropriate standards:

1. Develop the regional architecture. Major interfaces and the interface requirements will be
defined as part of this step.

2. Review publicly available information on ITS standards to determine the status of standards
work that is of interest. (See section 5 for more details on where to find this information).

3. Talk to the organizations involved in relevant standards work, such as AASHTO, the Institute
of Transportation Engineers, ITS America, and other standards developing organizations.

4. Select the standards that specify each of the major interfaces of interest.

Regional technology agreements may also specify design options to be followed. Tables provided
in section 4.5 of the National ITS Architecture Implementation Strategy outline some of the major
design options for each of the market packages.

Useful National ITS Architecture Document: Implementation Strategy

3.3 Project Deployment

Regional concept and implementation planning leads to project deployments that fit within a
regional transportation management context. Material in the National ITS Architecture documents
also provides agencies with insight on deployment issues, as discussed previously in section 2.

Project deployment includes detailed design development, procurement, and implementation.

Deployment may also be linked with other capital improvements, such as including conduit for
communication links in roadway re-construction projects. Some helpful project deployment hints
are provided in section 4 of this document.

3.4 Evaluation
Evaluation involves measuring and documenting the quantitative and qualitative impacts and
benefits that are derived from the proposed implementations. An ongoing evaluation process
should be developed that allows for assessment of progress against the measures of
effectiveness developed in the concept planning stage.

It can be very difficult to measure quantitative benefits of many ITS services and improvements
because of the uncertain nature of travel demand on any given day at any given time.
Consequently, qualitative and anecdotal measures can be very useful in illustrating the benefits of
many ITS services, especially to agency decision-makers and political representatives.

Useful National ITS Architecture Documents: Performance and Benefits Study, Evaluation
Results

3-14
Developing Traffic Signal Control Systems Using the National ITS Architecture

3-15
 Developing Traffic Signal Control Systems Using the National ITS Architecture

4. Lessons Learned / Best Practices

This section provides some advice from experience on how to best develop and implement
advanced traffic signal control projects from agencies that have developed and implemented ITS
projects, or are currently developing or implementing ITS projects. Information contained in this
section was derived from phone interviews, focus group sessions, site visits with agencies, and
from the experiences of several consultant organizations. The lessons learned and best
practices in this section are not intended to be guidance or direction from DOT, but are provided
as helpful information.

4.1 Teamwork and Coordination

Teamwork and coordination, involving all stakeholders, plus selecting and empowering the right
kind of program manager and staff, may very well be your key to success.

Teamwork & Coordination may be your Key to Program

Success

4.1.1 Regional Coordination

In order to be most effective, advanced traffic signal control systems must be cooperatively
defined and operated in a coordinated manner with other transportation operating agencies in the
same and neighboring jurisdictions, with transit operating authorities, with emergency services
providers, and with other entities whose operations are impacted by the operation of the traffic
management system. This will call for use of the team approach, involving as many of the
stakeholders as possible, in the development of the program and individual projects, and a building
of trust and working relationships throughout the process, all of which must be carried forward into
the actual operation of the system if full benefits to the public are to be realized.

Some key lessons and best practices:

♦ Include all stakeholders in regional planning and project development phases of ITS
programs.
♦ Involving a regional planning organization with a decision making body and technical
support committees is a key to success of regional coordination.
♦ Direct focus at current and potential ITS projects rather than at broad ITS themes.
♦ Involve police and other public safety agencies early in the planning/development process.
♦ Visit traffic operations centers in other regions to learn about the benefits of ITS projects.
Use the information gathered to get buy-in from agency decision makers and other
stakeholders. Even better, get the decision makers to make the visits and see the
benefits for themselves.

4-1
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Address the region’s needs in ITS projects , rather than just deploying technology for
technology’s sake.
♦ Perform public outreach. Emphasize the cost related benefits of ITS projects to justify ITS
to the public.

4-2
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Share the cost of ITS project staff, facilities, and equipment with other ITS stakeholders in
your region. The term for this is “Resource Sharing”.
♦ Consider the time required to get a Memorandum of Understanding (MOU) developed and
signed by all major stakeholders. Legal issues take a considerable amount of time to
resolve.

It is important to appreciate the fact that ITS deployment programs differ in many respects from
the traditional highway and street projects which state and local DOT’s have for many years
developed, constructed, and maintained. It follows that the process through which ITS programs
are developed must also differ from that which has been used in the past.

An open development process, involving all stakeholders, featuring the team

approach and leading to the building of consensus, trust, and good working
relationships, is essential.

This building of consensus, of trust, and of working relationships will all take special effort on the
part of those developing the program; it will consume more staff time and will significantly lengthen
project development time. However, it is essential for success. As noted in sections 1 and 2, use
of the National ITS Architecture tools can help to offset the additional time by savings in staff time
and project development time.

4.1.2 The Program Development Team

It is important that support for ITS traffic management programs be built and maintained as the
development process moves along. This support will be vital as various approvals are sought
including approval to include the program as a part of the Regional and State Transportation
Improvement Plan, approvals for funding, and approvals of individual projects. That support will
also be vital as the program moves forward into procurement, through system integration and into
actual operation, for highly successful operation will only be achieved through a spirit of
cooperation and accommodation, through the coordination of activities of the many operating
entities. And the best way to develop and to maintain that support is through a continued
involvement of the many stakeholder entities throughout the entire development process. This
group of stakeholders can be referred to as the Program Development Team.

Develop a broadly based Program Development Team involving as many

stakeholders as possible. Keep the Team actively involved throughout the
development of the program; let the Team share in the ownership, the
responsibilities, the credit associated with the program.

The role of the team in the development of the program is a critical consideration. Let the team
members help in shaping the program; let the team members be a part of moving the program
forward; let the team members feel a sense of ownership of the program and a responsibility for
the program; let the team members share in taking credit for the success of the program.

4-3
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Some key lessons and best practices:

♦ Involve the stakeholders throughout the program development process, although staff
should become more technical or more detail oriented as work progresses.
♦ Form separate, but coordinated groups within the Program Development Team to address
planning, design, procurement, and operations.
♦ Carefully define group charters and objectives to heighten productivity and speed results.
♦ Share project successes and credit for successes.

4.1.3 The Program Manager

Many operating agencies that have successfully deployed and operated ITS programs have
attributed much of their success to a common key point, the presence of a “champion" - a person
who fully understands the benefits that can accrue from the program, one who is fully committed to
the program, one who is willing to “go the extra step”to see the program fully deployed and
operational, and one who is skilled in convincing others of the value of the program.

Some key lessons:

♦ Insure continuity of project management.
♦ Select a well-qualified program manager.

The program manager should have a background in transportation engineering and in traffic
management. Training in systems engineering and program management disciplines would be
beneficial. He/she should possess both communications and people skills, as well as being
computer literate. It is important that the “champion”hold a relatively high position within the
organization, and be respected both within and outside of the organization.

Assign a well qualified “champion”as Program/Project Manager.

Program management continuity will be crucial to program

outcome.

4.1.4 Staffing the Program

Selection of the key staff to support regional transportation planning and to perform the project
development work is very important. These must be staff that have basic transportation
management experience and may be trained to achieve some basic knowledge of National ITS
Architecture application.

Some key lessons and best practices:

♦ Address staffing issues early. Prior to the start of an ITS project, ensure that adequate,
technically qualified staff are available to the project manager.

4-4
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Involve the agency that governs hiring as early as possible.

♦ Do not underestimate the time requirements involved in the training of public agency staff.
♦ Involve operations and maintenance personnel in all phases of ITS project planning and
deployment so that their roles, responsibilities, and needs are accurately defined and
addressed.
♦ Include procurement personnel at the beginning of the project. Procurement is as important
a phase of the project development as the design and build phases.
♦ Involve legal staffs early in the process to prevent fatal flaws such as non-conformance
with federal, state, and local laws and regulations.

4.2 Project Development Process

Fundamental steps used by transportation agencies in the formulation and implementation of

projects involve assessing problems or needs, the search for and selection of a solution, design
of the project, and finally, the funding , procurement and implementation. These are the same
process steps described in section 2.

4.2.1 Identification of Needs or Problems

In developing any ITS project, one must keep in mind the age-old axiom: Let the problem drive the
solution.

Some key lessons and best practices:

♦ Gaining consensus on the project definition, users, user needs, and user requirements can
take several passes.
♦ Consider use of focus groups to help determine users, user needs, and technologies
involved.

A thorough analysis of the operational problems being experienced needs to be made early in the
process. The exact nature, the magnitude, and the extent of the problem; and the conditions that
are causing the problem, need to be fully understood before even beginning to consider the
solutions.

Use a needs-driven approach in developing the program and

always LET THE PROBLEM DRIVE THE SOLUTION.

This needs-driven approach becomes particularly important in ITS projects. It has been noted all
too frequently that, in the consuming drive to bring high technology systems to the transportation
scene, the process has been reversed, resulting in an approach in which one finds high
technology “solutions”in search of a problem. This can result in a high cost project that falls short
of doing the job that needs to be done.

4-5
 Developing Traffic Signal Control Systems Using the National ITS Architecture

4.2.2 Identification of Solutions

As a first step in the development of solutions, key individuals involved with the program should
become thoroughly knowledgeable on what solutions (generically) have worked for others. It is
also important that staff be aware of those which have not worked and why they have not worked.
There are several ways to do this and possibilities include: communicating with other agencies
who are operating ITS applications, attendance at Federal Highway Administration and Federal
Transit Administration courses, a review of the literature, attendance at seminars, workshops and
conferences covering the subject, and seeking advice from your FHWA Division or FTA Region
Offices. Courses may be provided as part of the ITS professional capacity building program: see
the Office of Traffic Management and ITS Application web page at
<[Link] Whatever the means, getting key project staff
“up-to-speed”on ITS applications to traffic management problems is a critical activity that must be
carried out.

The project staff that are knowledgeable of ITS solutions to traffic management, including traffic
signal control, problems must be engaged in identification of the more favorable solutions to the
problems being addressed. From this list of solutions, the trade-offs of costs and benefits plus
any other impacts and considerations such as impact on maintenance and operations staffing
and costs, of the solutions should be addressed and recommendations prepared. The
recommendations coming out of this activity will be a key input to transportation planning process,
see Section 3.

Some key lessons and best practices:

♦ Act to ensure that key staff are up-to-speed on ITS applications. The first verbal contacts
for further information on this should be directed to your FHWA Division or FTA Region
Offices.
♦ Consider operational and maintenance impact as well as capital cost and potential
benefits.

4.2.3 Planning and Design of the Solution

Detailed design of the project should proceed based upon those systems which have been
defined in the solution definition and analysis. During the project design phase, as the full
implications of using specific hardware/software systems come more into focus, it may be
necessary to rethink some of the decisions reflected in prior planning. It is fully appropriate - in
fact, it should be viewed as a responsibility, to make trade-offs, and appropriate changes in the
project at this point in the project development process. Some of these trade-offs will be in traffic
signal control system configuration alternatives as described in section 2.

There are two general approaches which have been taken in deploying traffic management
systems, and thus, in the defining of the project to be implemented: (1) the full deployment
approach in which the entire traffic management system is deployed under one construction
contract, or one design-build contract, and (2) a staged project approach in which separate
contracts are awarded for the construction of a number of stand-alone subsystems, which when
completed, will comprise the comprehensive traffic management system.

4-6
 Developing Traffic Signal Control Systems Using the National ITS Architecture

The “Full Deployment”procurement approach requires funding for the deployment of the traffic
management system in its entirety under one contract. This approach will produce the entire
system as a whole, rather than as the combination of a series of individually contracted sub-
systems. With one contractor having responsibility for the entire system, the integration problems
should be minimized, thus helping to ensure interoperability. The components of the system must
be made to work together before the contractor’s performance is accepted and full payment is
made, so there is the potential of the contractor to play down the importance of those problems
associated with the integration of complex systems. However, with carefully-planned, progress
payments tied to specific accomplishment milestones of contractor performance, the pressure on
the contractor is reduced somewhat. Higher levels of annual funding, always difficult to secure in
today’s environment of funding shortfalls, are required for this project approach. The operating
staff is also suddenly faced with the operation of the entire system all at once and there is no time
for staff to grow into that level of operation through operating smaller, less complex sub-systems.
Advance arrangements need to be made for operations and maintenance training.

Under “Staged’, “Incremental”or ‘Evolutionary”approach, a series of projects, each consisting of

a stand-alone subsystem capable of delivering benefits, are constructed under separate
contracts over a period of time. Each subsequent sub-system is integrated with those which have
preceded it, evolving into the comprehensive system. One of the major areas that must be
addressed up front is definition of the communications facility or capability that will handle the
long-term needs of the transportation system. The greatest risk of the staged project approach
has to do with those problems associated the integration of new systems with those which are
already on-line, and with the assignment for accountability of that function. When two subsystems
can’t be integrated and one or both subsystems have to be modified, the costs may increase
substantially. However, there are advantages. Available funding levels are less of a problem, as
projects to match available funding levels can be spaced out over a period of time. There is the
opportunity to select “winners”, those projects on which there is a high probability of success, as
early projects with very visible benefits. Systems come on-line at a more manageable pace.
There are the advantages associated with evolution: building staff skills, evolving operational
procedures, and building inter-agency working relationships can be accomplished along with the
development of the system; the concept of traffic management is allowed to grow and mature as
the overall system evolves; traffic management measures are introduced to the public in smaller,
perhaps more acceptable, increments.

Some best practices for defining the project:

♦ Use an open architecture based on the National ITS Architecture and ITS standards as the
basis for design.
♦ If you are considering adding adaptive control to your system, make sure that you can
switch it on and off, or can run on a time of day schedule. Make sure you have a fall back
position if you are not satisfied with the adaptive control, and that the technology is
compatible with traffic signal control equipment standards in your region.
♦ Several agencies have concluded that a process of phased implementation for ITS projects
is optimal. It may not be necessary to deploy all the planned technologies, functions, and
equipment needed for your new traffic signal control system initially. Incremental
deployment will allow agencies to manage budget and staffing level growth. For a phased
implementation the system must be designed initially for the addition of future functionality
and incremental expansion.
♦ Be realistic about your capabilities and get help accordingly. Use integrators and

4-7
 Developing Traffic Signal Control Systems Using the National ITS Architecture

consultants to assist in the project.

♦ Conduct a communications study to make sure that future requirements are
accommodated by the system design (i.e. number and type of devices: computers,
controllers, cameras, variable message signs, etc.). Communications analysis can easily
be overlooked when most of the design discussions center around the central computer /
traffic management center needs and field element considerations. Overlooking this area
can be a costly mistake for replacement of inadequate communications.
♦ Build only what you can realistically maintain. During the design and build phases of the
project, maintain realistic maintainability/reliability expectations.
♦ Do not rush the project planning, requirements, and specification phases. To avoid delays
during the development and installation phases, define the project requirements clearly.
Also design to the needs that have been defined. Always keep the needs developed and
approved through the planning phases sharply in focus.
♦ In order to ensure the reliability and functionality of enabling technologies, it is
recommended that the agency developing ITS applications fully investigate previous
applications of candidate technologies in real world applications. These investigations
should include discussions and/or site visits to agencies that have previously deployed the
technologies. It is also important that these investigations be carried out independently of
the vendors.
♦ Performance standards for all system components must be defined.

Some key lessons about implementing advanced traffic signal control functions
♦ Emergency Vehicle Preemption
− If you are planning to add emergency vehicle preemption to your system, consider
doing it area-wide to realize the greatest benefits.
− Make sure you consider and address the issue of latency -- i.e. how long it takes the
system to recover from a preemption request. Specify that the system shall re-
synchronize within a certain number of cycles - one cycle versus three or four cycles.
− Make sure that you consider signals near railroad at-grade crossings / light-rail
crossings when considering preemption.
♦ Transit Vehicle Priority
− Perform a transportation study to limit the number of bus routes to include in the
priority strategy. Bus priority for routes should be implemented judiciously to maximize
the benefits to bus passengers and reduce the overall cost and impact on the traffic
system and traffic network.
− In one region, the planning period took about two years longer than originally expected.
But the extra time spent was well worth it to reach consensus among the involved
parties and to articulate and include each party’s anticipated benefits in the strategic
plan.
− Bus priority needs to be flexible. It should be something that can be scheduled
according to time-of-day, switched on and off, or simply requested as needed to help
alleviate bus “bunching”or to help restore scheduled headways.

4-8
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Camera Surveillance
− Camera systems have been a great success in one city, in terms of traffic
management improvement and in terms of raising the public’s awareness of traffic
management in the city. Camera video in this city is routed to the media and
broadcast to the public. The city recommends developing a policy about what video
signals can be provided to the media. The city has determined that it is important to be
able to restrict video to the media under certain situations, namely during enforcement
activities, and handling of incidents.

It is essential that ITS systems be designed to do the job needed to solve the transportation
problem, to provide for compatibility of operation with a variety of systems being operated by other
transportation-related entities, to provide for interoperability with those other systems, and to be
designed so that they can be reasonably modified and/or expanded in the future.

4.2.4 Funding, Procurement, and Implementation

[Link] The Schedule

The schedule must be well thought out, be realistic, clearly show task inter-relationships, and be in
a form which can be easily communicated and understood. It must have the commitment of the
project team. It should be used on a continuing basis as one of the most powerful tools in
managing the project. All reasonable steps should be taken by all parties to adhere to the
schedule. It should be up-dated and adjusted when slippage’s do occur.

Some key lessons and best practices:

♦ Do not adopt an optimistic schedule.
♦ Define frequent and realistic milestones to use in assessing progress against the schedule.
♦ Unambiguously define all milestones.
♦ Define each milestone so that reaching it is clearly identifiable.
♦ Make reasonable efforts to keep the project on schedule. However, never cut schedules
for reviews of design documentation, for preliminary and final design review presentations
by the contractor, for system integration, or for thorough testing, in the factory, at the first
field site and at every field site. When needed to preserve these critical activities, extend
the schedule.

[Link] Funding the Program

Obtaining funding for the project is one of the most critical responsibilities of the project manager
and his/her higher management. It is essential that he/she “think funding”from the inception of the
program, seeking out every opportunity to secure funding from a variety of sources for the
various elements of the overall program. One goal should be to secure funding from a number of
sources---the more the better---for the commitment of funding assures that there is a support for
the overall program from that funding source. The commitment of funding from private sources,

4-9
 Developing Traffic Signal Control Systems Using the National ITS Architecture

through public/private partnerships or other arrangements, further strengthens the program

insofar as competing for funds from public sources.

Develop a broad-based funding package, with funding coming from as many

sources as possible.

It is important that the project get into the programming process as early as possible in the project
development phase, in order that funding will, in fact, be available at the time the project is ready
for construction. While many ITS projects in the past were funded without going through the
Transportation Improvement Planning (TIP) process (since they were funded as under a research
or operational test environment), steps should be taken to have the project included in the TIP, in
order to ensure eligibility for funding. Projects need to be entered into the programming stream to
obtain funding from other sources.

It is also important to keep in mind that traffic management projects carry with them the obligation
to operate and maintain the systems. Thus, it is important to not only obtain capital outlay funding,
but also to secure the commitment for covering the on-going operating and maintenance costs.

Identify funding sources, and carry projects into the programming processes
at the earliest possible stage of project development. Secure approvals for
staffing levels to operate systems, and for funding to cover other on-going
operating and maintenance cost, such as contract maintenance.

[Link] Agency / Contractor Interaction and Other Issues

Many agencies strive to keep the contractor “at a distance” which would work well in a perfect
world where requirements are perfectly described and understood and where the contractor’s
design is perfectly described and understood. Lacking this perfect world, developing a
cooperative working relationship between agency and contractor is most likely to yield a system
that meets agency requirements. In such a relationship, it is appropriate that rules be established
to limit information going to the contractor from agency staff and other agency representatives to
“interpretations of the requirements,”and within the contract scope. Included must be the
admonition that only through contracting officer direction may the scope of the contract be
changed.

Some key lessons and best practices:

♦ Don’t simply take a vendor’s or contractor’s advice or word on the capabilities of a system
or piece of equipment. Ask them: “Has the (system / software / equipment) been used in a
traffic signal control system before? Has the (system / software / equipment) been used
to perform this (task / function) before?” Be sure to obtain references as to where these
applications were and what agencies were involved and then talk to those references.
♦ Make sure the company from which you are purchasing services or equipment from is
financially sound. Check business and technical references. Talk to others in the field who
have done what you are planning to do.
♦ Maintain focus on the system’s final configuration definition. Keep the system developer’s
focus on the requirements of the final product, not just the next deliverable.

4-10
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Take the time needed to review important project requirements. For larger projects, allow
the contractor / equipment vendors at least two passes (one draft, one final) to develop the
user requirements and the equipment and software specifications. For smaller projects,
one pass may suffice. Arrange in the contractor’s work statement for audio/visual
presentations of the draft and final designs to agency staff, plus other agency
representatives and project stakeholders. This is helpful in identifying requirements
misinterpretations.
♦ Allow sufficient time for a comprehensive review of draft and final versions of specifications
and requirements.
♦ When significant amounts of software development are involved, arrange to have one or
two key staff and expert software engineer representatives sit in on the contractor’s
internal software design walk throughs, since these cover how the system will work in some
detail and may highlight misinterpretations.

[Link] Managing the Program

There are many lessons that have been learned on ITS projects and on other kinds of projects,
including those from program management efforts of other civil and defense agencies. Although
most ITS projects are much smaller in scope than most defense projects, many of the lessons
apply. Most of the system engineering tools that other agencies have used are beyond the scope
of this document, but guidance on courses or seminars that describe application of those tools to
ITS projects is available from the FHWA Division or FTA Region Offices.

Some key lessons and best practices:

♦ Look for success stories in the ITS field prior to starting your ITS project. Learn from
projects related to what you are trying to do – what are the benefits? Was it cost
effective? Also check out the benefits reference documents. This will help you to support
your project as it develops.
♦ Provide upper management and decision makers with real examples of successfully
deployed ITS projects. This is a way for agencies to overcome resistance to ITS
technologies. Example projects should relate to the unique transportation problems in your
region.
♦ Use the design/build process to get systems operating early whenever appropriate.
However, it is important to separate the design aspects of the project from the build by
thorough review of all design aspects. The review time required for a design should not be
underestimated.
♦ Manage project and system expectations. They need to be realistic and achievable with
available funding, time (schedule), and staffing.
♦ Exceeding the costs estimated for software development is highly probable and a major
problem in the industry. Cost overruns are common in ITS projects. Agencies need to be
prepared for these overruns by developing contingency plans. Contractors can only base
realistic software development cost on detailed requirements and specifications.
♦ Use technical proposals and preliminary and final design reviews to achieve compatible
agency and contractor interpretations of requirements as early as possible. Differing
interpretations will yield false starts and wasted effort, time and money.

4-11
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ As unanticipated problems occur, the schedule slips, staff once available becomes
unavailable, budgets appear inadequate - a few words of advice:
− Take a step back and take a look at the big picture to reassess where the project
stands. Back away from trying to cope with numerous details and topics with which
you may not be completely familiar.

− Revisit your project plan. To help bring the project back on track, all parties involved
will need to be honest about achieving project expectations, and about assessing what
can be realistically accomplished with available resources.

− Be reasonable about deliverables, schedule, scope, and requirements.

− Focus on the system features that will bring the most benefit. Consider dropping less
significant aspects of the project.

− Focus on what has been accomplished so far, rather than on how much is left to do.
Other staff may need reassurance. Positive motivation can be very helpful to your
team, and help you get through a crisis.

− Create an environment that encourages solutions, rather than focusing on problems.

Establish an environment in which your agency, the equipment vendors, and
contractors can cooperate to complete the project successfully.

♦ Share your successes, and share credit for your successes.

♦ Learn and share lessons from all projects. Create an environment where engineers from
different backgrounds and projects have an opportunity to share their experiences with
each other – begin a “brown bag”lunch program or project / technologies discussion
group.
♦ It is critical that initial ITS project deployments provide immediate, visible and significant
benefits. Failure to do this will make it harder to secure funds for future ITS projects.
♦ Reduce the risk of failure by deploying ITS projects incrementally and by using proven
technologies.
♦ Document control is very important. Track and control project documentation. Use a
numbering scheme, such as PROJECT-TASK-YEAR-DOCUMENT NUMBER-REVISION
LEVEL.
♦ Share your funding experiences for design, construction, operations and maintenance.
♦ Share your experience using Federal-aid funding for operations cost and how to work with
your metropolitan planning organizations (MPOs) to get their support.

[Link] System Integration and Testing

Being very thorough in the integration and testing of your system will be as important, perhaps
more important, than anything else you do on the project, including writing complete and accurate
specifications. System integration and testing will be needed at different levels. During
development, integration and test will be accomplished the first time and must be very thorough,
testing against every requirement. This testing may include rigorous testing, analyses and
demonstrations. Acceptance testing in the field need not test every requirement, but must ensure
that the deliverable is acceptable.

4-12
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Some key lessons and best practices:

♦ Integration of existing / working technologies is hard enough without introducing new and
untried technologies.
♦ Systems can be built incrementally, however, any necessary communications equipment
needs to be in place for integration with prior and future increments.
♦ Integration needs to be done in a controlled environment (e.g. design or factory
acceptance tests) to isolate problems and system bugs. Interfaces with some devices
may have to be emulated for early integration efforts.
♦ Do integration in steps − add one component at a time. Do not wait until the end of the
project to integrate all of the system components, since it would be extremely difficult to
isolate problems. Integration and testing can easily take 30-40% of the time and
resources of a project.
♦ Take the time to thoroughly debug and test a few units in the field prior to deploying a large
number in the field. Require contractors to successfully conduct acceptance tests on
each major deliverable, witnessed by the agency’s representatives prior to acceptance by
the agency.
♦ When changes are made in some area of a design, keep in mind that there may be
desirable and undesirable consequences of the change that may ripple through the
design, and testing must ensure that the device, unit, or subsystem still functions properly
after the change.
♦ Perform operational and maintenance training early. Use those trained staff in hands-on
roles for operational and maintenance testing, particularly final development test in the
factory and final acceptance test at the first field site. This must be written into the
contract since contractors will otherwise not allow non-contractor staff to touch their
equipment.

4.3 Procurement and Contracting

Traffic management agencies face many impediments in the procurement and contracting of
developing projects, as procedures and controls and measures which have been put into place
over the years for highway construction projects have had to be accommodated. However, there
is some relief for these impediments. This section sheds some light on the more common
problems that have been experienced, and some of the solutions that have been developed.

4.3.1 Autonomy in the Procurement Process

In some agencies, it has been practice to clearly separate the procurement function from those
who will use the goods or services procured. This autonomy in the procurement process is seen
as providing certain assurances relative to the proper expenditure and management of public
funds. However, because of the technical complexity of most ITS systems, and the need for
these systems to be interoperable, technical and operational advice is critical in making wise
procurement decisions.

4-13
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Transportation management agencies should balance the need for autonomy in procurement with
the obvious need for those with the technical and operational knowledge of ITS systems to
participate in the procurement process. A sufficient degree of autonomy can be maintained while
still involving technical staff, by adopting a team approach to procurement, which would include
technical advisers and budget and procurement personnel. By bringing both sides together, each
can gain a better understanding of the knowledge each brings to the discussions.

It is crucial in ITS procurements that technical/operational, budgetary, and

management elements be involved in proposal evaluation with each presenting its
findings to a selection board. Bids from contractors that are not judged
responsible companies able to perform or with technical proposals that are not
technically acceptable should be rejected.

This will allow the technical advisers to make recommendations on the extent to which or even
whether the types of technology and systems available will meet agency needs, and the
procurement specialists to outline budget, financial, and procurement restrictions that may impact
how the type of technology or service is to be procured.

4.3.2 Selection of the Contracting Approach

The selection of a particular contracting arrangement for deploying ITS traffic management
systems is critical to the successful deployment of these systems, and, ultimately, to the
successful operation of these systems. Three contracting approaches to the deployment of
these systems, discussed below, have been used; the use of each has met with varying degrees
of success. See also a paper on innovative contracting for ITS projects [Innovative Contracting
Practices for ITS, April 1997] and another paper on procurement regulations and contracting
options [FHWA Federal-Aid ITS Procurement Regulations and Contracting Options, August 1997]
both available on the FHWA ITS web page . This paper, available in hardcopy from NTIS or
electronically from the Turner Fairbanks Highway Research Center web page, is a valuable
resource. Figure 1 of that paper identifies four basic contract types, their possible application,
and their approval requirements. Three of those approaches are discussed below.

Conventional PS&E/Contract Bid Approach

In this approach, the designer develops specifications for both software and hardware, and these
are included in the PS&E (Procurement Specification and Estimate) package and RFP (Request
For Procurement). A contract for the construction, hardware, and software to deploy the system
is then let in the manner of a conventional highway contract. This contracting approach may be
appropriate for procurement and contractor installation of field devices and hardware. However,
for design, development, integration and system engineering services, this approach has resulted
in some problems in the past. Hardware/software incompatibilities have arisen, and these
systems have not performed as anticipated. In some cases, major modifications in hardware
and/or software was called for in order to produce working systems. Resolution of issues relative
to the accountability for these deficiencies, and of the responsibility for the development and
deployment of corrective measures have proven to be particularly difficult in many cases. In
general, this approach does not work well for technology acquisition.

System Manager Approach

4-14
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Under the system manager approach, a consultant is engaged to develop the software and
hardware specifications for the traffic signal control system, and to produce a PS&E for the
project. Contracting for the system manager’s services falls under the Engineering and Design
Services contract category which includes services like program and construction management,
engineering, design, and surveying. Using the PS&E developed by the system manager, a
contract for furnishing and installing hardware, and for other required items is let, using traditional
contracting procedures as in the contract-bid category of contracting. Here, a key difference
comes into play: the software/hardware consultant’s responsibilities carry into the deployment
phase of the system under this approach. The consultant is responsible for the final design and
development of software and for integrating it with the hardware as it is installed, and for providing
documentation and training to operating staff in the use of the integrated system. Several
advantages to the system manager approach have been noted:
♦ The process includes competitive bidding, with all of its benefits, for the furnishing and
installing of hardware, and for facility and electrical construction.
♦ Access to those developing the system software, and agency control over system
development, are greatly facilitated. If the control system hardware is included with the
software bid, a hardware contractor who does not produce software could win the bid.
The hardware company will subcontract the software to a software company. The client
then has very limited access and control over the system development and may not be
able to ensure that the system meets its requirements.
♦ The system manager approach gives the flexibility to incorporate the latest technologies
into the system, as well as to provide integration with other traffic control systems which
may be operating on other roadway networks. It is important to avoid the low-bid
syndrome, where the software is designed to do the absolute minimum required to meet
the specifications rather than take advantage of the latest thinking and processes in a
rapidly evolving technological market.

Design/Build Approach

In this approach, a contractor is selected based on the contractor’s qualifications and an

assessment of the contractor’s ability to perform followed by competitive negotiation. This single
competitive contract is then awarded for design and construction of the project. This differs from
the design-bid-build approach in that design-bid-build uses two sequential competitively awarded
contracts, the first for design and the second for construction. The design/build approach
traditionally combines the procurement procedures employed with the traditional engineering and
design services contracts with those used in the traditional construction contracts, and thus
embodies characteristics of both. These procedures may include pre-qualification, competitive
sealed bidding, and award criteria based on price and other factors. It may be useful to require
separate detailed technical proposals and cost/business proposals and evaluate technical
proposals first. Then the predetermined selection criteria would include evaluation of the
offerors’technical proposals that have been found to be acceptable, by a predefined set of
criteria. This approach will provide indications of the each offeror’s skills, understanding, and
approach to the project. The negative is that the project requirements must be spelled out in the
RFP so that the offerors can respond to them.

The design/build approach relies on the contractor to develop a design and then to build the
project. The agency’s role is to monitor the contractor’s work. Generally this has worked for
roadways and structures. However, it may have significant problems when applied to technology

4-15
 Developing Traffic Signal Control Systems Using the National ITS Architecture

acquisition depending on contract type (e.g., fixed price or cost type) and the nature of the
relationship between the agency and contractor. If the agency has a hands-off approach to
contract management, the contractor may design and build much of the system based on
incorrect interpretations of requirements. Some of the work may be found to be unacceptable.
Partnering of the agency and contractor so that requirements are properly interpreted and the
design is reviewed by agency representatives and found acceptable, before construction and
implementation work proceeds, can lead to positive results. However, if the entire contract is a
fixed price type, the contractor has an incentive to interpret requirements, produce a design, and
build the system to minimize the contractor’s cost. A way to address this issue is to have the
agency more directly involved in the clarification of requirements during contract performance.
This, in turn, may increase the contract scope. Also, if the contractor subcontracts the software to
be designed and built by another contractor, there may be lack of visibility into the software
development process. This is likely to result in a lack of agency knowledge and control of the
software and an unacceptable system.

FHWA established Special Experimental Project No. 14 , Innovative Contracting Practices (SEP-
14) to enable agencies to implement and evaluate innovative contracting practices that maintain
competition advantages while striving for quality and timeliness. Included under SEP-14 are
Experimental Design-Build and Non-Experimental Cost-Plus-Time contracting innovations.
Federal-aid funds may be used in design-build contracts when awarded with competitive bidding
procedures and subject to FHWA approval under SEP-14.

Give full consideration to the use of the System Manager Approach when
deciding upon the contracting arrangement to use.

4.3.3 Procurement Rules and Regulations

Although federal legislative requirements mandating the use of low bid procurements have been
relaxed in recent years, many states still require its use for procuring many services and
equipment. In addition, it is still the preferred method for acquiring construction services in the
public sector. But there can be problems with accepting low bids for ITS systems and devices.
Some key lessons about low bids:
♦ An important problem with low bids: the equipment and software are frequently designed
to do the absolute minimum required to meet the specifications rather than take advantage
of the latest advances in technology.
♦ The design of the system provided by a low bidder may have many misinterpretations of
the requirements with major cost increases for the corrections thus allowing the bidder to
bid very low, with later scope increases. Specified requirements must be accurate and
thorough. Even then a low bidding contractor will find ways to reduce costs by not meeting
requirements or by misinterpreting requirements.
♦ Often systems that are low bid have limited expansion capabilities. These limitations are
frequently not discovered until control elements are expanded or modified at a later date.
♦ As upgrades to the system hardware and software are needed in later years, there may
be design problems that require very expensive redesign and expansion of the system.

4-16
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Traditional transportation procurement approaches will usually not provide the flexibility necessary
for acquiring ITS projects. In an effort to provide greater flexibility to state and local governments
in their procurement procedures, the U.S. Office of Management and Budget established the
Common Rule governing grants administration. The rule provides that states will spend and
account for grant funds according to their own laws and procedures. While some procurement
methods have very specific federal rules to be followed (particularly procurements for
architect/engineering services for construction projects), there is considerable flexibility in most
other procurement models.

Project team members should work together to select the most appropriate procurement
mechanism, contracting lead agency, and contracting approach for any particular project. In
selecting the procurement and contracting approach, the most favorable alternatives need to be
compared side-by-side listing all pros and cons of each. Decisions relative to project team
members, as well as procurement-related issues, need to be made early in the project
development process since many facets of the project will be impacted by these decisions.

4.3.4 Procuring Software

Procuring software has always been complex and care must be exercised to control the risks
inherent in this activity. There are many important topics to be informed of on software
acquisition. As of 1998, U.S. DOT is preparing an ITS software acquisition guidance document.
Some of the key topics covered include the following, all of which are important:
♦ Acquisition approaches
♦ Consideration of commercial-off-the-shelf (COTS) software with its pros and cons
♦ Importance of requirements
♦ Acceptance criteria
♦ Intellectual property rights
♦ Schedule issues

The document is built around people, management, and system themes that encourage partnering
between the agency and software contractor to ensure understanding and translation of
requirements into software.

Using “off-the-shelf”software packages and systems are often touted as low risk, but may or may
not reduce risk. Making major changes to an existing software system may be quite difficult.
Nevertheless, agencies should familiarize themselves with the different product offerings before
issuing procurement documents since it may be possible to meet requirements while saving time
and money. A key point - careful consideration should be given to requirements that might involve
extensive new software development or extensive product offering changes because of the risk
implications.

4.3.5 Procuring Telecommunications

Just as transportation is the backbone of our communities, serving to move people and goods
from point to point, telecommunications is the backbone of ITS, serving to move information

4-17
 Developing Traffic Signal Control Systems Using the National ITS Architecture

among detectors, transportation management centers, and field devices. Telecommunications is

vital and expensive. A new telecommunications system can be the highest cost item in an ITS
deployment project. A telecommunications analysis including the three steps below should
support telecommunications decisions:
♦ Requirements Definition
♦ Definition of Network Options
♦ Cost Analysis

The Requirements Definition step is the most important. Good decisions can only be made if
care is taken during this step of the analysis. The product of requirements definition is a
reasonable estimate of how much information needs to be moved from point to point throughout
the system in its future fully deployed state. To do this, a rigorous estimation process that
focuses on needs rather than possibilities must be followed. This must be supported by an
understanding of the types of devices to be installed, where they will be, how many there will be,
message sizes and frequencies, etc. Also, the region’s plan for locating and communicating
among transportation management centers must be understood. Perhaps the most fundamental
question in requirements definition is whether the telecommunications system will serve the needs
of a single agency, multiple transportation agencies in a region, or multiple government agencies
within a jurisdiction or region. The latter two raise issues about ownership and cost participation,
but should be considered from a good public policy perspective. The video requirement should be
carefully considered. Among the questions to be critically examined: Who needs to see what
images? How many images need to be seen at one time? What will the information be used for?
Using the video images for commercial television broadcasts may imply need for higher quality
than if they are only to be used to view incident scenes. Use of compressed digital video should
always be explored, since recent improvements in compression algorithms produce images that
approach the quality of full motion video transmissions. If the only use is to view incident scenes,
transmission of lower quality, freeze-frame/slow-scan images may be adequate, and require
much less communications capacity. For more information, reference the ITS JPO
Telecommunications Resource Guide, Tab A, Telecommunications in Transportation, a Summary
of Key Issues and Tab B, A Case for ITS Telecommunications Analysis.

The Definition of Network Options step involves defining different telecommunications network
structures or architectures. For example, the information that needs to be passed back and forth
will be very different if processing is distributed rather than centralized. Within the context of
these different network structures or architectures, ownership and leasing options should be
explored. Thinking broadly in terms of providing a telecommunications service rather than building
a telecommunications infrastructure will open the door to consideration of a number of different
options, including combinations of leased and owned infrastructure. This may also include
resource sharing opportunities, in which access to public right-of-way is exchanged for a share of
the telecommunications capacity being installed in the right-of-way. [Final Report on
Telecommunications Shared Resources: Legal and Institutional Issues, 1997].

In the final Cost Analysis step, the cost implications of the different alternatives are detailed and
compared. Ownership options involve higher installation and maintenance costs, which must be
compared against the terms of the available leasing arrangements. Short term leasing deals, on
the order of from five to ten years, may enable agencies to possibly obtain more favorable terms
in the future, and also enable agencies to take better advantage of technological advances than
they typically would be able to with a publicly owned system or longer term leasing deal.

4-18
 Developing Traffic Signal Control Systems Using the National ITS Architecture

A final but very important point is that typical transportation agency personnel seldom have the
experience needed to support informed decisions about these issues. It may be imperative that
this knowledge be acquired in the form of new staff or consulting assistance.

4-19
 Developing Traffic Signal Control Systems Using the National ITS Architecture

5. How Can I Find Out More?

Information on Intelligent Transportation Systems (ITS), the National ITS Architecture, and ITS
Standards may be found at the locations described below. Additional helpful references are listed
in the References section. You should also know that most Federal reports may also be obtained
through:

National Technical Information Service (NTIS), Technology Administration, U.S. Department of

Commerce, Springfield, VA 22161

Phone: 703-605-6000; FAX: 703-321-8547

World Wide Web at <[Link]

5.1 How Can I Find Out More About ITS?

Contact the agencies listed below:

First verbal contacts should be to your local Federal Highway Administration Division Office or
Federal Transit Administration Region Office. This should include queries relative to areas such
as program, technical and policy. This office will work with you to schedule courses, seminars
and possibly workshops on ITS topics.

ITS Joint Program Office

Federal Highway Administration, U.S. Department of Transportation, 400 Seventh Street SW,
Washington, DC 20590

Phone: 202-366-9536; FAX: 202-366-3302

World Wide Web at <[Link]

This [Link] ITS web page also provides links to numerous other sources of ITS-related
information. With the wealth of information of all types on ITS available via the Internet, it is
becoming important that the key staff involved in any ITS activity have access to Internet.

Office of Traffic Management and Intelligent Transportation Systems Applications

Federal Highway Administration, U.S. Department of Transportation, 400 Seventh Street SW,
Washington, DC 20590

World Wide Web at <[Link]

Turner Fairbanks Highway Research Center

Federal Highway Administration, U.S. Department of Transportation, 6300 Georgetown Pike,
McLean, VA 22101

World Wide Web at <[Link]

5-1
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Office of Mobility Innovation, Advanced Public Transportation Systems Division

Federal Transit Administration, U.S. Department of Transportation, 400 Seventh Street SW,
Washington, DC 20590

Phone 202-366-4991

Other sources include:

ITS America
400 Virginia Avenue SW, Suite 800, Washington, DC 20024

Phone: 202-484-4847

World Wide Web at <[Link]

5.2 How Can I Find Out More About the National ITS Architecture?
Where do I look for Information? Again, first verbal contact should be with your FHWA
Division or FTA Region Office.
Information on the National ITS Architecture is available at the following locations:

National ITS Architecture Team

The National ITS Architecture documentation and the linked HTML model are available on the
World Wide Web at

<[Link]

ITS Joint Program Office, Federal Highway Administration, [Link]

Documents that may be obtained from the Joint Program Office include:

♦ The National ITS Architecture for ITS: A Framework for Integrated Transportation into
the 21st Century

♦ Building the ITI: Putting the National ITS Architecture into Action

These documents are available on the World Wide Web at <[Link]

This site also provides a variety of very informative information, like an overview of what ITS is, a
large glossary, several other very informative reports.

Contact your FHWA Division or FTA Region Office to inquire about training:

A three day training course from the Federal Highway Administration is Using the National ITS
Architecture for Deployment Training Course; this course has been prepared by the National ITS
Architecture team and is informative about the Architecture and how to use it, with practical

5-2
 Developing Traffic Signal Control Systems Using the National ITS Architecture

interaction between students and the Architecture products on CD-ROM. Additional courses may
become available.

Exploring The National ITS Architecture On Your Own:

♦ Read the Executive Summary first. Then read the Implementation Strategy – start with
chapter 4.

♦ Use the CD-ROM in concert with a “File Find”utility. Some “File Find”utilities will search
the written material in a document for specific words. This will allow you to search the
entire National ITS Architecture for specific information.

♦ Use the Market Packages as guides to the rest of the material in the National ITS
Architecture or use them as a starting point. You can think of them as high-level ITS
system designs which can be implemented as a project or sub-project.

♦ Read sections 2.4 and 2.5 of this document for more details on how to explore the
material.

ITS America
World Wide Web at <[Link]

Hard copy versions of the National ITS Architecture documentation may also be purchased from
the ITS America Bookstore. Specific National ITS Architecture volumes are available.

Phone: (202)-484-4584 or (800)-374-8472

The National ITS Architecture is also available on CD-ROM and includes an easy to use browser
and search facility.

5.3 How Can I Find Out More About ITS Standards?

How can I find out the status of ITS standards development? Again, first verbal contact
should be with your FHWA Division or FTA Region Office.

Detailed information on ITS Standards is available at the locations listed below:

National Transportation Communications ITS Protocol (NTCIP)

Contact the NTCIP Coordinator at the National Electrical Manufacturers Organization
(NEMA)

Phone: (703) 841-3231; Fax: (703) 841-3331

World Wide Web at <[Link]

5-3
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Copies of papers regarding the NTCIP standards currently available from NEMA include:

♦ National Transportation Communications For ITS Protocol (NTCIP) Guide (Draft),

December 1, 1996.

♦ Center-to-Center Communications Requirements and Issues (White Paper), December

16, 1996

♦ NTCIP White Paper, Center-To-Center Communications, November 27, 1996

Copies of NTCIP standards may be purchased from NEMA. Those NTCIP standards currently
available include:

♦ NTCIP Overview (NEMA TS3.1) - This publication provides an overview of the concepts
and protocols for the NTCIP series of standards, which can be used to implement a
working NTCIP-based transportation control system. This standard encompasses
roadside device control, data collection, data routing, and file transfer services using
various communication system topologies.

♦ Simple Transportation Management Protocol (NEMA TS3.2) - The Simple Transportation

Management Framework (STMF) describes the framework used for managing and
communicating information between management stations and transportation devices. It
covers integrated management of transportation networks, networking devices and
transportation specific equipment attached to NTCIP-based networks.

♦ NTCIP Class B Profile (NEMA TS3.3) - This communications protocol standard can be
used for interconnecting transportation and traffic control equipment over low bandwidth
channels. This standard establishes a common method of interconnecting ITS field
equipment such as traffic controllers and dynamic message signs (DMS), defines the
protocol and procedures for establishing communications between those components,
and references common data sets to be used by all such equipment.

♦ Global Object Definitions (NEMA TS3.4) - The messaging between transportation

management and field devices is accomplished by using the NTCIP Application Layer
services to convey requests to access or modify values stored in a given device; these
parameters and their values are referred to as objects. The purpose of this standard is to
identify and provide those object definitions that may be supported by multiple device types
(e.g., actuated signal controllers and variable message signs).

♦ Actuated Controller Unit Object Definitions (NEMA TS3.5, ASC) - This standard defines
objects which are specific to actuated signal controller units.

5-4
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Object Definitions for Dynamic Message Signs (NEMA TS3.6, DMS) - This standard
contains object definitions to support the functionality of DMSs used for transportation
applications.

There are a total of sixteen of the NTCIP standards, ten more than listed above. For more
information about NTCIP standards, please refer to Appendix A.

Transit Communications Interface Profiles (TCIP)

Further information can be obtained from the following source:

World Wide Web at ..... < [Link]

ITS America
Contact ITS America for listing of all the ITS standards and status information on standards
development.

ITS America, 400 Virginia Avenue SW, Suite 800, Washington, DC 20024

Phone: 202-484-4847

World Wide Web at <[Link]

Other Standards

The American Association of State Highway and Transportation Officials (AASHTO)

Suite 249, 444 North Capitol Street, NW, Washington, DC 20001
Focus: State-level Agency Participation and Roadside Infrastructure.
World Wide Web at .....<[Link]

The American Society for Testing & Materials (ASTM)

Focus: Dedicated Short Range Communications (DSRC) systems.

World Wide Web at .....< [Link]>.

The Institute of Electrical and Electronics Engineers (IEEE)

Focus: Electronics and Communications Message Sets.

World Wide Web at ..... <[Link]

The Institute of Transportation Engineers (ITE)

525 School St., SW Suite 410, Washington, DC 20024-2797
Focus: Traffic Management and Transportation Planning systems.

Phone: (202) 554-8050

World Wide Web at <[Link]

5-5
 Developing Traffic Signal Control Systems Using the National ITS Architecture

The Society of Automotive Engineers (SAE)

Focus: In-vehicle and Traveler Information

World Wide Web at < [Link] Standards

5-6
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Acknowledgements
This work was funded by the U.S. Department of Transportation ITS Joint Program Office.
There have been contributions to this document by people from several organizations. It
is not possible to identify all of the contributors and reviewers. The authors would like to
express their sincere appreciation to those individuals who provided suggestions for
improvement.

Contributing Authors
Contributing authors include

• TransCore
• Mitretek Systems
• PB Farradyne
• Odetics
• Lockheed Martin
• David Roper

Final editing performed by Mitretek Systems.

Reviewers
• FHWA ITS Joint Program Office
• FHWA Office of Traffic Operations and ITS Applications
• FHWA Region and Division Offices
• Mitretek Systems
• ITS Architecture Team
• Peer reviews by
• David Roper
• Ed Rowe
• Richard Rossell
• Richard Beaubien
• Traffic Signal Control Focus Group Members

Plus numerous others.

AK-1
 Developing Traffic Signal Control Systems Using the National ITS Architecture

References
See Section 5 for web page URLs, phone numbers and addresses for the primary
sources for most of these documents. Also, please be aware that most Federal reports
may be obtained through:

National Technical Information Service (NTIS), Technology Administration, U.S.

Department of Commerce, Springfield, VA 22161

Phone: 703-605-6000; FAX: 703-321-8547.

World Wide Web at [Link]

Assessment of ITS Benefits — Early Results, MP 95W0000192, 1995, Roberts,

Donald L., and Dwight E. Shank. The MITRE Corporation,McLean, VA.

Building the ITI: Putting the National ITS Architecture into Action, 1997, Mitretek
Systems, prepared for the U.S. Department of Transportation, Federal Highway
Administration

Communications Handbook for Traffic Control Systems, April 1993, U.S. Department
of Transportation, Federal Highway Administration, Washington D.C.

Department of Transportation’s Intelligent Transportation Systems (ITS) Projects,

January 1997, Washington, D.C.: U.S. Department of Transportation, Intelligent
Transportation Systems Joint Program Office.

Developing Freeway and Incident Management Systems Using the National ITS
Architecture. This is an accompanying volume to this document intended for those
involved in the planning, development, deployment and operation of freeway and incident
management systems.

Developing Traveler Information Systems Using the National ITS Architecture. This
is an accompanying volume to this document intended for those involved in the planning,
development, deployment and operation of Traveler Information Systems.

FHWA Federal-Aid ITS Procurement Regulations and Contracting Options, 1997,

Booz-Allen & Hamilton, prepared for U.S. Department of Transportation, Federal Highway
Administration

Final Report on Telecommunications Shared Resources: Legal and Institutional

Issues, 1997, Apogee Research, prepared for U.S. Department of Transportation,
Federal Highway Administration

Guidelines for Funding Operations and Maintenance of ITS/ATMS,. January 1996.

Ginger Daniels and Tim Starr, Texas Transportation Institute. Presented at the 76th
Annual Meeting, Transportation Research Board, Washington D.C.

RE-1
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Innovative Contracting Practices for ITS, April 1997, L. S. Gallegos & Associates,
prepared for U.S. Department of Transportation, Federal Highway Administration

Innovative Contracting Procedures for ITS, 1996, Nossaman, Guthner, Knox & Elliott;
Ernesto V. Fuentes & Associates; L.S. Gallegos & Associates; Washington, D.C.: U.S.
Department of Transportation, Federal Highway Administration.

Integrating ITS Within the Planning Process: An Interim Handbook, 1997,

TransCore, prepared for U.S. Department of Transportation, Federal Highway
Administration

Intelligent Transportation Infrastructure Benefits: Expected and Experienced,

FHWA-JPO-96-008, 1996, MITRE Corporation, The. Washington, D.C.: U.S. Department
of Transportation, Federal Highway Administration. Available on the world wide web at
[Link] /itibeedoc/[Link]

Intelligent Transportation Systems Assessment of ITS Deployment, Review of

Metropolitan Areas: Discussion of Crosscutting Issues,. FHWA-JPO-96-0035,
1996, Blasio, Allan J., David W. Jackson, Anne C. Tallon, Anne C. McEwan, John P.
O’Donnell, Cambridge, Massachusetts: U.S. Department of Transportation, Volpe
National Transportation Systems Center.

Intermodal Surface Transportation Efficiency Act of 1991, A Summary, FHWA-PL-

92-008, 1992, U.S. Department of Transportation, Federal Highway Administration,
Washington, D.C.

ITE Operations and Maintenance Conference - Summary of Findings, 1995, Kraft,

Walter H., Institute of Transportation Engineers. Washington, D.C., PP-047.

ITS Benefits: Continuing Successes and Operational Test Results, 1997, Mitretek
Systems, prepared for the U.S. Department of Transportation, Federal Highway
Administration

ITS Deployment Guidance for Transit Systems: Technical Edition. This is an

accompanying volume to this document intended for those involved in the planning,
development, deployment and operation of transit management systems.

ITS Software Acquisition Guidance, 1998, Mitretek Systems, prepared for U.S.
Department of Transportation, Federal Highway Administration

Joint Operations In Operating and Maintaining Advanced Traffic Management

Centers, 1996, Douglas W. Wersig, White Paper prepared for the National Conference
on Operating and Maintaining Advanced Traffic Management Centers, Minneapolis, MN.

Key Findings From The Intelligent Transportation System (ITS) Program: What
Have We Learned?, FHWA-JPO-96-0036, 1996, Mitretek Systems, Washington, D.C.,
U.S. Department of Transportation, Federal Highway Administration.

RE-2
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Manual of Traffic Signal Design, 1982, Institute of Transportation Engineers, Prentice-

Hall, Inc., Englewood Cliffs, NJ

Manual on Uniform Traffic Control Devices for Streets an Highways, 1988,

U.S. Department of Transportation, Federal Highway Administration, Washington, D.C.

Overcoming Non-Technical Barriers: Lessons Learned From ITS Operational

Tests, FHWA-JPO-96-0010, 1996, DeBlasio, Allan J,. Cambridge, Massachusetts: U.S.
Department of Transportation, John A. Volpe National Transportation Systems Center.

Telecommunications Resource Guide, ITS JPO, U.S. Department of Transportation,

Federal Highway Administration

• Tab A, Telecommunications in Transportation, A Summary of Key Issues,

FHWA-JPO-97-0019, February 1997

• Tab B, A Case For Telecommunications Analysis, FHWA-JPO-97-0015, January

1997, Prepared by CSC and the Maryland Department of Transportation

The National Architecture for ITS: A Framework for Integrated Transportation into
the 21st Century, 1997, U.S. Department of Transportation, Federal Highway
Administration, Washington, D.C.

Traffic Control Systems Handbook, FHWA-SA-95-032, February 1996, Dunn

Engineering Associates, U.S. Department of Transportation, Federal Highway
Administration.

Traffic Control Systems, Standards Publication No. TS2-1992, National Electrical

Manufacturers Association, Washington, D.C., 1992.

Using the National ITS Architecture for Deployment Training Course, U.S.
Department of Transportation, Federal Highway Administration -- This 3 day course given
by the Architecture Team (Lockheed Martin and Odetics) gives the student the mechanics
for implementing regional systems using the architecture.

RE-3
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Appendix A. ITS Standards

A.1 Overview
The intent of this appendix is to identify and describe existing and planned ITS standards that are
applicable to traffic signal control systems. The need for these standards has been identified by
transportation industry.

The development, promulgation, and adoption of standards is an issue of utmost importance in

the use of a new technology. Adoption of standards can have a number of different effects. On
one hand, the adoption of a technology in the marketplace can be stimulated. On the other hand,
the further development of a technology could be frozen. Commercial broadcast television in the
United States serves as an example of both of these effects.

Early adoption of standards for commercial TV in the United States allowed for explosive
growth of industry here in the immediate post-World War II years. However, U.S.
technology was frozen at a level that subsequently proved to be inferior to that achieved
soon after in Europe. The technology of communicating data over telephone lines
provides a counter example. New standards for increasingly fast data transmission over
the phone lines periodically emerge, but the new modems that capitalize on these
standards also generally operate according to the old ones if such operation is needed.
This capability for backward compatibility increases the flexibility for all users of a
technology, thus spurring both greater adoption on the marketplace and further
technological advancement.

Standards development is critical to the success of implementing ITS. Well defined standards
help agencies better prepare procurement specifications, Requests For Information ( RFIs), and
Requests For Proposals (RFPs). These standards need to be open instead of proprietary in
order to allow for new technologies and new products from different manufacturers to be added.
Open standards are generally owned by a public organization, or the underlying technology is
licensed on a low-cost, non-discriminatory basis by its owner, and made available to anyone
wanting the documentation for an interface. Open standards encourage interoperability of
products from different manufacturers. Proprietary standards have restricted access, usually to
the company that developed the standard or their chosen licensees.

Utilizing standards to ensure ITS interoperability and the interchangeability of like equipment will
benefit the transportation industry by decreasing procurement costs (larger numbers of competing
manufacturers will spur competition), increasing system flexibility, and providing easy upgrade
paths.

Even though equipment standards are important, this section does not provide equipment-specific
standards because of the vast number of different equipment technologies. In addition, the

A-1
 Developing Traffic Signal Control Systems Using the National ITS Architecture

establishment of strict standards for device-specifications is not only location-dependent but it

would also restrict progress and innovation, and is therefore not desirable.

A.1.1 Previous work

Several organizations have been tasked, voluntarily and through contracts, to develop ITS-related
standards. Existing standards are generally based on the need of a particular industry or agency.
The U.S. DOT subsequently awarded a contract to the Jet Propulsion Laboratories (JPL) to
serve as the lead organization to:

♦ Collect ITS-related standards

♦ Create a database
♦ Organize the standards in the database
♦ Maintain and update the database content
♦ Provide interested parties with the entire content or excerpts of it
The content of this database is updated continuously and it can be visited on the ITS America
Internet home page at:

http:// [Link]/ [Link]

under the heading “Standards Catalog”.

A.2 Communication Standards

This overview of communication standards is designed to provide the reader with information on
ITS-related communications protocols. The communication standards presented allow agencies
to transmit data from one device or system to another. Some of these standards currently exist
or are very close to being completed, while others are either in an early development or planning
stage.

A.2.1 Overview
Since many interfaces have not been standardized, the U.S. DOT funded the development effort
of creating standards for ITS technologies.

Some of these new standards for ITS are described below. The listing is neither complete nor
does it indicate levels of importance.

A.2.1.1 NTCIP
The National Transportation Communications for ITS Protocol (NTCIP) was originally conceived
to be an extension of the NEMA TS-2 Controller Standard covering traffic controller
communications. The NEMA traffic control equipment manufacturers recognized that for true
hardware interchangeability, the standard had to cover the more complex issues of systems
interoperability and communications standards. As the NEMA development work grew, a general

A-2
 Developing Traffic Signal Control Systems Using the National ITS Architecture

industry forum evolved and ultimately the Federal Highway Administration (FHWA) identified the
concerns of ITS designers.

Today, the Joint NTCIP Committee, a steering committee consisting of members from three
Standard Development Organizations (SDOs), NEMA, ITE, and AASHTO, is overseeing and
directing all efforts with respect to NTCIP that are being executed within each of the above SDOs.

For ITS to be a reality, all the components that make up the traffic and transportation monitoring
and control community must be able to communicate with a common, or at least understandable,
language. The words that are spoken must have a clear and unambiguous meaning to everyone.
The NTCIP development participants started out by defining a language needed for a traffic
controller, and extended it to include Traffic Management Centers (TMCs). It has been further
refined into an open set of protocols that meet the diverse needs of ITS.

This openness is achieved by embracing features of several existing worldwide communications

standards established by the International Standards Organization (ISO), the International
Telecommunications Union, Telecommunications Sector (ITU-T; formerly CCITT), and the
Internet Engineering Task Force (IETF). These standards map onto the ISO Open Systems
Interconnect Reference Model (OSI Model) that deals with how information can be passed
through the various processing layers in an open system. The OSI Model breaks down the
aspects of communications into seven layers or discrete functions to reduce complexity. Each
layer is built upon its predecessor. These seven layers are shown in Figure A 1.

Layer 7 Application Layer

Layer 6 Presentation Layer
Layer 5 Session Layer
Layer 4 Transport Layer
Layer 3 Network Layer
Layer 2 Data Link Layer
Layer 1 Physical Layer

Figure A1: OSI Layers

These seven layers can be viewed as forming two groups of functionality to support open
communications. The first group (Layers 1-4) is responsible for data transport while the second
group (Layers 5-7) is responsible for data processing.

Protocols utilized on the different layers of the OSI models are mostly existing computer
standards that have been used for years within the industry. However, due to the nature of
transportation infrastructures, a few new protocols and modifications to existing protocols had to
be defined such as the development of the Simple Transportation Management Protocol (STMP),
a new application layer protocol, and Point-to-MultiPoint Protocol (PMPP), which follows the
existing Point-to-Point Protocol (PPP). PMPP has not yet been approved.

A-3
 Developing Traffic Signal Control Systems Using the National ITS Architecture

A.[Link] Class Profiles

Within the NTCIP there are various profile classes defined:

♦ A - Connectionless
♦ B - Central direct to field
♦ C - Connection oriented
♦ D - Dial-up
♦ E - Center to Center
♦ F - Alternate Center-to-Center
These classes are described below. The Class B Profile is the only Class Profile that has been
standardized to date. Development of this standard has been completed and it has been balloted
with the results indicating that the standard is acceptable. Manufacturers are developing
compatible products and agencies are encouraged apply the standard.

A.[Link] Class A Profile

Class A is a suite of protocols allowing the connectionless transmission of data packets over a
medium that does not require a permanent connection between two devices. For example, when
sending two letters via regular mail, it cannot be ensured that both letters will take the same route
(one letter might get from location A to location B via location C, while the other letter is sent via
location D). The Class A Profile is based on existing protocols already in use by the Internet
community and other network systems, therefore utilizing proven protocols. The only exception is
the utilization of STMP as the application layer protocol and a modified form of the HDLC protocol
that includes an initial protocol identifier (IPI) as the data link layer protocol.

The Class A Profile suite of protocols will use the Transmission Control Protocol (TCP) as its
Transport Layer protocol to guarantee delivery or signal when a message cannot be delivered
correctly. TCP uses sequence and acknowledge information and timers to make sure the
individual frames are received and that they are put in their proper order. If a frame is garbled or
lost, re-transmissions are attempted. If a frame cannot be delivered, the upper layer is notified.
This class of service ensures data integrity and correctness; its primary use is for large data
transfers.

This standard has not yet been approved but is in the process of being developed by device
manufacturers in conjunction with users of these devices. This development process ensures
that the devices utilizing this protocol will meet the requirements of the user community.

The main difference between the Class A Profile and the Class B Profile is that Class A
messages can be routed through an intermediate device, e.g., from a central location to a field
device.

A-4
 Developing Traffic Signal Control Systems Using the National ITS Architecture

A.[Link] Class B Profile

The NTCIP Class B Profile defines a set of communication protocols to be used in field devices
and their management systems that are part of an Intelligent Transportation System. The profile
provides for exchange of information between a primary station and each secondary station on a
particular communications channel or subnet. The profile sets forth standards to allow devices to
share a common interconnect, establish a common language for them to communicate and define
the structure under which the data in these devices is structured and managed. It does not
address the need for the exchange of information between devices on different subnets.

Class B provides for bandwidth efficient exchange of information between the primary station and
each secondary station on the same physical link. Class B does not ensure delivery. Frames
received with errors are discarded. If re-transmissions are needed, it is the responsibility of the
Application Layer to provide them. This class of service is primarily intended for short command
and reply messages where delivery time is a strong consideration.

The Class B Profile can be used to poll or transmit data to and from roadside devices such as
traffic signal controllers, surveillance detectors, variable message signs, or preemption devices.
It can also be used for communicating with traveler information kiosks or similar devices. A
prerequisite is the direct connection of management center and roadside device, because the
Class B Profile does not allow for routing of messages

A.[Link] Class C Profile

Class C is a profile providing connection-oriented services similar to the data transmission within
the Internet. In fact, the Class C Profile includes the same protocols on the Network (using
Internet Protocol or IP) and Transport (using TCP) Layers of the OSI model. This profile is not
yet finalized but will probably not include the untested Simple Transportation Management Protocol
(STMP), as required for the Class B and Class A Profiles. Instead, it will utilize the Simple
Network Management Protocol (SNMP), TELNET, and the File Transfer Protocol (FTP), which
are well-tested and implemented within the Internet and intranet networks.

Class C may seem to provide the ideal service; however, it imposes additional overhead. Before
any information can be passed, a connection between the devices must be established. The
connection procedure takes a certain amount of time. When the information transfer is
completed, the connection must be formally closed.

The main difference between the Class C Profile and the Class B Profile is that Class C
messages can be routed through an intermediate device, e.g., from a central location to a field
device. Another aspect is the capability to “chop”large data files into smaller data packets (file
transfer) and to sequence these packets so that they can be assembled correctly at the receiving
end.

A variety of traffic signal applications can benefit from the Class A and/or Class C Profiles.
Different types of field devices, such as traffic signal controller, video surveillance cameras, and
variable message signs, from various different manufacturers could be connected to one

A-5
 Developing Traffic Signal Control Systems Using the National ITS Architecture

common communications line and still be controlled and monitored from the traffic management
center. Currently, it is not possible to connect existing field devices that utilize different
communications protocols to the same communications channel as NTCIP.

A.[Link] Class D Profile

The Class D Profile is intended for dial-up connections. The protocol will include security features
such as dial-back. Development work on the Class D profile has not occurred yet.

A.[Link] Class E Profile

The Class E Profile specifies the suite of protocols that allows for center-to-center
communications. The specification of this Profile is at a very preliminary stage and its anticipated
development completion date is 1999. One of the first steps in developing this standard is the
definition of the Transportation Management Data Dictionary (TMDD) specifying the content of
data that needs to be transmitted between management centers.

Several different existing and emerging protocols, mostly specifying the application layer protocol
and ultimately influencing the underlying layers of the OSI model, are under consideration for this
profile but a consensus has not been reached.

The transportation industry can utilize this standard to ensure compatibility between multiple
transportation management centers or service providers. The Class E Profile should not be used
separately unless the data format of messages to be exchanged are known to both the
transmitting and receiving management centers.

A.[Link] Class F Profile

Another NTCIP compatible and NTCIP-compliant method for center-to-center communications
has been introduced. The introduction of a Class F Profile took place in December 1996 but the
information regarding this proposed standard development effort has not yet been specified in
writing.

A.[Link] Message Sets

NTCIP utilizes message sets that define how a particular function or parameter is defined and
described, and what the allowed ranges are for each parameter (or objects as they are called).
All objects have a unique name which is based on a location under a global tree. NEMA has a
node (or branch) within the global tree and assigns unique names to each known and defined
object. Because of the history, NEMA first tried to define signal controller objects, but detected
very quickly that many objects (parameters and/or functions) are not unique to signal controller
applications (e.g., time) and created another message set that contains common objects
(referred to as Global Object Definitions). As of February 1998, five of these message sets have
been completed and voted as acceptable and are available from NEMA (see section 5).
However, these have not reached a maturity level needed for final approval and publication by the
Joint NTCIP Committee and for U.S. DOT rules requiring use in Federally funded ITS projects

A-6
 Developing Traffic Signal Control Systems Using the National ITS Architecture

beyond a trial basis. However, they are not expected to undergo any significant changes from
testing and field trials. Manufacturers are developing compatible products and agencies are
encouraged apply these standards.

A.[Link] Future Developments

NTCIP is envisioned to cover many different types of communications. The flexibility of NTCIP
achieved through following the OSI Reference Model allows the expansion to various, not yet
considered communications protocols on the different layers of the OSI model. Interoperability is
provided by defined interface setups (APIs) that the layer protocols are required to follow.

A.2.1.2 TCIP
The Transit Communications Interface Profiles (TCIP) is a standards development effort that may
consist of several suites of protocols and data message sets. TCIP’s primary goal is the
definition of data interfaces to both transit-related applications and the National ITS Architecture
data flows. Transit-related application interfaces are anticipated to include the FTA National
Transit GIS standard (under development, see below) and consider the Advanced Public Transit
Systems (APTS) Map and Spatial Database User Requirement specifications (also under
development) as well as the NTCIP, DSRC, and other standardization efforts. TCIP will be
developed by addressing data flows as identified within the National ITS Architecture to the
greatest extent possible. Interfaces needed for other transit-related applications that have not
been addressed will also be identified.

The TCIP development effort is expected to augment the information management area of NTCIP
with transit-related information and message formats that facilitate the exchange of transit
information among operations centers, transit vehicles and the infrastructure. The TCIP will
provide additional NTCIP Class Profiles or subsets of existing and planned Class Profiles, and
the necessary bridges for information transfer from legacy transit systems to advanced
information systems developed conforming to the National ITS Architecture. The characteristics
of transit information exchange may be best served, for example, by one of the five NTCIP Class
Profiles, by one of the Profiles of SAE J1708, or by TCIP. However, the main focus of TCIP will
be the development of message formats to exchange transit information in a standardized
manner.

The TCIP effort is lead by the Institute of Transportation Engineers (ITE) and supported by a large
group of technical advisors consisting of members of the transit community such as FTA, APTS,
and APTA. ITE is a recognized Standard Development Organization (SDO) that was awarded a
contract by the US DOT to develop the TCIP standard. As of February 1998, the time frame
currently scheduled for the TCIP development ends in 1998.

The following have been identified as preliminary targets for the TCIP work:

1.) data flows internally and externally:

a.) internal data flows: interdepartmental within a transit property or within the
different branches (remote offices), Transit Management

A-7
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Center (TrMC) to transit vehicles, transit kiosks, and other

items such as roadside transmitters
b.) external data flows: TrMC to TMC or other centers such as service providers
and financial agents (e.g., credit card companies and
banks)

2.) static reference and dynamic data transfers:

a.) static reference data flows: for example, route and bus stop inventory, schedule, fare,
and spatial data transfers
b.) dynamic data flows: for example, pre-trip itinerary planning, safety and security
information, and detour and service delay data transfers
TCIP will ensure interoperability and compatibility to NTCIP
and SAE J1708/J1587 by creating gateway protocols, also
termed application programming interfaces (APIs).
Further information can be obtained from the following source:

[Link]

A.2.1.3 Dedicated Short Range Communications (DSRC)

Dedicated Short Range Communications (DSRC) consists of short-range communications
devices that are capable of transferring high rates of data over an air interface between mobile or
stationary vehicles and normally stationary devices that are either mounted to structures along the
roadway or are hand-held. One way of accomplishing these communications is through use of
radio frequency (RF) beacons. RF beacon technology generally consists of a transponder (tag),
transceiver (reader), and transceiver antenna (beacon). DSRC is also known as vehicle-
roadside communications (VRC).

The National ITS Architecture program recognized the need for DSRC systems for those specific
applications that require a close physical interaction between the vehicle and the roadside
infrastructure, such as in toll collection, commercial vehicle electronic clearance and roadside
safety inspection, etc. However, DSRC is considered inappropriate for applications such as
route guidance that can be more efficiently served by wide-area ITS communications. Because
of the dedicated nature and limited range of DSRC systems, the National ITS Architecture
realizes that the costs of deploying DSRC will have to be absorbed by the ITS applications they
support, including both public and private investment. The technical and applications aspects of
DSRC are covered in the Communications, Physical Architecture and Theory of Operations
documents produced by the National ITS Architecture program.

The following applications have been identified as candidates to utilize DSRC as a primary
communications technique or mechanism:

♦ Electronic Toll and Parking Payments

♦ Commercial Vehicle Operations
– International Border Clearance
– Electronic Clearance
– Safety Inspection

A-8
 Developing Traffic Signal Control Systems Using the National ITS Architecture

– Automated Equipment Identification and Freight Management

– Off-Line Verification
♦ Transit and Emergency Vehicle Operations
♦ Fleet Management
♦ Use of Vehicles as Probes to Obtain Link Travel Times
♦ In-Vehicle Signing
♦ Intersection Collision Avoidance and Automated Highway Systems
♦ Commercial Applications (e.g., drive-through purchases)
♦ Intersection Safety Warning
To encourage development of nationally, and perhaps internationally, compatible Intelligent
Transportation Systems using DSRC, the ITS Joint Program Office (JPO) in the U.S. Department
of Transportation has promoted the voluntary consensus development approach with wide private
and public participation. Leading this effort are the American Society for Testing and Materials
(ASTM) and Institute of Electrical and Electronic Engineers (IEEE).

A.3 Automated Vehicle Location (AVL) Systems

The application of AVL is a very beneficial application in terms of implementing ITS technologies.
It will enable fleet, transit and emergency services managers to manage vehicles in real-time with
reference to the roadway network.

There are many AVL systems in existence. However, all of these AVL systems are proprietary,
locking implementing agencies into a vendor-specific system. Most of these AVL systems have
not been designed to allow for integration with an overall management system. Therefore,
expansion to include upgrades, include other subsystems, or the integration of an AVL system
into an overall management system will be very expensive.

The transportation industry has expressed the need for an AVL standard to allow for
interoperability and integration of subsystems. The U.S. DOT placed AVL high on the priority list
of standards that need to be developed for ITS technologies.

The Institute of Electrical and Electronic Engineers (IEEE) has been designated as the lead
organization to develop the message set (applications standard) for AVL. However, other
standards specifying the communications protocols are also needed.

Currently existing and planned standards usable for AVL are listed in the ITS Standards Catalog
available on-line at the following World Wide Web site:

http:\\[Link]

A-9
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Appendix B. Glossary

Advanced Traffic Management Systems (ATMS) - The Advanced Traffic Management

System category of ITS functions. Includes adaptive traffic signal control, electronic road pricing,
and toll collection.

Advanced Traveler Information Systems (ATIS) - The Advanced Traveler Information System
category of ITS functions. Includes vehicle navigation, route guidance, in-vehicle signage,
intermodal travel information, trip planning, and mayday communication.

Algorithm - A procedure, process, or rule for the solution of a problem in a finite number of
steps. An algorithm may be a set of computational rules for the solution of a mathematical
problem or for evaluating a function.

Advanced Public Transportation Systems (APTS) - The Advanced Public Transportation

System category of the ITS functions. Includes vehicle location and schedule monitoring, real-
time transit, ride-share and HOV information.

Architecture Flow - A grouping of data flows (from the logical architecture) that originate at one
subsystem and end at another (in the physical architecture).

Arterial System - A linear sequence of signals on an arterial supervised to provide progressive

flow in one or both directions.

Automated Vehicle Identification (AVI) - System that has three functional elements: a vehicle-
mounted transponder (also known as a vehicle tag); roadside reader unit (also known as a tag
reader); and a processing control unit.

Automated Vehicle Location (AVL) - A computerized system that tracks the current location of
vehicles, buses, etc., enabling fleets to function more efficiently.

Bus Priority - Cycle-by-cycle timing of a traffic signal so the beginning and end times of green
may be shifted to minimize delay to approaching buses. The normal sequence of signal displays
is usually maintained.

CCTV - Closed Circuit Television

Centralized System - A computerized traffic signal control system in which the master computer,
central communication facility, console, keyboard, and display equipment are all situated at a
single location. From this center, the operating staff coordinate and control traffic signals and
related traffic functions in the area.

B-1
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Closed-Loop Signal System - A system that provides two-way communication between the
intersection signal controller and its master controller. The master controller communicates to the
traffic operations center.

Command - A signal (typically from the central computer or master controller) that initiates a
control function.

Communication System - The composite of communication links and associated

communications equipment which interconnect all the control and surveillance components of a
traffic control system.

Communications Addressing - The process of selecting a specific receiving unit on a

multidrop line or network so that the message can be sent to the unit alone.

Communications Control Unit (CCU) - The portion of a system that handles the
communication processes. The CCU may be a software program or a separate hardware unit. It
handles message transmission, errors, control functions, and other communication-related tasks.

Congestion - A freeway condition where traffic demand exceeds roadway capacity. Normally
occurs during peak travel periods or when a traffic incident reduces capacity by creating a
bottleneck.

Council of ITS Standards - The council established by ITS America (Standards and Protocol
Committee) to coordinate the standards-setting efforts in USA and international. Includes
representatives from ANSI, IEEE, SAE, ASTM, EIA, NAB, NEMA, TIA, ITE, and AASHTO.

Cycle - In a pretimed controller unit, a complete sequence of signal indications. In an actuated

controller unit, a complete cycle is dependent on the presence of calls on all phases.

Cycle Length - The time required for one complete sequence of signal phases.

Delay - The retardation of traffic flow through a segment of roadway or intersection for a definite
period of time.

Demand - The need for service, e.g., the number of vehicles desiring use of a given segment of
roadway or intersection during a specified unit of time.

Detector - A device for indicating the presence or passage of vehicle or pedestrians. The
general term is usually supplemented with a modifier; loop detector, magnetic detectors, etc.
indicating type.

Distributed System - A control system in which individual computers are installed at each of the
major control areas of a total system, and a supervising master is used to provide interface
between the individual areas and to make decisions on timing patterns affecting two or more
areas.

Diversion - An aspect of corridor control which refers to the directing of traffic from a corridor
with excess demand to those with excess capacity.

B-2
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Diversion Strategy - a strategy for diverting traffic that optimizes corridor operations in
response to corridor incidents.

Emergency Management - The bundle of ITS user services that includes; emergency
notification and personal security; and emergency vehicle management.

Emergency Vehicle Preemption - The transfer of the normal control of signals to a special
signal control mode for emergency vehicles.

Equipment Package - A set of like functions (see process specifications) of a subsystem

grouped together in the National ITS Architecture that represents an “implementable”package of
hardware and software capabilities.

Equipment Status Monitoring - The ability to determine the operational characteristics of a

remote device in terms of: operating normally, malfunctions, communications errors, etc.

Field Equipment - That equipment or hardware which is located on the street, such as an
intersection controller assembly, signal heads, and detectors.

Hardware - The physical equipment in a computer system. (see Software).

Highway Advisory Radio (HAR) - Also know as Traveler’s Information Stations (TIS), or
Traveler’s Advisory Radio (TAR). These systems provide travel or roadway information to
motorists via their AM radio sets. The FCC regulates the use of HAR.

Incident - An occurrence in the traffic stream which causes a reduction in capacity or abnormal
increase in demand. Common incidents include accidents, stalled vehicles, spilled loads, and
special events.

Intelligent Transportation Systems (ITS) - The collection of transportation services and

infrastructure that will implement the goals of ISTEA. ITS uses advanced technologies to provide
the range of traffic-based user services.

Intermodal Surface Transportation Efficiency Act of 1991 (ISTEA-91) - A Congressional act

whose purpose is to develop a National Intermodal Transportation System that is economical
efficient and environmentally sound, provide the foundation to compete in the global economy and
move people and goods in an energy efficient manner. Provides governmental basis for research
and deployment of ITS technologies.

International Organization for Standardization (ISO) - An international standards

organization. ANSI is the U.S. representative to ISO.

Intersection - The common area of roadways that meet or cross.

Layer - A breakdown or stratification of the physical architecture; comprised of the transportation

layer and the communications layer.

B-3
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Local Controller: Pretimed - A device that controls all timing intervals to a fixed pre-determined
plan. Works best where traffic is predictable and constant.

Local Controller: Full-Actuated - A device that controls the length of all timing intervals based
on detected traffic demand on the associated approach. Adjusts cycle and split to fit changing
demand.

Local Controller: Semi-Actuated - A device that controls some approaches on the basis of
detected traffic demand. Non-actuated phases receive minimum green interval that extends until
interrupted by actuation on other phases.

Logical Architecture - The identification of system functional processes and information flows
grouped to form particular transportation management functions. These processes are broken
down into subprocesses and further into process specifications or p-specs.

Mainline: Freeway - The freeway proper as distinguished from the entrance ramps, exit ramps,
and interchange geometry of the freeway.

Market Package - Within the National ITS Architecture, a set of equipment packages required to
work together to deliver a given service and the major architecture flows between them and other
important external systems.

Measures of Effectiveness (MOE) - The quantitative variables derived from traffic

measurements that measure the improvement in traffic operations ranging from one signalized
intersection to a complete system. Common MOEs are total travel time, total travel, number and
recent of stops, delay, average speed, accident rate, and throughput.

Metering - Traffic control method or technique for regulating traffic flow.

Metering Rate - Number of vehicles allowed to enter a given section of roadway per unit time.

National Transportation Communications for ITS Protocol (NTCIP) - A family of protocols

being developed for the transportation community.

NEMA - National Electrical Manufacturers Association, a standards development body.

Occupancy - Percent of time that a point on a roadway is occupied by a vehicle.

Open Systems Interconnect Reference Model (OSI Model) - A communications model

established by the International Standards Organization (ISO) that breaks down the aspects of
communications into seven layers or discrete functions to reduce complexity and provide support
for open communications. The layers range from the physical layer to the application layer.

Phase - The portion of a traffic cycle allocated to any single combination of one or more traffic
movements simultaneously receiving the right-of-way during one or more intervals.

Phase Sequence - A predetermined order in which the phases of a cycle occur.

Physical Architecture - The physical (versus functional) view or representation of a system.

B-4
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Preemption/Priority Systems - Preemption control of normal signal timing plans applies in the
following situations: priority for selected transit vehicles; preemption for emergency vehicles; and
preemption for approaching trains at signals adjacent to railroad grade crossings.

Process Specifications - The lowest level of functional hierarchy, process specifications (also
know as p-specs) are elemental functions that must be performed to satisfy user service
requirements.

Project Management - A management process that transforms a design into an installed

system. Uses management tools such as: contract administration; project scheduling;
construction management; work breakdown structure; defined and budgeted work packages;
project design reviews and audits; and costs/progress status reports. This process carries
forward the implementation of the system design. Tasks include: procurement of subsystems,
software, and equipment, contractor performance monitoring, documentation; design reviews,
development, integration, development testing, acceptance testing; training, hands-on training,
and turnover to user, followed by a warranty period covering design, construction, installation and
operational

Queue Length - (1) Number of vehicles stopped in a lane behind the stopline at a traffic signal.
(2) Number of vehicles that are stopped or moving in a line where the movement of each vehicle
is constrained by that of the lead vehicle.

Ramp Metering - The most widely used form of freeway traffic control. It regulates the number
of vehicles entering the freeway over a given time interval so that demand does not exceed
capacity.

Signal Priority Systems - Priority control at signalized intersections are typically used for
reduction of transit delay. Conditional signal priority for transit vehicles can be implemented
through: phase/green extension; phase early start or red truncation; red interrupt or special
phase; phase suppression or skipping; and window stretching.

Software - Various computer programs to facilitate the efficient operation of the system.
Software items include: assemblers; compilers, generators; subroutines; libraries; operating
systems; and application programs.

Split - The percentage of a cycle length allocated to each of the various phases in a single cycle.

Subsystem - A physical entity within the transportation layer of the National ITS Architecture.

Supervisory Local Controller - A control device ranging from a time-base coordination unit to a
remote master controller that determines or alters interval duration and/or maintains timing
relationships in a group of local controllers.

Threshold - A present level or value of a parameter which indicates that a change of activity will
occur if the current value is above or below this level.

Time-of-Day Operation (TOD) - Signal timing plans selected according to time-of-day

B-5
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Timing Plan - A set of cycle lengths, splits, and offsets within a section of signals. The particular
timing for each intersection may vary with time-of-day within the plan.

Traffic Signal Coordination - the establishment of a definite timing relationship between

adjacent traffic signals.

Transit Communications Interface Profiles (TCIP) - A subset of NTCIP protocols which are
specific to the transit community.

Urban Traffic Control System (UTCS) - A widely deployed real-time traffic responsive system
control system originally developed by the Federal Highway Administration (FHWA) and
prototyped in Washington, D.C.

User Service - A categorization of ITS that represents what the system will do from a user’s
perspective. User services formed the basis for the National ITS Architecture development.

User Service Bundles - A collection of ITS user services that have common characteristics and
can be deployed in a coordinated manner.

User Service Requirement - The decomposition of each user service into fundamental needs.

Variable Message Sign (VMS) - Signs that electronically or mechanically vary the visual word,
number or symbolic display as traffic conditions warrant. Also referred to as changeable message
signs or as dynamic message signs.

Wide Area Network - Any one of a number of technologies that provides geographically distant
transfer.

B-6
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Appendix C. Physical Architecture Data Flows

Associated With Traffic Signal Control
The physical architecture allocates the functionality defined in the logical architecture into
subsystems based on the functional similarity of the process specifications and the typical
locations of functions in transportation systems. By defining four subsystem classes (Traveler,
Roadway, Center and Vehicle) and 19 subsystems, the National ITS Architecture provides a
framework for development of a regional physical architecture. Once the subsystems of the
physical architecture have been defined, and the interfaces required between them identified, a
detailed system design can be developed.

Figure C-1 provides an illustration of the physical data flows into and out of the Traffic
Management Subsystem.

Event Map Update

Promoters Provider
Construction & Other Traffic
Maintenance Management

Traffic Operations
DMV
Personnel

Roadway
Subsystem Enforcement
Agency
Traffic
Management
Weather
Service Emergency
Management

Transit
Management Rail
Operations

Parking
Management Planning
Subsystem
Information
Service Toll Emissions
Provider Administration Management

Figure C-1. Physical Data Flows for Traffic Management

The balance of Appendix C lists important physical data flows that may be associated with traffic
signal control.1 The format of each is as follows:

1
This appendix was derived from the January 1997 version of the National ITS Architecture.
Since this information is subject to change as updates are implemented, the reader should
always consult and defer to the latest version of the National ITS Architecture (see section 5 of

C-1
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Heading (bold) - Source subsystem to destination subsystem

♦ Physical Architecture flow name - italics

♦ Brief description of the data flow - line following Physical Architecture flow name

♦ Logical Architecture Reference Flow (bullets) - Logical data flows which comprise the
Physical Architecture data flow

This list does not constitute the entire list of data flows that may be relevant to traffic signal control
systems. For example, data flows exchanged with most external system interfaces (or
terminators) are not included. Guidance for locating complete data flow lists for each market
package is provided in section 2.

Construction and Maintenance -> Traffic Management

Physical Architecture Flow Name: work zone status

status of maintenance zone

♦ Logical Architecture Reference Flow: fcm_incident_information
♦ Logical Architecture Reference Flow: fcm_fault_clearance

DMV -> Traffic Management

Physical Architecture Flow Name: registration

registered owner of vehicle and owner information

♦ Logical Architecture Reference Flow: fdmv_traffic_violation_vehicle_registration
♦ Logical Architecture Reference Flow: fdmv_traffic_violation_state_identity

Emergency Management -> Traffic Management

Physical Architecture Flow Name: emergency vehicle greenwave request

request for greenwave for emergency vehicle

♦ Logical Architecture Reference Flow: emergency_vehicle_green_wave

Physical Architecture Flow Name: incident information

notification of existence of incident and expected severity, location, and nature of incident.
♦ Logical Architecture Reference Flow: incident_details

Physical Architecture Flow Name: incident response status

status of currently occurring incident

this document).

C-2
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Logical Architecture Reference Flow: incident_response_status

C-3
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Emergency Vehicle Subsystem -> Roadway Subsystem

Physical Architecture Flow Name: emergency vehicle preemption request

request to TMS for signal preemption either through roadside or directly to TMS
♦ Logical Architecture Reference Flow: emergency_vehicle_preemptions

Emissions Management -> Traffic Management

Physical Architecture Flow Name: wide area statistical pollution information

emissions from vehicles as measured at the roadside

♦ Logical Architecture Reference Flow: pollution_state_data
♦ Logical Architecture Reference Flow: pollution_incident
♦ Logical Architecture Reference Flow: wide_area_pollution_data

Event Promoters -> Traffic Management

Physical Architecture Flow Name: event plans

plans for major events impacting traffic

♦ Logical Architecture Reference Flow: fep_event_information

Information Service Provider -> Traffic Management

Physical Architecture Flow Name: incident notification

notification by a motorist of an incident on the roadway through the emergency network

♦ Logical Architecture Reference Flow: media_incident_data_updates
♦ Logical Architecture Reference Flow: confirm_incident_data_output

Physical Architecture Flow Name: logged route plan

route plan that may be used for demand management or optimal routing
♦ Logical Architecture Reference Flow: logged_hazmat_route
♦ Logical Architecture Reference Flow: low_traffic_route

Physical Architecture Flow Name: request for traffic information

request issued to agency which collects traffic data for traffic conditions
♦ Logical Architecture Reference Flow: request_incident_media_data
♦ Logical Architecture Reference Flow: traffic_data_media_request

C-4
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Physical Architecture Flow Name: road network use

aggregated OD data from clients for planning purposes

♦ Logical Architecture Reference Flow: parking_lot_charge_details
♦ Logical Architecture Reference Flow: current_other_routes_use
♦ Logical Architecture Reference Flow: current_transit_routes_use
♦ Logical Architecture Reference Flow: current_road_network_use

Map Update Provider -> Traffic Management

Physical Architecture Flow Name: map updates

either static or real-time map updates

♦ Logical Architecture Reference Flow: fmup_traffic_display_update
♦ Logical Architecture Reference Flow: fmup_demand_display_update
♦ Logical Architecture Reference Flow: fmup_incident_display_update

Other TM -> Traffic Management

Physical Architecture Flow Name: TMC coordination

traffic information exchanged between TMCs. Normally could include congestion data, traffic
data, signal timing plans, real-time signal control information.
♦ Logical Architecture Reference Flow: fotc_data_request
♦ Logical Architecture Reference Flow: fotc_identity
♦ Logical Architecture Reference Flow: fotc_transfer_data
♦ Logical Architecture Reference Flow: parking_lot_charge_change_response

Parking Management -> Traffic Management

Physical Architecture Flow Name: demand management price change response

response to change request indicating level of compliance with request

Physical Architecture Flow Name: parking availability

parking lot occupancy and availability

♦ Logical Architecture Reference Flow: parking_lot_current_state
♦ Logical Architecture Reference Flow: parking_guidance_for_vms

C-5
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Planning Subsystem -> Traffic Management

Physical Architecture Flow Name: planning data

data to Transportation Planners

♦ Logical Architecture Reference Flow: link_data
♦ Logical Architecture Reference Flow: supply_incident_static_data
♦ Logical Architecture Reference Flow: static_data_request
♦ Logical Architecture Reference Flow: supply_traffic_static_data
♦ Logical Architecture Reference Flow: traffic_data_deployment_request

Rail Operations -> Traffic Management

Physical Architecture Flow Name: railroad advisories

real-time notification of railway incidents

♦ Logical Architecture Reference Flow: fro_incident_notification

Physical Architecture Flow Name: railroad schedules

train schedules, maintenance schedules, and other information from the railroad that supports
forecast of HRI closures.
♦ Logical Architecture Reference Flow: fro_maintenance_schedules
♦ Logical Architecture Reference Flow: fro_train_schedules

Roadway Subsystem -> Traffic Management

Physical Architecture Flow Name: fault reports

reports from signals and displays on the roadside which are not functioning properly

Physical Architecture Flow Name: HOV data

HOV data from roadside indicating information regarding vehicle occupancy in HOV lanes
♦ Logical Architecture Reference Flow: roadside_fault_data
♦ Logical Architecture Reference Flow: hov_lane_data_input

Physical Architecture Flow Name: hri status

status of the highway-rail intersection equipment including both the current state or mode of
operation and the current equipment condition
♦ Logical Architecture Reference Flow: hri_guidance_for_beacon_message
♦ Logical Architecture Reference Flow: hri_guidance_for_vms

C-6
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Logical Architecture Reference Flow: hri_status

♦ Logical Architecture Reference Flow: hri_traffic_data
♦ Logical Architecture Reference Flow: rail_operations_message
♦ Logical Architecture Reference Flow: traffic_management_request

Physical Architecture Flow Name: incident data

incident imagery and other data from roadside

♦ Logical Architecture Reference Flow: incident_analysis_data
♦ Logical Architecture Reference Flow: vehicle_pollution_alert
♦ Logical Architecture Reference Flow: vehicle_pollution_message_for_highways
♦ Logical Architecture Reference Flow: vehicle_pollution_message_for_roads

Physical Architecture Flow Name: intersection blockage notification

notification that a highway-rail intersection is obstructed and supporting information

♦ Logical Architecture Reference Flow: hri_blockage
♦ Logical Architecture Reference Flow: intersection_blocked

Physical Architecture Flow Name: local traffic flow

traffic flow over local streets

♦ Logical Architecture Reference Flow: traffic_image_data
♦ Logical Architecture Reference Flow: traffic_sensor_data

Physical Architecture Flow Name: signal control status

status of surface street signal controls

♦ Logical Architecture Reference Flow: indicator_input_data_from_roads

Physical Architecture Flow Name: signal priority request

request for priority at signal either generated by emergency vehicle or transit vehicle. May be
dealt with at roadside or forwarded to TMC
♦ Logical Architecture Reference Flow: indicator_input_data_from_roads

Toll Administration -> Traffic Management

Physical Architecture Flow Name: demand management price change response

response to change request indicating level of compliance with request

♦ Logical Architecture Reference Flow: toll_price_changes_response

C-7
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Physical Architecture Flow Name: probe data

aggregate data from probe vehicles including location, speed for a given link or collection of links.
♦ Logical Architecture Reference Flow: probe_data_for_traffic

Traffic Management -> Emergency Management

Physical Architecture Flow Name: incident information request

request for incident information, clearing time, severity

♦ Logical Architecture Reference Flow: incident_details_request

Physical Architecture Flow Name: incident notification

notification of an incident on the roadway through emergency network

♦ Logical Architecture Reference Flow: incident_alert
♦ Logical Architecture Reference Flow: incident_response_clear

Traffic Management -> Information Service Provider

Physical Architecture Flow Name: traffic information

congestion, pricing, and incident information

♦ Logical Architecture Reference Flow: current_highway_network_state
♦ Logical Architecture Reference Flow: current_road_network_state
♦ Logical Architecture Reference Flow: incident_data_output
♦ Logical Architecture Reference Flow: link_data_for_guidance
♦ Logical Architecture Reference Flow: parking_lot_charge_request
♦ Logical Architecture Reference Flow: predicted_incidents
♦ Logical Architecture Reference Flow: prediction_data
♦ Logical Architecture Reference Flow: retrieved_incident_media_data
♦ Logical Architecture Reference Flow: traffic_data_for_media
♦ Logical Architecture Reference Flow: traffic_data_media_parameters
♦ Logical Architecture Reference Flow: transit_fare_request

C-8
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Traffic Management -> Other TM

Physical Architecture Flow Name: TMC coordination

traffic information exchanged between TMCs. Normally could include congestion data, traffic
data, signal timing plans, real-time signal control information
♦ Logical Architecture Reference Flow: totc_data_request
♦ Logical Architecture Reference Flow: totc_identity
♦ Logical Architecture Reference Flow: totc_transfer_data

Traffic Management -> Rail Operations

Physical Architecture Flow Name: hri advisories

notification of Highway-Rail Intersection equipment failure, intersection blockage, or other

condition requiring attention, and maintenance activies at or near highway rail intersections
♦ Logical Architecture Reference Flow: tro_event_schedules
♦ Logical Architecture Reference Flow: tro_equipment_status
♦ Logical Architecture Reference Flow: tro_incident_notification

Traffic Management -> Roadway Subsystem

Physical Architecture Flow Name: hri control data

HRI information transmitted at railroad grade crossings and within railroad operations
♦ Logical Architecture Reference Flow: rail_operations_advisories
♦ Logical Architecture Reference Flow: indicator_sign_control_data_for_hri
♦ Logical Architecture Reference Flow: rail_operations_device_command

Physical Architecture Flow Name: hri request

a request for HRI status or a specific control request intended to modify HRI operation
♦ Logical Architecture Reference Flow: hri_traffic_surveillance
♦ Logical Architecture Reference Flow: ro_requests
♦ Logical Architecture Reference Flow: tms_requests

Physical Architecture Flow Name: signage data

information sent to vehicles about traffic

♦ Logical Architecture Reference Flow: vehicle_sign_data

C-9
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Physical Architecture Flow Name: signal control data

Control information to surface street signals

♦ Logical Architecture Reference Flow: indicator_control_data_for_roads
♦ Logical Architecture Reference Flow:
indicator_control_monitoring_data_for_road
s

Physical Architecture Flow Name: surveillance control

control signals for surveillance devices

♦ Logical Architecture Reference Flow: incident_video_image_control
♦ Logical Architecture Reference Flow: traffic_video_camera_control

Traffic Management -> Operations Personnel

Physical Architecture Flow Name: traffic operations data

data detailing performance of the road network including current and historical data
♦ Logical Architecture Reference Flow: ttop_video_image_output
♦ Logical Architecture Reference Flow: ttop_traffic_control_information_display
♦ Logical Architecture Reference Flow: ttop_current_indicator_faults
♦ Logical Architecture Reference Flow: ttop_undefined_response_details
♦ Logical Architecture Reference Flow: ttop_possible_incidents_data
♦ Logical Architecture Reference Flow: ttop_incident_information_display
♦ Logical Architecture Reference Flow: ttop_defined_incident_responses_data
♦ Logical Architecture Reference Flow: ttop_possible_defined_response_output
♦ Logical Architecture Reference Flow: ttop_incident_video_image_output

Traffic Management -> Transit Management

Physical Architecture Flow Name: demand management price change request

request to change the pricing for road facility use based on demand
♦ Logical Architecture Reference Flow: transit_services_demand_request
♦ Logical Architecture Reference Flow: transit_conditions_demand_request
♦ Logical Architecture Reference Flow: transit_services_changes_request

C-10
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Physical Architecture Flow Name: signal priority status

status of signal priority request functions at the roadside (e.g. enabled or disabled)
♦ Logical Architecture Reference Flow: transit_highway_priority_given

Physical Architecture Flow Name: traffic information

congestion, pricing, and incident information

♦ Logical Architecture Reference Flow: prediction_data

Traffic Operations Personnel -> Traffic Management

Physical Architecture Flow Name: traffic control

instructions to the TMC from an operator to adjust signal timing plans, change CMS or roadway
signing, demand factors etc.
♦ Logical Architecture Reference Flow:
ftop_defined_incident_response_data_updat
e
♦ Logical Architecture Reference Flow: ftop_incident_camera_action_request
♦ Logical Architecture Reference Flow: ftop_incident_data_amendment
♦ Logical Architecture Reference Flow:
ftop_defined_incident_response_data_requ
est
♦ Logical Architecture Reference Flow: ftop_update_defined_incident_responses
♦ Logical Architecture Reference Flow: ftop_traffic_information_requests
♦ Logical Architecture Reference Flow: ftop_incident_information_requests
♦ Logical Architecture Reference Flow: ftop_video_camera_action_request
♦ Logical Architecture Reference Flow: ftop_traffic_data_parameter_updates

Transit Management -> Traffic Management

Physical Architecture Flow Name: request for transit signal priority

request for signal priority either through roadside or directly to TMS

♦ Logical Architecture Reference Flow: transit_highway_overall_priority

Transit Vehicle Subsystem -> Roadway Subsystem

Physical Architecture Flow Name: local signal priority request

request between vehicle and roadside

C-11
 Developing Traffic Signal Control Systems Using the National ITS Architecture

♦ Logical Architecture Reference Flow: transit_vehicle_roadway_priority_request

C-12
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Weather Service -> Traffic Management

Physical Architecture Flow Name: weather information

predicted and accumulated weather data

♦ Logical Architecture Reference Flow: from_weather_service
♦ Logical Architecture Reference Flow: fws_current_weather
♦ Logical Architecture Reference Flow: fws_predicted_weather

Useful National ITS Architecture Document: Physical Architecture

C-13
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Appendix D. National ITS Architecture Products

Provided below is a brief overview of all documents that are part of the National ITS Architecture.

Vision Statement Written in “magazine style”, the Vision Statement sketches a number of
possible scenarios of ITS development over the next 20 years. It describes how travelers and
system operators may be able to use and benefit from ITS technologies in their day-to-day
activities. While the Vision Statement is not a technical document, it does describe the potential
impact of ITS technologies on the management of the nation’s transportation system.

Mission Definition The first of the technical documents, the Mission Definition covers a broad
range of ITS-related issues. It contains the overall mission of ITS deployment, as well as the
operational concept, which deals with specific ITS goals and objectives; ITS user groups and
other stakeholders; ITS user services; and potential sources for funding, operations and
maintenance. The document also defines operational requirements at the system level, user
requirements, performance requirements, and program requirements.

These concepts are important aspects of the National Architecture throughout the deployment
process, since they provide the overall direction for the ITS program. Constant evaluation of a
region’s ITS deployment against the national goals and objectives will ensure that regional ITS
deployment is compatible with the philosophy of the National Architecture. The Mission Definition
document is important for those that are involved with the initial concepts definition of an ITS
system for a particular region.

Logical Architecture The Logical Architecture document contains three volumes: Description
(Volume 1), Process Specifications (Volume 2), and Data Dictionary (Volume 3). These
documents present a functional view of the ITS user services, contain diagrams that show
processes and data flows among them, and define data elements, respectively.

Physical Architecture The Physical Architecture document describes the transportation and
communications layers resulting from the partitioning of the processes within the logical
architecture, presents architecture flow diagrams that show data passing among physical
subsystems, and provides characteristics and constraints on the data flows.

Theory Of Operations This document provides a detailed narrative of the manner in which the
architecture supports the ITS user services, described in the Mission Definition. It is a technical
document, intended for engineers, operators, and others involved detailed systems design.

Traceability Document The Traceability Document is a technical document that is used in

conjunction with and throughout the development of the Logical and Physical Architectures. It lists
all the User Service Requirements (USR), which constitute the highest-level functional
specifications for ITS, as provided by the U.S. Department of Transportation. In several tables,
these USRs are mapped to the various logical and physical components of an ITS system. The
document should be used primarily by those involved in detailed design.

D-1
 Developing Traffic Signal Control Systems Using the National ITS Architecture

Implementation Strategy The Implementation Strategy document ties the elements the National
Architecture together, and is intended to assist ITS implementors at all levels with cost-effective,
efficient ITS deployment.

Standards Development Plan This document discusses the issues that are involved in the
development of system interface standards. It is primarily intended for Standards Development
Organizations and system designers, and will be important at the integration step in the Systems
Engineering Process.

Standards Requirements This is a set of 12 Standards Requirements Packages that presents

detailed data flow and interface information pertaining to the priority standards packages that
need to be developed to implement the architecture. It, too, is primarily intended for Standards
Development Organizations and system designers, and will be important at the integration step in
the Systems Engineering Process.

Evaluatory Design The Evaluatory Design document is intended to evaluate the National
Architecture’s performance, benefits, and costs for three conceptual scenarios at various points
in time. The scenarios consist of “typical”deployment environments: urban, inter-urban, and rural.
The entire document will assist you in developing an evaluation methodology for the architecture
that you have developed for your particular region.

Communications Document This document provides a thorough analysis of the

communications requirements of the National Architecture, and ITS in general, and includes a
discussion of options for implementing various communications links. With the latest version of
the National Architecture, an addendum to this document was published, detailing requirements
for the Highway-Rail Intersections User Service. It is an important document for those involved in
detailed design and integration during the Systems Engineering Process.

Risk Analysis This document presents an analysis of potential critical risks that may delay or
prevent the deployment of ITS technologies, and recommends mitigation plans which will eliminate
of reduce these risks to the deployment process. It is intended for implementors that are involved
with the details of ITS deployment in their region, throughout the development of the Regional
Architecture.

Cost Analysis The Cost Analysis document has two purposes. First, it develops a high-level
cost estimate of the expenditures that are associated with implementing ITS components.
Second, it is a costing tool for implementers, by providing unit prices and systems costs of ITS
subsystems. There is significant correlation between the Cost Analysis and the Evaluatory
Design documents; the Cost Analysis is based largely on the assumptions made for the three
deployment scenarios (urban, inter-urban, and rural). The latest version of the National
Architecture documents contains an addendum to the Cost Analysis, accounting for the Highway-
Rail Intersection User Service. This is an important document for those involved in planning and
design, and could be useful to those responsible for project management in the Systems
Engineering Process, including funding and procurement.

Performance and Benefits Study This document assesses the technical performance of the
National Architecture on a number of system-level and operational-level criteria. It could be

D-2
 Developing Traffic Signal Control Systems Using the National ITS Architecture

helpful in supporting the case for ITS deployment, as it provides a measure of the degree to which
ITS can help achieve some regional transportation goals.

Evaluation Results This document contains a concise summary of the various evaluations that
were performed in five other National Architecture documents: Evaluatory Design,
Communications Analysis, Cost Analysis, Performance and Benefits, and Risk Analysis.

Executive Summary Provides an overview of the most important aspects of the National
Architecture, most notably the Logical and Physical Architectures.

D-3