You are on page 1of 63

ITS Architectures

Levels of ITS Architecture


• There is an analogy between ITS architecture and house architecture.
The architecture of a house may have to be expressed in various forms to
suit the audience.
• For the homeowner, the architect shows them artist sketches and floor
plans. For the construction workers, the architect shows them drawings of
beams and columns and gives precise dimensions.
• Similarly, the system architecture of a particular ITS may be expressed in
various forms that are mutually consistent. The selection of a particular
form depends on the needs and the audience at hand. The idea of
multiple architectural forms is consistent with the multiple viewpoints in
the IEEE standard 1471-2000, “Recommended Practice for Architectural
Description of Software-Intensive Systems.”
Levels of ITS Architecture
Levels of ITS Architecture

• ITS architecture is primarily about information exchange and control between


systems at various levels of abstraction, as depicted in the multi-level model in
Figure.
• The CONVERGE project * defined these levels as a way of explaining the
uses that should be made of the various models and viewpoints that may
comprise an architecture.
• Traffic and transport managers lay down high-level properties, or policy, at
Levels 3 and 2, and the architectural structure at Level 1 is then devised so
that it conforms to these properties. Level 0 is not strictly part of the
architecture though it is often referred to as such, and represents the stage at
which a supplier designs a system, or component, that conforms to the
architecture.

* URL: http://www.cvisproject.org/en/links/converge.htm
Levels of ITS Architecture
• Level 3 architecture needs to reflect the real-world constraints that operate
on transport agencies, and to reflect the requirements for such system
properties as interoperability between the participating agencies and the
retention of information control by the respective agencies. It may show
where existing organizational structures must be modified and changed –
perhaps quite radically – in order to deliver ITS services
• As an example, a traffic control centre (TCC) may need to exchange data
with another TCC or a traveller information centre (TIC), possibly across
national or language boundaries. Defining the nature and minimum
performance specification for this transaction matters is important
• In some cases a simple telephone line that carries voice messages would
suffice. Other cases may require a high-speed secure dedicated data link
for closed circuit TV pictures. The required level of interconnection and
interoperability has to be specified adequately for architecture analysis
purposes although the choice of specific technologies should be left to
system designers.
Levels of ITS Architecture
• Level 2 architecture defines the properties of those systems that operate
under the control of a single agency, and it can take into account the
characteristics of both existing systems and future planned systems.
• The issues dealt with at Levels 2 and 3 are similar. The CONVERGE
approach separates them because they are dealt with at different times, and
may be dealt with by different groups.
• Level 1 architecture is primarily the concern of the systems engineers. At this
level, the system structure will be defined so that ITS functions can be
grouped together for cost-effective implementation and information systems
can be logically decomposed into subsystems for design at Level 0.
• Specific technologies will be chosen only at Level 0. Therefore system
architectures at Levels 1 through 3 are technology independent, and are
stable in terms of ITS services and functions, notwithstanding technological
changes.
Steps for developing ITS Architecture

– User Needs,
– Functional Requirements,
– and Concept of Operations
User Needs

• The first step in the establishment of an ITS architecture is the selection and
prioritisation of user services. All the key stakeholders and actors should be
involved in this process, making architecture development an opportunity for
consensus building that is very important for successful ITS deployment and
operations.

• The consensus view lead to the determination of functional requirements and


a concept of operations that describes who provides and who receives which
ITS service(s), and what interactions the providers must have in order to
support the service delivery.
User Needs (Contd..)

• Within any single country or region, there are likely to be large differences
between the set of ITS services useful for big cities and that for rural areas.

• There are key actors and obvious stakeholder groups organised around
domains (such as motorway networks, traffic control for medium sized cities,
and rural areas), and around areas of competence and responsibilities (such
as road safety, public transport, fleet logistics, etc.).

• Each interest group has its own policy goals, in addition to the more general
objectives of improving safety, efficiency, environmental quality, etc.

• Following the principles shown in Figure on next slide, each interest group will
start out with its own narrow policy goals and think about what ITS services
would support its goals.
Steps for developing ITS Architecture
Functional Requirements
• the functional requirements for providing these services must be determined.
At this point, commonalities between domains may be identified.
• For example, the highway network operators may be planning to deploy ITS for
electronic tolling and automatic incident detection. This functionality can be
adapted to give high-quality traffic and traveller information, with point-to-point
journey times. Thus an alliance between the network operators and the
information service providers is needed on the planned joint use of ITS
infrastructure, the protocols for information exchange, and an integrated ITS
architecture, which can serve the needs of both groups.
Functional Requirements
• In another example, the motorway network operators might think about using
ramp metering to maintain smooth traffic flow in the network. A side effect can
be long queues of vehicles on the surrounding roads. Therefore, there would
be calls for measures to ensure that the surrounding road network does not
become gridlocked, and for pressure to assist transit and high-occupancy
vehicles waiting to get onto the ramp. After some discussion on mutual
accommodation, the main interest groups might agree on demand
management, with upgrading of transit services through ITS technologies to
encourage a modal shift. Thus, while one interest group might begin thinking
about services within its own domain only, it would probably end up
collaborating with other interest groups in the final design.
• This example shows how, through negotiation and consensus building, a
set of ITS services and corresponding functional requirements are jointly
developed through the group process. To the extent that the executives and
representatives of stakeholder groups are driven by their policy goals in their
selection of ITS user services, the resultant architecture represents a technical
articulation of transport policies.
Concept of Operation
The executives of different agencies and other stakeholders involved in
ITS need to understand what activities are to take place in the system,
what roles they are expected to play, and what interactions must take
place among them for the ITS services to be delivered.

A concept of operations diagram can portray these relationships, as


exemplified by the architectural sketch in Figure, which graphically depicts
the interactions among three management centres and the police at a
high level for delivering intermodal transportation management and
emergency services.

The figure shows the need to consider both single agency systems (Level
2) and multiagency interoperability (Level 3).
Concept of Operation
Concept of Operation
Concept of Operation
Two groups of advanced traffic management systems (ATMS)
entities are displayed in the figure:

 for the freeways or motorways


 for the urban area

Other entities on the infrastructure side are advanced public


transport systems (APTS), commercial vehicle operations (CVO),
and emergency services.
Concept of Operation
This particular diagram also suggests that there would be a
transport information centre (TIC), which can feed multimodal
transport information to the end users through two information
service providers (ISP1 and ISP2), which are likely to be in the
private sector, and would supply traveller and weather
information, reservation booking, and other services to the end
users.

There is a group of in-vehicle functions that has links with the


outside ITS-world.
Concept of Operations
Requirements
ITS Architectures can be created at national, regional or city
level, or relate to specific sectors or services. They help to
ensure that the resulting ITS deployment:
• can be planned in a logical manner;
• integrates successfully with other systems;
• meets the desired performance levels;
• has the desired behavior;
• is easy to manage;
• is easy to maintain;
• is easy to extend;
• satisfies the expectations of the users.
US ITS Architecture

http://www.ops.fhwa.dot.gov/its_arch_imp/policy_1.htm
US Regulations for ITS Architecture

• FHWA Rule and FTA Policy


• Regions deploying ITS projects shall use the National ITS
Architecture to develop a Regional ITS Architecture
• All ITS projects shall subsequently adhere to the Regional
ITS Architecture and ITS Standards
• Applies to all ITS projects that are funded in whole or in part
with the Highway Trust Fund (including Mass Transit )
National ITS Architecture: Defines..

 The functions (e.g., gather traffic information or request a


route) that are required for ITS
 The physical entities or subsystems where these functions
reside (e.g., the field or the vehicle).
 The information flows and data flows that connect these
functions and physical subsystems together into an integrated
system.
National ITS Architecture: Layers
The National ITS Architecture provides a framework for
planning, programming, and implementing intelligent
transportation systems. The architecture framework is comprised
of

 two technical layers,


 Transportation Layer and
 Communication Layer, which must operate in the context of an
Institutional Layer.
National ITS Architecture: Layers…

The Institutional Layer includes the institutions, policies, funding mechanisms,


and processes that are required for effective implementation, operation, and
maintenance of an intelligent transportation system.

The Institutional Layer is shown as the base because solid institutional support
and effective decisions are prerequisite to an effective ITS program. This is
where the objectives and requirements for ITS are established.
The Institutional Layer is the source for objectives and requirements for the
surface transportation system, including the User Services that are the driving
requirements for the National ITS Architecture.

The Institutional Layer also includes the policies and processes for architecture
use to support transportation planning and project development.
National ITS Architecture: Layers…
The Transportation Layer is where the transportation solutions are
defined in terms of the subsystems and interfaces and the
underlying functionality and data definitions that are required for
each transportation service. This layer is the heart of the National
ITS Architecture.

The Communications Layer provides for the accurate and timely


exchange of information between systems to support the
transportation solutions.
Entry Points Into the Architecture

Source: National ITS Architecture – Version 5


User Services
What is a User Service?

• Defines What ITS Should Do From the User's Perspective


• Represents a Broad Range of Users
• Allows System or Project Definition to Begin by Establishing
the High Level Services That Will Be Provided to Address
Identified Problems and Needs
User Services Bundles

1. Travel and Traffic Management


2. Public Transportation Management
3. Electronic Payment
4. Commercial Vehicle Operations
5. Emergency Management
6. Advanced Vehicle Safety Systems
7. Information Management
8. Maintenance and Construction Operations
Travel and Traffic Management

• 1.1 Pre-trip Travel Information


• 1.2 En-route Driver Information
• 1.3 Route Guidance
• 1.4 Ride Matching And Reservation
• 1.5 Traveler Services Information
• 1.6 Traffic Control
• 1.7 Incident Management
• 1.8 Travel Demand Management
• 1.9 Emissions Testing And Mitigation
• 1.10 Highway Rail Intersection
Transit and E-Payment

2.0 Public Transportation Management


• 2.1 Public Transportation Management
• 2.2 En-route Transit Information
• 2.3 Personalized Public Transit
• 2.4 Public Travel Security
3.0 Electronic Payment
• 3.1 Electronic Payment Services
Logical Architecture
Logical Architecture

• Defines the Processes (the Activities and Functions)


That Are Required to Provide the Required User
Services
• Many Different Processes Must Work Together and
Share Information to Provide a User Service
• Can Be Implemented Via Software, Hardware, or
Firmware
• Independent of Technologies and Implementations
Data Flow Diagram

• Show the Functions That Are Required for ITS and


the Information That Moves Between These
Functions
– Circles Represent the Processes or Functions
– Arrows Represent the Data Flows
– Parallel Lines Represent Data Stores
– Rectangles Represent the Terminators
Manage ITS Data Flow Diagram
Information Management
Travel & Traffic Management Emergency Management
Electronic
Payment

Public
Transportation
Management

Commercial
Vehicle
Operations

M&C Ops
Advanced Vehicle
Source: Version 5 National Safety Systems
ITS Architecture
Manage Traffic – User Services

• 1.1 Pre Trip Travel Information


• 1.2 En-Route Driver Information
• 1.5 Traveler Services Information
• 1.6 Traffic Control
• 1.7 Incident Management
• 1.8 Travel Demand Management
• 1.9 Emission Testing and Mitigation
• 1.10 Highway Rail Intersections
• 3.1 Electronic Payment Services
• 5.3 Disaster Response and Evacuation
• 7.1 Archived Data Function
• 8.1 Maintenance and Construction Operations
Breakdown of Manage Traffic

1.1 Provide Traffic Surveillance


1.2 Provide Device Control
1.3 Manage Incidents
1.4 Manage Travel Demand
1.5 Manage Emissions
1.6 Manage Highway Rail Intersections
1.2 Provide Device Control

1.2.1 Select Strategy


1.2.2 Determine Road and Freeway State
1.2.3 Determine Ramp State
1.2.4 Output Control Data
1.2.5 Manage Parking Lot State
1.2.6 Maintain Static Data for TMC
1.2.7 Provide Roadside Control Facilities
1.2.8 Collect and Process Indicator Fault Data
vehicle_
signage_
data
vehicle_smart_ vehicle_smart_
indicator_ probe_data_ probe_data_
input_data_ indication output Process
from_roads hri_ In-vehicle
tp-cross_ device_ Process smart_probe_ Signage vehicle_
request_ sense Vehicle Smart equip_status_for_ Data sign_data indicator_equip_
received indicator_equip_ Probe Data m_and_c .4 status_from_
status_from_roads_ for Output highways_
for_m_and_c .7 for_m_and_c
tp-cross_
road smart_ vehicle_sign_
probe_reader_ data_status vehicle_sign_equip_
status status_for_m_and_c
vehicle_signage_ td-ramp_state_
wide_area_alert_ indication
information
td-lane_use_ train_ td-lane_use_
indication_ sense_ indicator_control_ indication_
for_roads data monitoring_data_ for_highways
for_highways
traffic_control_
device_status Process tmmc-crossing_
indicator_control_ Indicator clear_at_highways
hri_device_ monitoring_data_ Output
Process control for_roads Data for
td-signal_ Indicator Freeways tmmc-highway_
indication Output Data .5 equipment_status
for Roads
.1 indicator_response_ tmmc-stop_
tmmc-crossing_ indicator_response_ data_for_highways alternate_mode_
clear_at_roads data_for_roads at_highways
Monitor
Roadside
tmmc-road_ Equipment fmmc-crossing_
equipment_status Operation status_for_
for Faults highways
.2
tmmc-stop_
alternate_ reversible_lane_
mode_at_ control
roads indicator_override_ indicator_input_
for_highways local_ data_from_
indicator_override_ signal_override_ t_other_rw_ sensor_ indicator_ highways
for_roads indicator_ status fc_to_fc data_for_ control_
fmmc-crossing_ indicator_ monitoring_ t_other_rw_fc_ highways data_for_
status_for_ control_data_ suspend control_to_ highways
roads for_roads traffic_sensor

intersection_ signal_override_equip_
local_sensor_ state_data status_for_m_and_c td-dms_indication
data_for_roads
f_other_rw_ dms_status_ dms_data_from_
transit_vehicle_ sensor_to_fc har_data for_m_and_c m_and_c
roadway_
Manage priorities dms_auto_treat_ har_status_ har_data_from_m_and_c
Indicator data_from_ for_m_and_c
Preemptions roadway
Provide .3 speed_warning_
Intersection for_display
Collision emergency_ f_other_rw_
Avoidance vehicle_ fc_to_fc dms_auto_treat_ tbv-har_broadcast
Data preemptions data_from_maint
.6 individual_vehicle_
intersection_collision_ dms_auto_treat_ Process speed_for_display
avoidance_data status_to_maint Roadway
local_sensor_ Information dms_data
data_for_roads Data
t_other_rw_ic_control_ f_other_rw_roadway_ .9
to_traffic_sensor info_data work_zone_
dms_status info_for_display
t_other_rw_ Provide Device tp-dms_
ic_to_ic Interface to Other indication dms_status_
Roadway Devices fors- for_mcv
.8 sensor_ har_equip_ dms_
f_other_rw_ic_to_ic data status_for_ har_ control_
m_and_c status data dms_safeguard_
activated_from_roadway
f_other_rw_ fors- dms_equip_ dms_wide_
sensor_to_ic sensor_ status_for_ har_wide_ area_alert_
status m_and_c area_alert_ information
t_other_rw_env_sensor_ information
control_by_auto_treat_
device tors- dms_data_
sensor_ from_mcv dms_barrier_
control activated_
f_other_rw_env_ from_roadway
sensor_data_for_
auto_treat_device
fors-device_
tors-roadway_ status t_other_rw_
t_other_rw_dms_ f_other_rw_ info_data_from_ dms_barrier_ barrier_system_
safeguard_ work_zone_ devices fors-device_ activated_from_ control
activated_ t_other_rw_dms_ intrusion_ control roadway
from_roadway auto_treat_data_ detection
from_roadway barrier_system_
status
fors-roadway_
vehicle_ info_data_from_ tors-device_ Control
pollution_ fors-roadway_ devices status barrier_system_ Barrier
message info_data_from_ equip_status_for_ Systems
sensors m_and_c .10
tors-device_
control

1.2.7-Provide Roadside Control Facilities


Source: Version 5 National ITS Architecture
Process Specification

• Provides an Overview of the Process


• Set of Functional Requirements
• Complete Set of Inputs and Outputs
– Data Dictionary
1.2.7.1-Process Indicator Output Data for Roads

• Implement the indicator output data


• Provide control at intersections or pedestrian
crossings
• Provide the interface for data for units that manage
multimodal crossings or highway-rail intersections
• Monitor the status of the indicator equipment and
provide fault status
• Includes list of Data Inputs and Outputs
vehicle_
signage_
data
vehicle_smart_ vehicle_smart_
indicator_ probe_data_ probe_data_
input_data_ indication output Process
from_roads hri_ In-vehicle
tp-cross_ device_ Process smart_probe_ Signage vehicle_
request_ sense Vehicle Smart equip_status_for_ Data sign_data indicator_equip_
received indicator_equip_ Probe Data m_and_c .4 status_from_
status_from_roads_ for Output highways_
for_m_and_c .7 for_m_and_c
tp-cross_
road smart_ vehicle_sign_
probe_reader_ data_status vehicle_sign_equip_
status status_for_m_and_c
vehicle_signage_ td-ramp_state_
wide_area_alert_ indication
information
td-lane_use_ train_ td-lane_use_
indication_ sense_ indicator_control_ indication_
for_roads data monitoring_data_ for_highways
for_highways
traffic_control_
device_status Process tmmc-crossing_
indicator_control_ Indicator clear_at_highways
hri_device_ monitoring_data_ Output
Process control for_roads Data for
td-signal_ Indicator Freeways tmmc-highway_
indication Output Data .5 equipment_status
for Roads
.1 indicator_response_ tmmc-stop_
tmmc-crossing_ indicator_response_ data_for_highways alternate_mode_
clear_at_roads data_for_roads at_highways
Monitor
Roadside
tmmc-road_ Equipment fmmc-crossing_
equipment_status Operation status_for_
for Faults highways
.2
tmmc-stop_
alternate_ reversible_lane_
mode_at_ control
roads indicator_override_ indicator_input_
for_highways local_ data_from_
indicator_override_ signal_override_ t_other_rw_ sensor_ indicator_ highways
for_roads indicator_ status fc_to_fc data_for_ control_
fmmc-crossing_ indicator_ monitoring_ t_other_rw_fc_ highways data_for_
status_for_ control_data_ suspend control_to_ highways
roads for_roads traffic_sensor

intersection_ signal_override_equip_
local_sensor_ state_data status_for_m_and_c td-dms_indication
data_for_roads
f_other_rw_ dms_status_ dms_data_from_
transit_vehicle_ sensor_to_fc har_data for_m_and_c m_and_c
roadway_
Manage priorities dms_auto_treat_ har_status_ har_data_from_m_and_c
Indicator data_from_ for_m_and_c
Preemptions roadway
Provide .3 speed_warning_
Intersection for_display
Collision emergency_ f_other_rw_
Avoidance vehicle_ fc_to_fc dms_auto_treat_ tbv-har_broadcast
Data preemptions data_from_maint
.6 individual_vehicle_
intersection_collision_ dms_auto_treat_ Process speed_for_display
avoidance_data status_to_maint Roadway
local_sensor_ Information dms_data
data_for_roads Data
t_other_rw_ic_control_ f_other_rw_roadway_ .9
to_traffic_sensor info_data work_zone_
dms_status info_for_display
t_other_rw_ Provide Device tp-dms_
ic_to_ic Interface to Other indication dms_status_
Roadway Devices fors- for_mcv
.8 sensor_ har_equip_ dms_
f_other_rw_ic_to_ic data status_for_ har_ control_
m_and_c status data dms_safeguard_
activated_from_roadway
f_other_rw_ fors- dms_equip_ dms_wide_
sensor_to_ic sensor_ status_for_ har_wide_ area_alert_
status m_and_c area_alert_ information
t_other_rw_env_sensor_ information
control_by_auto_treat_
device tors- dms_data_
sensor_ from_mcv dms_barrier_
control activated_
f_other_rw_env_ from_roadway
sensor_data_for_
auto_treat_device
fors-device_
tors-roadway_ status t_other_rw_
t_other_rw_dms_ f_other_rw_ info_data_from_ dms_barrier_ barrier_system_
safeguard_ work_zone_ devices fors-device_ activated_from_ control
activated_ t_other_rw_dms_ intrusion_ control roadway
from_roadway auto_treat_data_ detection
from_roadway barrier_system_
status
fors-roadway_
vehicle_ info_data_from_ tors-device_ Control
pollution_ fors-roadway_ devices status barrier_system_ Barrier
message info_data_from_ equip_status_for_ Systems
sensors m_and_c .10
tors-device_
control

1.2.7-Provide Roadside Control Facilities


Physical Architecture
Physical Architecture

• Forms a high-level structure around the processes


and data flows in the Logical Architecture
• Defines the Physical Entities and Their Connections
• Relates to Solutions as Implemented
Subsystems

• Individual physical systems that comprise the overall


ITS program
• Four Types
– Center
– Field
– Vehicle
– Traveler
National ITS Architecture Subsystems

Source: Version 5 National ITS Architecture


Key Terms

• Equipment Packages: The building blocks of


subsystems.
– Examples: “Onboard Transit Signal Priority”, “Roadway
Basic Surveillance”
• Architecture Flows: Data exchanged between ITS
subsystems.
– Examples: “signal control data”, “traffic images”
• Service Packages:
– Links needs to appropriate solutions provided by ITS
applications
– Define the components (equipment packages and
subsystems) and interfaces (architecture flows) needed to
implement a particular solution
Service Package Service Areas

Service Packages USER SERVICES


1. Advanced Traveler 1. Travel and Traffic
Information Systems Management
2. Advanced Traffic 2. Public Transportation
Management Systems
Management
3. Advanced Public
Transportation Systems 3. Electronic Payment
4. Emergency Management 4. Emergency Management
5. Maintenance and 5. Maintenance and
Construction Management Construction Operations
6. Archived Data Management 6. Information Management
7. Commercial Vehicle 7. Commercial Vehicle
Operations Operations
8. Advanced Vehicle Safety 8. Advanced Vehicle Safety
Systems
Systems
Service Package Example
Subsystem Architecture Flow

Equipment Package

Source: Version 5 National ITS Architecture


Service APTS7
Package
– Multi-modalExample
Coordination
transit
Transit multimodal Multimodal
Management information Transportation
Other Transit transit service Service provider
Management coordination

transit vehicle
parking lot schedule Transit Vehicle
data request performance
Parking
Management
parking Transit Center On- board Transit
information Multimodal Coordination Signal Priority

local signal
traffic control priority status + traffic control priority request +
priority
request transit information transit system data
request

Traffic
Management
signal control data
TMC Signal Roadway
Control

TMC Multimodal
signal control status
Roadway Signal
Coordination Priority
request for
right of way
Source: Version 5 National ITS Architecture
Service
APTS7 King Package Example
County Metro Multi-modal Coordination

transit
Transit multimodal Multimodal
Management information Transportation
Other Transit transit service Service provider
Management coordination

transit vehicle
parking lot schedule Transit Vehicle
data request performance
Parking
Management
parking Transit Center On- board Transit
information Multimodal Coordination Signal Priority

traffic control priority request +


transit system data local signal
priority
traffic control priority status + request
request transit information

Traffic
Management
signal control data
TMC Signal Roadway
Control

TMC Multimodal
signal control status
Roadway Signal
Coordination Priority
request for
right of way
Consolidated View of the Architecture

Logical Physical
User Service
Bundles
Subsystems

Logical Processes Physical Channels Communications

User Services

Data Flows Architectural Flows

User Services Equipment


P-Specs
Requirements Packages

Data Dictionary
Market Packages

Source: City of Seattle ITS Master Plan (IBI Group)


Developing a Regional
Architecture
What is a Regional ITS Architecture?

• A framework for implementing and integrating ITS


with a region
• Planning tool for identifying gaps in existing and
planned ITS deployments versus transportation
needs
• Involves working with agencies to document
partnerships, roles, and responsibilities.
Developing a Regional ITS Architecture

Source:
Regional ITS Architecture
Guidance: Developing,
Using and Maintaining an
ITS Architecture For Your
Region (October 2001)
Regional ITS Architecture Elements

• Description Of The Region


• Identification Of Stakeholders
• Operational Concept
• Required Agreements
• System Functional Requirements
• Interface Requirements And Information Exchanges
• Identification Of ITS Technical Standards
• Sequence Of Projects Required For Implementation
Operational Concept Development
Operations
Maintenance
City Traffic Com m and Roadway
Managem ent Center Request

Inform ation Sharing

Data
Status
Video
Inform ation Sharing

Data
KEY:
Request Inform ation Sharing
Relationship
Status
Data Inform ation Flow
Video
Request
Status Operational Concept Defines:
Video
• Institutional Relationships Among
State Traffic
Managem ent Center Organizations
• Roles And Responsibilities
• Information Exchange
Agreements Between Organizations

• Documents Current Status of ITS Agreements


• Identifies Needed Agreements as New Projects are
Deployed
• Provides Guidance on Elements of New Agreement
Technical Framework
City Traffic
Roadway
Managem ent Center sensor and surveillance control
roadway inform ation system data
signal control data
TMC Signal Control Roadway Signal
Controls
Collect Traffic Roadway Basic
Surveillance Surveillance
roadway inform ation system status
Traffic Maintenance signal control status
traffic flow
TMC Regional
traffic im ages
Traffic Control

traffic control coordination


traffic inform ation coordination Provides Guidance For Defining
traffic im ages
• System Functional
State Traffic
Managem ent Center
Requirements
• Interface Requirements
TMC Regional
Traffic Control
• Information Exchanges
ITS Technical Standards

• ITS Technical Standards


– Allows systems to “talk to each other”
– Removes dependency on one vendor
– FHWA will tie funding to use of standards
• Identifies Key Regional ITS Technical Standards
• Provides Guidance on Use of Standards
Fitting It Together
Private Information
Toll Administration
Service Providers

Ports

Transit Management

Emissions
Management

County WSDOT City

Rail Operators

Emergency
ITS Backbone
Management

Commercial Vehicle
Administration

Archived Data Fleet and Freight


Management Management
Why Develop a Regional ITS Architecture?

• Saves Time and Money During Project Development


• Guides Coordination Among Individual Projects
• Sets Direction for Improving Efficiency of
Transportation System
• Provides Framework for Sharing Information Among
Agencies and General Public
• Reduces Cost of Implementation
• Conformance With the Federal ITS Requirements Is
Required to Receive Federal Highway Trust Funds
Information Sources

• National ITS Architecture:


– http://www.iteris.com/itsarch/index.htm
• US DOT ITS Program:
– http://www.its.dot.gov/
• ITS Standards:
– http://www.standards.its.dot.gov/standards.htm
• ITS Benefits and Costs
– http://www.benefitcost.its.dot.gov/
• ITS America
– http://www.itsa.org/
• ITS Washington
– http://depts.washington.edu/itswa/

You might also like