Puget Sound Regional ITS Architecture
P R E PA R E D B Y I B I G R O U P
JUNE 2001
a
PB Farradyne, Inc.
Pacific Rim Resources
Battelle Memorial Institute
Puget Sound Regional Council
PUGET SOUND REGIONAL ITS ARCHITECTURE
Prepared by:
in association with:
PB Farradyne
Pacific Rim Resources
Battelle Memorial Institute
June 27, 2001
Table of Contents
1 Introduction ....................................................................................................................................... 1
1.1 Project Overview........................................................................................................................1
1.2 Purpose of Document ...............................................................................................................1
2 Description of Region ..................................................................................................................... 4
2.1 Geographic and Demographic.................................................................................................4
2.2 Transportations Systems ..........................................................................................................4
2.3 ITS Applications .........................................................................................................................5
3 Identification of Stakeholders....................................................................................................... 8
3.1 Potential Stakeholders ..............................................................................................................8
3.2 Stakeholder Outreach.............................................................................................................11
4 Operational Concept .....................................................................................................................13
4.1 Identification of Relevant Market Packages ........................................................................13
4.2 Approach to Developing Operational Concept....................................................................16
4.3 Regional Traffic Control ..........................................................................................................17
4.3.1 Regional Traffic Control Concept.............................................................................17
4.3.2 Regional Traffic Control Information .......................................................................18
4.4 Regional Parking Management .............................................................................................25
4.4.1 Regional Parking Management Concept................................................................25
4.4.2 Regional Parking Management Information...........................................................26
4.5 Transit........................................................................................................................................28
4.5.1 Multi-Modal Coordination..........................................................................................28
4.5.2 Transit Fare Management.........................................................................................33
4.5.3 Transit Data Management........................................................................................35
4.5.4 Transit Traveler Information .....................................................................................35
4.5.5 Other Transit Applications.........................................................................................38
4.6 Incident Management..............................................................................................................38
4.7 Data Archiving ..........................................................................................................................39
4.8 ITS Backbone ...........................................................................................................................40
4.9 Regional Multi-Modal Traveler Information Center (RMTIC) ............................................41
4.9.1 RMTIC Concept..........................................................................................................41
4.9.2 RMTIC Information.....................................................................................................41
4.10 Local Link to CVISN ................................................................................................................41
4.11 Railroad Operations Coordination.........................................................................................42
5 Agreements Between Organizations ........................................................................................44
5.1 Existing, Planned and Potential Agreements ......................................................................44
5.2 Elements of an Agreement.....................................................................................................48
June 27, 2001
i.
Table of Contents
6 Regional Architecture Overview ................................................................................................50
6.1 Washington State Department of Transportation ...............................................................51
6.2 Typical County with Traffic Operations Center ...................................................................51
6.3 Typical City with Traffic Operations Center .........................................................................51
6.4 Typical Traffic Center-to-Center Interface ...........................................................................51
6.5 Transit Architecture .................................................................................................................51
6.6 ITS Backbone ...........................................................................................................................52
6.7 Regional Multi-Modal Traveler Information Center (RMTIC) ............................................52
6.8 Local Link to CVISN ................................................................................................................52
6.9 Emergency Management Service Provider .........................................................................53
6.10 Archived Data Management...................................................................................................53
7 Identification of ITS Standards...................................................................................................54
7.1 Market Packages and Related ITS Standards ....................................................................55
7.2 Common Standards.................................................................................................................58
7.3 The National Transportation Communications for ITS Protocol Family..........................59
7.3.1 NTCIP...........................................................................................................................59
7.3.2 TCIP..............................................................................................................................61
7.4 Puget Sound ITS Backbone ...................................................................................................63
8 Sequence Of Projects Required For Implementation...........................................................64
8.1 ITS Backbone ...........................................................................................................................64
8.2 Determination of Regional Center-to-Center Standard .....................................................64
8.3 Expansion of RMTIC ...............................................................................................................64
8.4 Communications Network.......................................................................................................65
APPENDICES
APPENDIX A: Regional Market Package Databases
APPENDIX B: ITS Architecture Diagrams
APPENDIX C: Standard's Summary
APPENDIX D: National ITS Architecture Definitions
June 27, 2001
ii.
Puget Sound Regional ITS Architecture
1
INTRODUCTION
1.1
Project Overview
The Puget Sound region has been at the forefront of deploying Intelligent Transportation System (ITS)
applications. Until the Seattle Model Deployment Initiative – Smart Trek, the majority of ITS
applications in the region had primarily served the interests of individual state, regional, county, and
local jurisdictions and modes. The Smart Trek project led the effort to link and integrate these various
applications into a comprehensive, integrated transportation management and information system. This
project builds upon these past efforts to define the technical and institutional relationships among
transportation related organizations to move these separated systems into an integrated whole.
The National ITS Architecture was developed for the US Department of Transportation (USDOT) to
serve as a common framework for planning, defining, and integrating Intelligent Transportation
Systems. The development of the Regional ITS Architecture and Integration Strategy is also necessary
to meet the requirements of Transportation Equity Act for the 21st Century (TEA-21), which states that
all ITS projects using federal funding must “conform” to the National ITS Architecture. Specifically,
this project is developing a Regional ITS Architecture for the Puget Sound region to provide for the
continued development and integration of the area’s ITS infrastructure.
1.2
Purpose of Document
A Notice of Final Rule Making, issued on January 8, 2001, will implement the TEA-21 requirements for
ITS project development. The rule making calls for the development of a Regional ITS Architecture to
guide the development of ITS projects and programs and be consistent with ITS strategies and projects
contained in applicable transportation plans. Regional ITS Architecture is defined as a regional
framework for ensuring institutional agreement and technical integration for the implementation of ITS
projects or groups of projects.1 This document presents the recommended Regional ITS Architecture for
the Puget Sound Region.
The intent of the Regional ITS Architecture is to provide guidance to, and act as a resource for,
jurisdictions in the development of their ITS projects. Figure 1-1 illustrates how the sections of this
report can assist in the development of a local ITS project. Starting in the upper left corner is the Puget
Sound Regional ITS Integration Strategy.2 The strategy provides a systematic plan for coordinating and
implementing regional ITS investments funded with highway trust funds to achieve an integrated
regional transportation system. The strategy report provides guidance on how the individual projects in
the region should relate to each other.
•
Section 2 of this report discusses existing and planned ITS applications that provide the
project developer with an understanding of other ITS activities. This can point the
developer to similar projects and provide a framework for their project.
1
January 8, 2001, US Department of Transportation, Federal Highway Administration, 23 CFR Part 940, FHWA Docket No.
FHWA-99-5899 (http://www.its.dot.gov/aconform/archrule_final_1.htm)
2
Puget Sound Regional Intelligent Transportation Systems Integration Strategy, prepared for Puget Sound Regional Council,
prepared by IBI Group in association with Parsons Brinckerhoff, Pacific Rim Resources, and Battelle Memorial Institute,
April 2001.
June 27, 2001
1.
Puget Sound Regional ITS Architecture
•
Section 3 identifies the potential stakeholders that comprise the institutional framework for
the Regional ITS Architecture as well as for the development of local projects. The needs
of stakeholders should be incorporated into the project development process.
•
Section 4 identifies the operational concepts, which characterize the existing, planned, and
potential roles, responsibilities, and interaction among participants in an ITS project and
for the region.
•
Section 5 discusses the nature of the agreements required to formalize the exchanges
characterized by the operational concepts.
•
Section 6 builds on the other sections to present a series of ITS architecture flow diagrams
that provide system functional requirements, interface requirements, and information
exchanges required for the design and deployment of an ITS project within the context of
the Regional ITS Architecture.
•
Section 7 discusses the ITS standards that should be considered in the development of ITS
projects in the region.
June 27, 2001
2.
Puget Sound Regional ITS Architecture
Figure 1-1 Relationship to Project Development
Section 2
Section 3
Stakeholders
Existing and
Planned
ITS Applications
Regional Integration
Strategy
Section 5
Section 4
Operational Concept
Agreements
Subsystem
Subsystem
Equipment
Equipment
Package
Package
Architecture Flow
Equipment
Equipment
Architecture Flow
Package
Architecture
Flow
Package
Terminator
Section 6
Architecture Flow Diagrams
ITS Standards
Local ITS Project
Development
Section 7
National ITS
Architecture
June 27, 2001
3.
Puget Sound Regional ITS Architecture
2
DESCRIPTION OF REGION
2.1
Geographic and Demographic
The central Puget Sound region is located between the Cascade and Olympic mountain ranges and is
bisected by the saltwater inlets of Puget Sound. The region is
largely surrounded by mountains and water, and available
land is restricted by steep hills and sensitive areas. This
limits land suitable for development, and imposes complex
and expensive infrastructure requirements.
The region is made up of four counties: King, Kitsap, Pierce,
and Snohomish, which cover 6,287 square miles. The major
cities of the region are Seattle and Bellevue in King County,
Bremerton to the west across Puget Sound in Kitsap County,
Tacoma to the south in Pierce County, and Everett to the
north in Snohomish County. About 36% of the population
lives in unincorporated areas. Incorporation of the more
densely populated portions of counties was an emerging
trend in the 1990s, since passage of the state’s Growth
Management Act. Since 1990, twelve new cities have been
formed and numerous annexations have occurred in the
region, adding more than half a million people to the
incorporated area.
The population of the central Puget Sound was estimated to
have reached 3,125,300 as of April 1, 2000. This represents an increase o f 466,400 persons or 17% –
1.6% per year on average – since 1990.3
2.2
Transportations Systems
The Puget Sound region consists of approximately 185 miles of interstate, and a total of nearly
16,500 miles of roadway within King, Kitsap, Pierce, and Snohomish Counties. Facilities in the MTS
include those from the following seven transportation systems, supported by Transportation System
Management:
•
•
•
•
•
•
•
3
4
Roadway System, Highways and Arterial Streets
Ferry System
Transit System
Non-Motorized System
Freight and Goods System
Intercity Passenger Rail
Regional Aviation4
Puget Sound Regional Council, Puget Sound Trends, No. D3, “Population of Cities and Towns”, September 2000.
Puget Sound Regional Council, Draft Destination 2030 Plan, March 2001.
June 27, 2001
4.
Puget Sound Regional ITS Architecture
Traffic in the central Puget Sound region continues to grow at about the same rate as population and
employment. In the last decade, population grew 19% and employment grew 27%, while vehicle miles
traveled increased a comparable 26%.5
2.3
ITS Applications
A baseline inventory of existing and planned ITS projects in the region was compiled. Significant
regional ITS initiatives that are multi-jurisdictional and/or multi-modal, affect regional integration of
ITS systems, and directly support national interoperability include:
•
WSDOT Freeway Management System: Washington State Department of Transportation
(WSDOT) operates an extensive freeway traffic management system for the Puget Sound
region. The traffic management system
includes Vehicle Detectors, Closed Circuit
Television (CCTV) Cameras, Ramp Meters,
Dynamic Message Signs (DMS), and
Highway Advisory Radio (HAR). Most of
the field equipment is linked through a fiber
optic communications network. It provides
the data for the traffic congestion map as
well as the video for the camera snapshots that are available over the World Wide Web.
The system is controlled from two linked Traffic System Management Centers (TSMC),
one in Shoreline and the other in Tacoma. Coverage for the remainder of the regional
freeways and other controlled access facilities is planned for the future.6
The TSMC also has direct communication links to the Cities of Bellevue and Seattle for
the sharing of video images and traffic information. More links to other cities are planned
for the future.
•
Traffic Operations Centers : Beyond the WSDOT managed TSMCs, cities and counties
through out the region have or are building traffic operations centers to house advanced,
centralized traffic signal control centers. These centers are being established with the
capabilities to better coordinate traffic signal operations, monitor traffic conditions with
CCTV cameras and roadway traffic surveillance equipment and facilitate the
implementation of transit signal priority.
•
Regional Advanced Transportation Management System (ATMS): WSDOT is also
leading a project to provide electronic connections between the WSDOT TSMC in
Shoreline with traffic signal control systems operated by local and county jurisdictions in
King and Snohomish Counties. This effort began as the North Seattle ATMS and has
expanded to include jurisdictions in eastern and southern King County. This project will
deploy the first center-to-center interface using the emerging National Transportation
Communications for ITS Protocol (NTCIP) standard between WSDOT and Bellevue.
5
6
Puget Sound Regional Council, Puget Sound Trends, No. T2, “Growth in Traffic and Vehicle Miles Traveled”, August 2000
WSDOT Northwest Region Website, http://www.wsdot.wa.gov/PugetSoundTraffic/future.htm
June 27, 2001
5.
Puget Sound Regional ITS Architecture
•
Traffic Operations Center-to-Center Links: There are several existing and near-term
planned electronic links among regional traffic operations centers. These include the links
planned under the Regional ATMS effort.
•
Traffic Signal System Operations : There are a significant number of traffic signal
systems that are operated by one jurisdiction (usually a county) for other jurisdictions. This
cross-jurisdictional responsibility is enabling the implementation of arterial corridor
management strategies.
•
Smart Trek: Currently the Smart Trek website is operating a one-stop source for regional
real-time data. The site in effect is acting as a Regional Multi-Modal Traveler Information
Center providing traffic conditions information, camera images, and transit vehicle location
information, by acting as a portal to public and private sources of information.
•
511 Three-Digit Traveler Information Telephone Number: The Federal
Communications Commission (FCC) has designated 511 as the new telephone number for
traveler information across the country. Cities, counties, WSDOT, and transit agencies
have begun the process of converting their individual transportation information numbers
into the single 511 number for the Puget Sound region. This number will provide travelers
with a single source of information for various modes of travel.
•
ITS Backbone : As part of the Smart Trek project, a common standard and facility for the
real-time sharing of traveler information among jurisdictions was established. Information
from the WSDOT freeway management system and King County Metro bus location
information are available on the ITS Backbone. A more detailed discussion of the
backbone is found in Section 4.8.
•
Trans it Operations Center: To varying degrees, each transit agency in the region has
implemented a transit operations center. As more transit field devices are deployed, and
more data sharing is implemented, these centers will become more robust.
•
Transit Fare Coordination: A joint effort among the region’s seven transit agencies are in
the process of planning and designing the implementation of a regional smart card fare
collection system for the Puget Sound region. The card will operate across a variety of
modes (bus, commuter rail, light rail, and ferries), and provide stored value, period pass,
and other fare payment functions.
•
Transit Traveler Information: The region’s transit agencies have been cooperating on a
joint project to build an automated transit schedule and route information system that
provides each of the transit agencies with information for all transit systems. The Regional
Automated Trip Planning (RATP) links Pierce Transit, Community Transit, King County
Metro, and Sound Transit.
•
Transit Signal Priority: In cooperation with cities, counties and WSDOT, transit agencies
throughout the region have been implementing the capability to provide transit vehicles
with priority at traffic signals. Pierce and Kitsap Counties are deploying infrared bus
detection technology and Snohomish and King Counties are using radio frequency based
Automatic Vehicle Identification (AVI) transponders. The building of at-grade light rail
transit in the region will expand the deployment of transit signal priority.
June 27, 2001
6.
Puget Sound Regional ITS Architecture
•
CVISN: WSDOT is implementing the national Commercial Vehicle Information Systems
and Networks (CVISN) to enhance safety for drivers and trucks and to improve the
operating efficiencies for both government agencies and motor carriers. One aspect of the
project allows trucks with proper credentials and the correct weight to by-pass weigh
stations. AVI transponders are used to identify trucks and provide a key to a roadside
database to check credentials. Weigh-In-Motion (WIM) sensors measure the weight of the
truck. However, the Dedicated Short-Range Communication (DSRC) protocol for AVI
devices for the trucks uses a different DSRC protocol than used in the bus transit signal
priority project.
•
Electronic Border Crossing: WSDOT is implementing a US-Canada electronic border
clearance for commercial vehicles carrying cargo from the Port of Seattle. The same AVI
technology and DSRC protocol that are used for the weigh station bypass program are
deployed here.
•
Intermodal Freight: WSDOT has begun a project to develop a means for integrating
intermodal data at the Port of Seattle. This local effort and other national efforts could
provide a model for future deployments.
•
Electronic Toll Collection: Several initiatives may result in the introduction of tolling or
road pricing schemes in the region. These efforts include the construction of a parallel
Tacoma Narrows Bridge with toll facilities, the recommended introduction of High
Occupancy and Toll (HOT) lanes on I-405 or roadway pricing as a potential source of
transportation funding. Any of these would result in the introduction of electronic toll
collection and the need for DSRC based transponders.
•
Federal Lands Traveler Information: Mt. Rainier National Park is considering
establishing “welcome centers” along approach corridors to the park. This would include
providing real -time parking, weather, avalanche hazard, alternative transportation, and
general park information at kiosks and on dynamic message signs. This information could
also be provided to a website for trip planning purposes. Increased coordination with local
jurisdictions, and WSDOT would also be established.
June 27, 2001
7.
Puget Sound Regional ITS Architecture
3
IDENTIFICATION OF STAKEHOLDERS
3.1
Potential Stakeholders
The Puget Sound Region has many different public and private entities providing transportation related
services, data management, and coordination. A convenient way to characterize these organizations is to
use the center subsystem descriptions found in the National ITS Architecture. Accordingly, the regional
stakeholders can be categorized as follows:
•
Traffic Management (state, county, local): The Traffic Management Subsystem operates
within a traffic management center or other fixed location. This subsystem communicates
with the Roadway Subsystem to monitor and manage traffic flow. Incidents are detected
and verified and incident information is provided to the Emergency Management
Subsystem, travelers (through Roadway Subsystem Highway Advisory Radio and
Dynamic Message Signs), and to third party providers.7
•
Transit Management (transit agencies, ferry system): The transit management
subsystem manages transit vehicle fleets and coordinates with other modes and
transportation services. It provides operations, maintenance, customer information,
planning, and management functions for the transit property. It spans distinct central
dispatch and garage management systems and supports the spectrum of fixed route,
flexible route, and paratransit services.8
•
Emergency Management (police, fire, ambulance, etc.): The Emergency Management
Subsystem operates in various emergency centers supporting public safety including police
and fire stations, search and rescue special detachments, and Hazardous Materials response
teams. This subsystem interfaces with other Emergency Management Subsystems to
support coordinated emergency response involving multiple agencies. The subsystem
creates, stores, and utilizes emergency response plans to facilitate coordinated response.9
•
Information Service Provider (ISP): This subsystem collects, processes, stores, and
disseminates transportation i nformation to system operators and the traveling public. The
subsystem can play several different roles in an integrated ITS. In one role, the ISP
provides a general data warehousing function, collecting information from transportation
system operators, and redistributing this information to other system operators in the region
and other ISPs. In this information redistribution role, the ISP provides a bridge between
the various transportation systems that produce the information and the other ISPs and their
subscribers that use the information. The second role of an ISP is focused on delivery of
traveler information to subscribers and the public at large. Information provided includes
basic advisories, real time traffic condition and transit schedule information, yellow pages
information, ridematching information, and parking information.10
7
USDOT, National ITS Architecture, Version 3.0
USDOT, National ITS Architecture, Version 3.0
9
USDOT, National ITS Architecture, Version 3.0
10
USDOT, National ITS Architecture, Version 3.0
8
June 27, 2001
8.
Puget Sound Regional ITS Architecture
•
Commercial Vehicle Administration: The Commercial Vehicle Administration
Subsystem performs administrative functions supporting credentials, tax, and safety
regulations. It issues credentials, collects fees and taxes, and supports enforcement of
credential requirements. This subsystem communicates with the Fleet and Freight
Management Subsystems associated with the motor carriers to process credentials
applications and collect fuel taxes, weight/distance taxes, and other taxes and fees
associated with commercial vehicle operations. The subsystem also receives applications
for, and issues special Oversize/Overweight and Hazardous Materials permits in
coordination with other cognizant authorities.11
•
Fleet and Freight Management: The Fleet and Freight Management Subsystem provides
the capability for commercial drivers and dispatchers to receive real-time routing
information and access databases containing vehicle and cargo locations as well as carrier,
vehicle, cargo, and driver information. In addition, the capability to purchase credentials
electronically shall be provided, with automated and efficient connections to financial
institutions and regulatory agencies, along with post-trip automated mileage and fuel usage
reporting. The Fleet Management Subsystem also provides the capability for Fleet
Managers to monitor the safety of their commercial vehicle drivers and fleet. The
subsystem also supports application for Hazardous Materials credentials and makes
information about Hazardous Materials cargo available to agencies as required.12
The following table illustrates regional stakeholders by center subsystems. It should be noted that
Information Service Providers (ISPs) could be either public or private organizations. An agency can be
an ISP by simply having a website that provides transportation information. Many organizations listed
under traffic and transit management act as ISPs. They are not represented under the ISP category.
11
12
USDOT, National ITS Architecture, Version 3.0
USDOT, National ITS Architecture, Version 3.0
June 27, 2001
9.
Puget Sound Regional ITS Architecture
Table 3-1: Regional Stakeholders
Traffic Management
State
WSDOT NW Region
WSDOT Olympic Region
Counties
King
Kitsap
Pierce
Snohomish
Cities
Algona
Arlington
Auburn
Bainbridge Island
Beaux Arts Village
Bellevue
Bonney Lake
Bothell
Bremerton
Buckley
Burien
Clyde Hill
Covington
DuPont
Duvall
Eatonville
Edgewood
Edmonds
Enumclaw
Everett
Federal Way
Fife
Fircrest
Gig Harbor
Hunts Point
Issaquah
Kenmore
Kent
Kirkland
Lake Forest Park
Lake Stevens
Lakewood
June 27, 2001
Lynnwood
Maple Valley
Marysville
Medina
Mill Creek
Milton
Monroe
Mountlake Terrace
Mukilteo
Newcastle
North Bend
Orting
Pacific
Port Orchard
Poulsbo
Puyallup
Redmond
Renton
Ruston
Sammamish
SeaTac Airport
Seattle
Shoreline
Skykomish
Snohomish
Snoqualmie
Stanwood
Steilacoom
Sultan
Sumner
Tacoma
Tukwila
University Place
WSDOT
Woodinville
Woodway
Yarrow Point
Marysville
Emergency Management
Ambulance Services
Hospitals
Local Fire
Local Police
Other Emergency Response
Washington State Patrol
WSDOT Incident Response
Information Service Providers
Agency Operated ISPs
Private ISPs
Smart Trek
Commercial Vehicle Administration
Fleet and Freight Management
Burlington Northern Santa Fe
Union Pacific
Shipping Companies
Trucking Companies
Department of Licensing
Washington State Patrol
WSDOT
Washington Trucking Association
Ports
US Customs
Transit Management
Community Transit
Everett Transit
Kitsap Transit
King County Metro
Pierce Transit
Sound Transit
Washington State Ferries
Emergency Management
Ambulance Services
Hospitals
Federal Lands
Mt. Rainier National Parks
Mount Baker/Snoqualmie
National Forest
10.
Puget Sound Regional ITS Architecture
3.2
Stakeholder Outreach
Two stakeholder advisory groups provided guidance and direction for this project. The Regional ITS
Advisory Panel fulfilled this role for the development of the overall Regional ITS integration strategy
and architecture. The Advisory Panel consists of representatives from federal, state, county, and local
transportation agencies and private sector organizations engaged in providing transportation services and
consulting. The Regional Transit Technology Group (RTTG) performed this function for the
development of the more detailed transit architecture. The RTTG includes members from all the
regional transit agencies.
Besides the dialogue with the Advisory Panel, the following discussion group meetings were held with
key stakeholder groups:
•
•
•
•
•
Freight Systems Improvement Team
Traffic Control System Managers
Emergency Management Coordinators
Advanced Traveler Information System Developers
Regional Transit Technology Group
The purpose of these meetings was to collect and summarize information about agency roles and
responsibilities, identify and discuss operational issues, and identify the potential future need for
operational and technology agreements. The discussions were also used to confirm and gather additional
information about existing systems and confirm plans for the expansion of existing systems and/or the
deployment of new ITS systems.
The five discussions group meetings were held to inform the members of these groups about the regional
architecture project and to seek input to help shape the planning process. While the discussion group
members represented a wide-range of interests and levels of familiarity with ITS, there were several
over-arching themes – or gaps identified in the current ITS system – that emerged from all the groups
that were consistent across most of the sessions. The detailed results are contained in the Puget Sound
Regional ITS Architecture Discussion Groups Summary, May 8, 2000.13
In addition, briefing sessions with transportation system managers were conducted with representatives
from cities, counties, WSDOT and transit agencies to gather their input and to determine their
acceptance of the recommended integration strategy. Specific sessions included meetings with:
•
WSDOT staff from the Advanced Technology Branch, Northwest Region, and Olympic
Region
•
Eastside traffic managers including representatives from Bellevue, Redmond and Kirkland
•
Snohomish County traffic managers including representatives from Snohomish County,
Lynnwood, and Everett
•
King County traffic engineer
•
City of Seattle traffic engineer
13
Prepared for Puget Sound Regional Council, Puget Sound Regional ITS Architecture - Discussion Groups Summary,
Prepared by Pacific Rim Resources, May 8, 2000
June 27, 2001
11.
Puget Sound Regional ITS Architecture
•
Pierce County traffic engineer
•
City of Tacoma traffic engineer
Finally, draft copies of the Concept documents, and the Integration Strategy were distributed to over 50
transportation managers in the region for review and comment.
June 27, 2001
12.
Puget Sound Regional ITS Architecture
4
OPERATIONAL CONCEPT
The operational concept portion of the Regional ITS Architecture defines the institutional relationships
among the organizations in the region required for the deployment and operation of a regional integrated
transportation management and information system. The operational concept establishes the roles and
responsibilities between organizations including responsibilities for operation and maintenance and the
level of information, status, and control sharing among the entities. This section provides the
recommended operational concept for the Puget Sound region.
4.1
Identification of Relevant Market Packages
In the National ITS Architecture, market packages provide an accessible, deployment-oriented
perspective to the national architecture. They are tailored to fit - separately or i n combination - real
world transportation problems and needs 14 . The market packages also include a depiction of the
relationship and data flow between different entities providing the “service” provided by the deployment
of the market package. For example, the incident management system market package requires that
traffic management and emergency management centers exchange information. This implies that an
operational concept and an institutional relationship be established between the two organizations that
are cooperating. The identification of which market packages are and will be deployed in the Puget
Sound region leads the way to define an operational concept for the Regional ITS Architecture.
Through the Stakeholder Outreach portion of this project, a survey was sent to each local, county and
state agency to determine what ITS applications where deployed and planned by the jurisdiction and
what interactions were in-place or planned with other organizations. The survey was designed to map
the answers of specific questions directly to the market packages defined by the National ITS
Architecture. Supplemental data was gathered from focus groups and interviews with various relevant
organizations.
Table 4 -1 shows all the market packages that are encompassed by the Regional ITS Architecture. The
market packages are listed by type of public sector organization that are of prime concern for this effort.
Table 4-1: Puget Sound Regional ITS Market Packages
Market Package Name
ITS Data Mart
ITS Data Warehouse
Transit Vehicle Tracking
Transit Fixed-Route Operations
Demand Response Transit
Operations
Transit Passenger and Fare
Management
Transit Security
14
Commercial
Vehicle
Local Emergency
WSDOT Operations Transit Agencies ManagementPSRC
X
X
X
X
X
X
X
X
X
X
X
X
Glossary, USDOT, National ITS Architecture, Version 3.0
June 27, 2001
13.
Puget Sound Regional ITS Architecture
Market Package Name
Transit Maintenance
Multi-Modal Coordination
Transit Traveler Information
Broadcast Traveler Information
Interactive Traveler Information
Dynamic Ridesharing
In Vehicle Signing
Network Surveillance
Surface Street Control
Freeway Control
HOV Lane Management
Traffic Information Dissemination
Regional Traffic Control
Incident Management System
Electronic Toll Collection
Emissions Monitoring and
Management
Standard Railroad Grade Crossing
Railroad Operations Coordination
Parking Facility Management
Reversible Lane Management
Road Weather Information System
Regional Parking Management
Electronic Clearance
CV Administrative Processes
International Border Electronic
Clearance
Weigh-In-Motion
Roadside CVO Safety
On-board CVO Safety
Hazardous Materials Management
Emergency Response
Emergency Routing
Mayday Support
Commercial
Local Emergency
Vehicle
WSDOT Operations Transit Agencies ManagementPSRC
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
A more detailed market package analysis was completed for local traffic management agencies using the
results of the survey. These results are illustrated in Table 4-2. The table shows existing and planned
market packages as reported by each local jurisdiction.
June 27, 2001
14.
Puget Sound Regional ITS Architecture
Table 4-2: Local Jurisdictions and Relevant Market Packages
Y
Bremerton
Y
P
E
E
E
E
E
Burien
P
E
E
E
P
E
F
E
E
Y
Des Moines
Y
E
Edmonds
P
P
E
P
P
P
P
P
P
E
Y
P
P
P
Y
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
P
Y
E
P
E
E
P
Y
P
E
P
E
P
E
Everett
P
P
Y
E
P
E
Federal Way
E
E
Y
E
E
E
E
P
E
P
P
P
P
P
P
E
Fife
E
P
P
Y
P
Kenmore
Y
Kent
Y
P
P
P
P
P
P
P
P
E
E
E
E
Y
P
E
P
P
P
P
Kirkland
P
P
Y
P
P
P
P
P
P
E
E
E
E
P
Y
E
P
E
Kitsap County
Y
Lakewood
P
Y
Marysville
Y
E
Y
P
Y
E
Y
E
E
P
E
King County
Lynnwood
P
E
Covington
Issaquah
P
Transit Security
Surface Street Control
E
Traffic Information Dissemination
Standard Railroad Grade Crossing
Road Weather Information System
Regional Traffic Control
Regional Parking Management
Parking Facility Management
E
P
Roadside CVO Safety (CVO)
P
E
Y
Electronic Clearance (CVO)
P
Bothell
Network Surveillance
Multi-modal Coordination
ITS Data Mart
Interactive Traveler Information
Incident Management System
Emergency Routing
Y
CV Administrative Processes (CVO)
Bellevue
Dynamic Ridesharing
Jurisdiction
Auburn
Broadcast Traveler Information
Market Package Name
Y
P
E
E
P
P
E
E
E
P
P
P
P
E
P
E
E
E
P
E
P
Y
E
Maple Valley
P
Mercer Island
P
Monroe
E
P
Mountlake Terrace
Y
P
Mukilteo
Y
E
E
E
Newcastle
Y
E
E
Y
P
Pierce County
Puyallup
P
E
P
P
E
P
E
Y
Y
E
E
Y
P
E
E
E
E
E
Redmond
P
P
Y
E
P
E
P
E
P
E
E
P
Renton
P
P
Y
P
P
E
P
E
P
E
E
P
SeaTac Airport
E
Seattle
E
E
E
E
P
E
P
P
Y
P
E
E
E
Shoreline
Y
E
E
P
P
P
Snohomish County
Y
P
E
P
E
P
E
E
Y
E
P
P
P
E
E
Sumner
Tacoma
June 27, 2001
P
P
E
E
E
E
P
P
P
P
E
E
P
15.
Puget Sound Regional ITS Architecture
Market Package Name
Tukwila
Y
University Place
Y
P
E
P
P
P
E
P
Y
P
Woodinville
E
E
P
P
P
E
P
Note: E=Existing, P=Planned, Y=Unspecified as Existing or Planned
Most market packages do not require interaction with other organizations, and can be generally
implemented as stand-alone applications locally. In these cases, the market package itself defines the
operational concept for deployment.
However, several market packages have been identified as requiring jurisdictional interaction and the
need to define operational concepts. These market packages are:
•
•
•
•
•
•
•
•
•
Regional Traffic Control (Section 4.3)
Regional Parking Management (Section 4.4)
Multi-Modal Coordination (Section 4.5.1)
Transit Fare Management (Section 4.5.2)
Transit Data Management (Section 4.5.3)
Transit Traveler Information (Section 4.5.4)
Incident Management (Section 4.6)
Data Archiving (Section 4.7)
Rail Crossing Coordination (Section 4.11)
In addition, there are also several specific projects that cross several market packages and will require
the establishment of operational concepts. These are:
•
Transit Applications
- Geographic Information Systems (Section 4.5.5)
- Regional Communications (Section 4.5.5)
•
ITS Backbone (Section 4.8)
•
Regional Multi-Modal Traveler Information Center (Section 4.9)
•
Local Link to Washington State implementation of the national Commercial Vehicle
Information Systems and Network (CVISN) program (Section 4.10)
4.2
Approach to Developing Operational Concept
Each market package or specific project that requires a detailed operational concept will involve
multiple jurisdictional relationships. In several cases, multiple traffic, transit, and emergency
management agencies will need to form relationships with each other to define specific roles and
responsibilities for the deployment of the market package.
Relationships between agencies embody two main components: 1) what roles and responsibilities does
each agency play in the relationship and 2) what kinds of information are shared. Seven types of roles or
responsibilities have been identified to describe agency-to-agency relationships. They are listed as
follows from lowest to highest level of interaction:
June 27, 2001
16.
Puget Sound Regional ITS Architecture
Consultation: One party confers with another party, in accordance with an established process, about an
anticipated action and then keeps that party informed about actions taken.
Cooperation: The parties involved in carrying out the planning and/or project development processes
work together to achieve a common goal or objective.
Coordination: The comparison of the transportation plans, programs, and schedules of one agency with
related plans, programs, and schedules of other agencies and adjustment of plans, programs and
schedules to achieve general consistency.
Information Sharing: The exchange of data, and device status information between parties, for the
purpose of coordinat ed responses, planning, and analysis.
Control Sharing: The ability, through operational agreements, to allow for one party to control another
party’s field devices to properly respond to incident, event, weather, or traffic conditions.
Operations : One party fully operates field equipment of a second party, typically because the second
party does not operate a control center.
Maintenance: One party maintains the field equipment of a second party.
Along with these seven roles and responsibilities are associated information types that are typical for
agency-agency exchange. Five primary types of information exchanges were identified:
Video: The dissemination of live video and still images from one party’s field cameras to another party.
Data: The dissemination of data gathered from one party’s field devices to another party. Data can
include, but is not limited to, traffic data, weather data, parking data, transit data, etc.
Command: The ability for one party to control a second parties field devices. Command can include,
but is not limited to, changing VMS messaging, changing traffic signal timings, camera control, etc.
Request: The ability for one party to solicit either data, or a command change, such a VMS messaging
or signal timings, from another party.
Status: The ability for one party to monitor another parties field devices, and receive such information
as current signal timing/response plan, current message sets, etc.
4.3
Regional Traffic Control
4.3.1 Regional Traffic Control Concept
The Regional ITS Integration Strategy calls for the linking of multiple existing and planned traffic
management centers in the region. This consists of center-to-center sharing of data and, potentially
control, to form an integrated regional traffic management system, which could respo nd in a coordinated
fashion to traffic conditions on the regional highway network. The implementation of this concept
requires local traffic management centers, which can vary from full scale operating centers, such as the
WSDOT TMSC in Shoreline, to single workstations that control local traffic signals.
The National ITS Architecture market package that supports this concept is Regional Traffic Control.
“This market package provides for the sharing of traffic information and control among traffic
management centers to support a regional control strategy. The nature of optimization and extent of
information and control sharing is determined through working arrangements between jurisdictions. This
package relies principally on roadside instrumentation supported by the Surface Street Control and
June 27, 2001
17.
Puget Sound Regional ITS Architecture
Freeway Control market packages and adds hardware, software, and wireline communications
capabilities to implement traffic management strategies which are coordinated between allied traffic
management centers.”15
Within this region, WSDOT NW Region, along with Lynnwood, King County, and Snohomish County
are already serving as concentration points for Regional Traffic Control. Neighboring cities and counties
will ideally coordinate the sharing of data and control of field equipment to better respond to traffic
congestion and incidents. There are three main relationships between jurisdictions with respect to
Regional Traffic Control that have been identified:
Management Center to Management Center: In this relationship, two jurisdictions with traffic
management centers will be linked to allow for the potential of sharing data and control.
Management Center to Operator (without Center): This relationship involves a jurisdiction which
operates equipment such as signals, but does not plan on having a traffic management center (i.e.,
isolated signals). In this scenario, since the jurisdiction without a center will not be able to directly
control others field devices, the relationship is based on “requests”.
Management Center to Non-Operator: This relationship involves a jurisdiction that does not operate
any field devices, but rather has another jurisdiction operate and maintain its signals. This relationship is
considered a cooperative effort as opposed to a coordinated one because there is no sharing of
information or control. It is an important relationship to illustrate however because it indicates areas
where there is an existing “regional or area wide” approach to traffic control.
4.3.2 Regional Traffic Control Information
To characterize the regional traffic control effort, five high level information exchanges have been
identified to define the operational concept for each jurisdiction. These have been preliminarily
formulated to demonstrate the actual exchanges that can happen between centers. They are:
Video: Video will be shared for the purpose of network surveillance, incident identification, and
verification of conditions. This will allow jurisdictions to implement response plans that take into
account visual verification of conditions outside their jurisdiction.
Data: A Data function will include, but not be limited to, the sharing of road condition detector data.
Command: A Command function will include changing VMS messaging, adjusting signal
timings/response plans, adjusting and zooming CCTV camera angles, etc., per jurisdiction to jurisdiction
agreements. This allows for equipment in one jurisdiction to be controlled by another jurisdiction.
Request: In jurisdictional relationships where command of equipment and sharing of data is not direct,
whether by agreement or the lack of a center, a Request function is necessary to “ask” for a modification
to VMS messaging, signal timing, etc.
Status: In order to take proper action in a regional response, it is important to know what messaging is
currently on VMS and HAR that is controlled by other jurisdictions, and what signal response plans
others are using. The status information type provides for sharing equipment status information.
15
USDOT, National ITS Architecture, Version 3.0
June 27, 2001
18.
Puget Sound Regional ITS Architecture
One example of a Regional Traffic Control relationship is between the City of Seattle and WSDOT.
This management center-to-management center connection is operational, and supports coordinated
efforts and data sharing. Key information exchanges include video, data, request, and status. As more
coordinat ed regional control applications are implemented, device control sharing, and exchange of
device command may also play a role in this relationship. These are indicated as a future consideration.
Another example that illustrates a management center to non-operator relationship is the relationship
that King County has with several cities, such as Federal Way and Burien. For these cities King County
operates signals in the local jurisdiction. This relationship consists of cooperation, as the County
operates and maintains signals, but there is no exchange of data or control. However, King County
becomes the mechanism through which Regional Traffic Control can be deployed for these “client”
jurisdictions.
Figures 4.3-1 through 4.3 -5 illustrate the regional relationships that will support Regional Traffic
Control. Each relationship is directional and provides the roles of each agency and what information
types will be shared. Relationships are also described with an existing, planned, or potential
consideration label. Existing and planned status is directly correlated to jurisdictional input through the
survey results. “Potential” indicates relationships that should be considered by jurisdictions when they
develop related ITS applications (i.e., signal control) because of the value they could bring to the
functionality of regional traffic management. Complete tables showing each interaction are found in
Appendix A.
June 27, 2001
19.
Puget Sound Regional ITS Architecture
Coordination
Info Sharing
Video
Data
Request
Status
Control Sharing
Command
Shoreline
Control Sharing
Command
Coordination
Info Sharing
Video
Data
Request
Status
Coordination
Info Sharing
Video
Data
Request
Status
Traffic Management
Kirkland
Control Sharing
Command
Coordination
Info Sharing
Video
Data
Request
Status
Traffic Management
Seattle
Control Sharing
Command
Coordination
Info Sharing
Video
Data
Request
Status
Traffic Management
Tukwila
Control Sharing
Command
Coordination
Info Sharing
Video
Data
Request
Status
Control Sharing
Command
Coordination
Info Sharing
Video
Data
Request
Status
Control Sharing
Command
Coordination
Info Sharing
Control Sharing
Video
Data
Command
Request
Status
Traffic Management
Redmond
Coordination
Info Sharing
Control Sharing
Video
Data
Command
Request
Status
Coordination
Info Sharing
Video
Data
Request Control Sharing
Status
Command
Traffic Management
Bellevue
Coordination
Info Sharing
Control Sharing
Video
Data
Command
Request
Status
Traffic Management
Renton
Traffic Management
Issaquah
Legend
Control Sharing
Command
Auburn
Traffic Management
Kent
Management Center
Coordination
Info Sharing
Data
Request
Status
Operator without
Management Center
Existing Link / Data Flow
Planned Link / Data Flow
Coordination
Info Sharing
Video
Data
Request
Status
Video
Potential Link / Data Flow
Control Sharing
Command
Figure 4.3-1 Regional Traffic Control (City Perspective within King County)
June 27, 2001
20.
Puget Sound Regional ITS Architecture
Traffic Management
Kirkland
Traffic Management
Seattle
Traffic Management
Redmond
Coordination
Info Sharing
Video
Data
Request
Status
Maintenance
Coordination
Info Sharing
Video
Data
Request
Status Control Sharing
Command
Coordination
Info Sharing
Control Sharing
Video
Data
Command
Request
Status
Traffic Management
Tukwila
Control Sharing
Command
Traffic Management
King County
Maintenance
Coordination
Info Sharing
Control Sharing
Video
Data
Command
Request
Status
Traffic Management
Kent
Coordination
Info Sharing
Video
Data
Request
Status
Control Sharing
Command
Coordination
Info Sharing
Control Sharing
Video
Data
Command
Request
Status
Legend
Management Center
Coordination
Info Sharing
Video
Data
Request
Status
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
O&M
Algona
Burien
Covington
Federal Way
Kenmore
Pacific
Sammamish
SeaTac
Shoreline
Woodinville
Coordination
Request
Traffic Management
Bellevue
Control Sharing
Command
Maintenance
Coordination
Info Sharing
Video
Data
Request
Status
Traffic Management
Issaquah
Control Sharing
Command
Coordination
Info Sharing
Video
Data
Request
Status
Coordination
Info Sharing
Video
Data
Control Sharing Request
Command
Status
Control Sharing
Command
Traffic Management
WSDOT NW Region
Operarator without
Management Center
Existing Link / Data Flow
Planned Link / Data Flow
Potential Link / Data Flow
Traffic Management
Snohomish County
Pierce County
Traffic Management
Renton
Figure 4.3-2 Regional Traffic Control (County Perspective within King County)
June 27, 2001
21.
Puget Sound Regional ITS Architecture
Traffic Management
Kirkland
Traffic Management
Seattle
Traffic Management
Redmond
Coordination
Cooperation
Maintenance
Coordination
InfoSharing
Data
Request
Status
Traffic Management
Tukwila
Video
Control Sharing
Command
Traffic Management
SeaTac Airport
Coordination
InfoSharing
Data
Request
Status
Legend
Management Center
Control Sharing
Command
Planned Link / Data Flow
Potential Link / Data Flow
Coordination
InfoSharing
Data
Request
Status
Traffic Management
Issaquah
Control Sharing
Video
Command
Coordination
InfoSharing
Control Sharing
Video
Data
Command
Request
Status
Operarator without
Management Center
Existing Link / Data Flow
Traffic Management
Bellevue
Video
Coordination
InfoSharing
Data
Request
Status
Control Sharing
Video
Command
Coordination
InfoSharing
Data
Request
Status
Traffic Management
WSDOTNWRegion
Control Sharing
Video
Command
Coordination
InfoSharing
Data
Request
Status
Traffic Management
Kent
Control Sharing
Video
Command
InfoSharing
Coordination
Control Sharing
Cooperation
video
InfoSharing
Data
Data
Command
Request
Request
Status
Status
Traffic Management
WSDOTOlympicRegion
Control Sharing
Video
Command Coordination
InfoSharing
Data
Request
Status
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Coordination
InfoSharing
Video
Data
Video
Coordination Comman Request
InfoSharing
Status
d
Control Sharing
Data
Request
Status
Control Sharing
Command
Traffic Management
KingCounty
Auburn
Des Moines
Federal Way
Maple Valley
Traffic Management
Renton
Mercer Island
SeaTac
Woodinville
Figure 4.3-3 Regional Traffic Control (State Perspective within King County)
June 27, 2001
22.
Puget Sound Regional ITS Architecture
Traffic Management
WSDOT NW Region
Traffic Management
King County
Coordination
Info Sharing
Control Sharing
Video
Data
Command
Request
Status
Coordinaiton
Info Sharing
Video
Data
Request
Status
Traffic Management
Snohomish County
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Management Center
Operarator without
Management Center
O&M
Arlington
Bothell
Marysville
Mill Creek
Stanwood
Coordination
Info Sharing
Video
Data
Request
Status
Everett
Coordination
Info Sharing
Video
Data
Requests
Status
Control Sharing
Command
Traffic Management
Lynnwood
Existing Link / Data Flow
O&M
Planned Link / Data Flow
Ÿ Edmonds
Ÿ Mountlake Terrace
Potential Link / Data Flow
Coordination
Info Sharing
Video
Data
Request
Status
Control Sharing
Command
Comman
d
Legend
Control Sharing
Command
Control Sharing
Video
Coordination
Command Info Sharing
Data
Request
Status
Bothell
Edmonds
Mountlake Terrace
Coordination
Info Sharing
Video
Data
Requests
Status
Control Sharing
Command
Figure 4.3-4 Regional Traffic Control (Snohomish County)
June 27, 2001
23.
Puget Sound Regional ITS Architecture
Coordination
Request
Info Sharing
Control Sharing
Video
Data
Command
Request
Status
Coordination
Info Sharing
Video
Data
Request
Control Sharing Status
Command
Lakewood
Coordination
Cooperation
Info Sharing
Control Sharing
Video
Data
Command
Request
Status
Tacoma Narrows
Bridge
Control Sharing
University Place
Cooperation
Maintenance
Cooperation
Coordination
Cooperation
Coordination
Cooperation
Info Sharing
Video
Data
Command
Request
Status
Traffic Management
WSDOT NW Region
Comman
d
Cooperation
Maintenance
Traffic Management
WSDOT Olympic
Request
Comman
d
Coordination
Info Sharing
Video
Data
Request
Status
Cooperation
Request
Coordination
Request
Info Sharing
Video
Data
Request
Status
Control Sharing
Command
Coordination
Cooperation
Pierce County
Ÿ
O&M
Edgewood
Coordination
Request
Legend
Management Center
Traffic Management
King County
Bremerton
Ÿ
Ÿ
O&M
Kitsap County
Silverdale
Coordination
Info Sharing
Control Sharing
Video
Data
Command
Request
Status
Operarator without
Management Center
Existing Link / Data Flow
Coordination
Request
Tacoma
Planned Link / Data Flow
Potential Link / Data Flow
Figure 4.3-5: Regional Traffic Control (Pierce/Kitsap Counties)
June 27, 2001
24.
Puget Sound Regional ITS Architecture
4.4
Regional Parking Management
4.4.1 Regional Parking Management Concept
A need is emerging to provide a coordinated means for parking management. There are several
applications for this concept. The first involves coordination with parking facilities and event venues to
promote parking information previous to large events, such as sporting events and concerts. Providing
pre-trip (internet) and en-route parking (dynamic message signs) information reduces the impacts of
traffic on local arterial networks.
Another application provides for the monitoring of transit park and ride lots, and to provide information
to users of available parking. Again, the output of this monitoring could be pre-trip and en-route
information to t he end-user. Data from this monitoring can also be shared and used for future analysis
and planning.
The National ITS Architecture market package that supports this function is Regional Parking
Management. “This market package supports coordination between parking facilities to enable regional
parking management strategies.”16 Typically in this region, traffic and transit management agencies
would act as the parking management entity. For example, for events at Seattle Center, the City of
Seattle acts as the parking management entity, monitoring lot occupancies and disseminating parking
information. For park and ride lots, the parking management function would typically be provided by
the lot operator (i.e., Sound Transit, etc.), possibly in conjunction with another traffic agency for the
purpose of en-route parking information. The main jurisdictional relationships that support this concept
are:
Traffic Management to Private Parking Operators/Venues: This relationship coordinates event
schedules, and provides anticipated attendance to the traffic management entity to allow for planning of
response plans that might be necessary. Communications with parking operators is necessary to obtain
parking occupancy information.
Traffic Management to Transit Management: Data will likely be shared between these two entities
on the use of park and ride lots. This can be used for future planning, and in cases where a transit agency
is operating the lot, it can be provided to a traffic agency for the dissemination of en-route parking
information.
Traffic Management to Traffic Management: In situations where events may affect the parking
management of adjacent jurisdictions, there may be a need to coordinate proper parking responses.
There may also be the need for cooperation between transit agency operated park and ride lots with the
jurisdiction in which the lot resides.
16
USDOT, National ITS Architecture, Version 3.0
June 27, 2001
25.
Puget Sound Regional ITS Architecture
4.4.2 Regional Parking Management Information
To characterize the regional parking management effort, five high level information types have been
identified to define the operational concept for each jurisdiction. These have been formulated to
demonstrate the actual exchanges that may happen between centers. They are:
Video: Video feeds from parking lot monitoring cameras can be shared by traffic and transit agencies to
monitor lot security and lot occupancy.
Request: Within this market package Requests will be for data. Jurisdictions may request such
information as lot occupancy or VMS status.
Status: A Status function will allow jurisdictions the ability to both monitor the status of specific
parking facilities (lot is FULL, CLOSED, etc.), and also know what pre-trip, and en-route parking
information is being provided to users.
Data: Within a regional parking management system, a Data sharing function would include, but not be
limited to, lot occupancy, event schedules, etc.
Command: This function provides for the shared control of en-route devices such as route guidance
signs to available parking, and potentially control of cameras at parking facilities.
One example of a Regional Parking relationship is that between the City of Seattle and Event Venues for
events at Seattle Center. This planned relationship will provide event schedule information to the city
and share parking data.
Figure 4.4-1 describes the regional relationships that will support Regional Parking Management. Each
relationship is directional and provides the roles of each agency and what information types will be
shared. Existing and planned status is directly correlated to jurisdictional input through the survey
results. “Potential” represent relationships that should be considered because of the value they could
bring to the functionality of the regional application.
June 27, 2001
26.
Puget Sound Regional ITS Architecture
Coordination
Info Sharing
Video
Data
Command
Status
Coordination
Info Sharing
Video
Data
Command
Status
WSDOT
Coordination
Info Sharing
Video
Data
Command
Status
Everett
Transit
Coordination
Info Sharing
Video
Data
Command
Status
King County
Metro
Coordination
Info Sharing
Video
Data
Commad
Status
Coordination
Info Sharing
Video
Data
Command
Status
Kitsap County
Coordination
Info Sharing
Data
Request
Status
Community
Transit
Lynnwood
Video
Pierce Transit
Coordination
Info Sharing
Data
Request
Coordination
Status
Info Sharing
Data
Request
Status
Coordination
Info Sharing
Data
Request
Status
Coordination
Info Sharing
Data
Request
Status
Coordination
Info Sharing
Data
Request
Status
Coordination
Info Sharing
Data
Request
Status
Sound Transit
Other Seattle
Venue
Coordination
Info Sharing
Data
Request
Status
Coordination
Info Sharing
Data
Request
Status
ITS Backbone
Coordination
Info Sharing
Data
Request
Status
Coordination
Info Sharing
Data
Request
Status
Smart Trek
Coordination
Info Sharing
Data
Request
Status
Coordination
Info Sharing
Data
Request
Status
Seattle
Coordination
Info Sharing
Data
Request
Status
Video
Coordination
Info Sharing
Data
Request
Status
SeaTac Airport
Seattle Center
Legend
Parking
Participating Entities
Operator
Amtrak
Existing Link / Data Flow
Planned Link / Data Flow
Potential Link / Data Flow
Figure 4.4-1 Regional Parking Management
June 27, 2001
27.
Puget Sound Regional ITS Architecture
4.5
Transit
Transit services are provided in the Central Puget Sound Region by transit agencies in King, Pierce,
Snohomish, and Kitsap counties. Generally speaking, responsibilities of transit service providers include
provision of services to passengers, as well as managing and maintaining vehicle fleets. To a limited
extent, transit services providers in the region coordinate the provision of services, as well as the sharing
of data with other regional transportation agencies (e.g., WSDOT). The regional transit management
concept, as defined in the Puget Sound Regional Transit Architecture17 , is composed of four primary
functional areas including:
•
•
•
•
Multi-Modal Coordination
Transit Fare Management
Transit Data Management
Transit Traveler Information
The concepts for each of these functions are described below, in addition to other regional initiatives
that currently, or in the future will, enable these functions.
4.5.1 Multi-Modal Coordination
4.5.1.1 Multi-Modal Coordination Concept
One component of the Integration Strategy that has been identified is the integration of trans it operations
both with traffic management centers and among transit agencies. Within the region, opportunities
involving transit signal priority, transit fare and data management, and traffic conditions information
sharing will require multi-jurisdictional/agency coordination.
The National ITS Architecture market package that supports this concept is Multi-Modal Coordination.
This market package is defined as: “This market package establishes two way communications between
multiple transit and traffic agencies to improve service coordination. Inter-modal 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 o n-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.”18
There are four main relationships in the region with respect to these activities that have been identified:
1.
Traffic Management to Transit Management: This relationship involves a transit agency
and a traffic management agency that are working together to implement transit signal
priority, or sharing traffic/transit information.
2.
Transit or Traffic Management to Non-Operating Agency: This relationship involves the
cooperative actions of jurisdictions who are having transit signal priority implemented
within their jurisdiction, but do not operate the signals.
17
Puget Sound Regional Transit Architecture, prepared for Puget Sound Regional Council, prepared by PB Farradyne under
contract to IBI Group, in association with Pacific Rim Resources and Battelle Memorial Institute, May 2001.
18
USDOT, National ITS Architecture, Version 3.0
June 27, 2001
28.
Puget Sound Regional ITS Architecture
3.
Traffic Management to Traffic Management: Within bordering traffic management
jurisdictions there may be the need for coordination planning to transit signal priority.
4.
Transit Management to Transit Management: This relationship will involve the sharing
and coordination of both fare and schedule information to provide for coordinated transit
networks spanning over jurisdictional borders.
4.5.1.2 Multi-Modal Coordination Information
To characterize the multi-modal coordination effort, three high-level information types have been
identified to define the operational concept for each jurisdiction. These have been formulated to
demonstrate the actual exchanges that may happen between centers. They are:
Request: Within this market package there are two types of Requests. The first is a vehicle to field
request where a transit vehicle will request signal priority from the roadside traffic signal controller. The
second is a data request which can cover such things as priority histories, transit reliability, schedule
information, etc.
Status: A Status function will allow jurisdictions the ability to monitor the state of the signals at specific
intersections, i.e., whether the signal cont roller is in a priority phase. Status information will be available
per operating agreements between agencies.
Data: Within a Multi-Modal coordination system, a Data sharing function would include, but not be
limited to, priority history/data, delay reduction, transit schedule information, etc.
One example of a Multi-Modal Coordination relationship is that between Community Transit and the
City of Lynnwood. For transit signal priority planned for intersections within Lynnwood, a TrafficTransit management r elationship is necessary. This includes coordinated efforts in creating priority
criteria, and the sharing of transit priority information. Specific information exchanged within this
relationship will be data (number of requests, number of priority calls, delay times, etc), equipment
status, and requests from transit for priority.
An example of an information sharing relationship that supports Multi-Modal Coordination is between
WSDOT and King County Metro. WSDOT provides express lane status to King County Metro, allowing
Metro to route transit vehicles accordingly.
King County Metro, Community Transit, and Kitsap Transit currently support transit signal priority.
Pierce Transit also hopes to benefit from the efficiencies of transit signal priority in the near future.
Transit signal priority requires communication between the transit vehicle and the roadside. Under King
County Metro’s current architecture, communication between the roadside and the transit management
center is also required. These relationships become complex in a region where the transit agencies pass
through numerous jurisdictions. These communication links are further complicated when transit
agencies use different signal priority systems. Benefits of transit signal priority can be optimize d when
common transit signal priority technologies are seamlessly implemented across multiple jurisdictions.
The regional Multi-Modal Coordination illustration has been divided into three illustrations, one for
each King County (4.5-1), Snohomish County (4.5-2), and Pierce/Kitsap County (4.5.3). Each
relationship illustrated is directional, and provides the roles of each agency and what information types
will be shared. Existing and planned status is directly correlated to jurisdictional input through the
survey results. “Potential” represent relationships that should be considered because of the value they
could bring to the functionality of the regional application.
June 27, 2001
29.
Puget Sound Regional ITS Architecture
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Kirkland
Coordination
Cooperation
Consultation
Tacoma
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Redmond
Info Sharing
Data
Request
Status
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Sound Transit
(Link)
Coordination
Cooperation
Consultation
Coordination
Cooperation
Consultation
Traffic
Transit
ITSManagement
Backbone
Management
ITS Data Mart
June 27, 2001
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Tukwila
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
SeaTac
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Sound Transit
(Sounder)
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Federal Way
Seattle
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Renton
King County
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
WSDOT
Kent
Auburn
Sumner
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Bellevue
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
King County Metro
Shoreline
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Legend
Transit Agency
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
State/County/City
Jurisdiction
Existing Link / Data Flow
Planned Link / Data Flow
Potential Link / Data Flow
Figure 4.5-1 Multi-modal Coordination (King County)
30.
Puget Sound Regional ITS Architecture
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Everett Transit
Snohomish County
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Everett
(Sounder)
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Community Transit
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Mountlake Terrace
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Sound Transit
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Lynnwood
Legend
Edmonds
Transit Agency
State/County/City
Jurisdiction
Existing Link / Data Flow
Planned Link / Data Flow
Figure 4.5-2 Multi-modal Coordination (Snohomish County)
June 27, 2001
Potential Link / Data Flow
31.
Puget Sound Regional ITS Architecture
University Place
Traffic Management
Transit
ITS Management
Backbone
ITS Data Mart
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Kitsap Transit
Traffic Management
Transit
ITS Management
Backbone
ITS Data Mart
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Pierce County
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Bremerton
Gig Harbor
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Legend
Transit Agency
Traffic Management
Transit
ITS Management
Backbone
ITS Data Mart
Sound Transit
(Link)
Planned Link / Data Flow
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
WSDOT
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Puyallup
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Tacoma
State/County/City
Jurisdiction
Existing Link / Data Flow
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Pierce Transit
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Lakewood
Coordination
Cooperation
Consultation
Info Sharing
Data
Request
Status
Traffic Management
Transit
ITS Management
Backbone
ITS Data Mart
Sound Transit
(Sounder)
Potential Link / Data Flow
Figure 4.5-3 Multi-Modal Coordination (Pierce/Kitsap Counties)
June 27, 2001
32.
Puget Sound Regional ITS Architecture
4.5.2 Transit Fare Management
The implementation of a Regional Smart Card based system will allow customers to use one fare
card on multiple systems throughout the region and will support linked trips between transit, ferries
and rail alike. The smart card based system will utilize a wireless data communications process at
applicable operating bases and a central clearinghouse where all smart card-generated trip data and
revenue are reconciled for the region. Transit fare payment data will be collected from vehicles at
the maintenance bases for each transit agency, passed to the regional clearinghouse for processing,
and then returned to each transit agency for their internal use. The current plans for the Regional
Smart Card will support common equipment throughout the region.
Transit fare management functions are supported by the Transit Passenger and Fare Management
market package. This market package allows for the management of passenger loading and fare
payments on-board vehicles using electronic means. Figure 4 .5-4 illustrates the existing, planned,
and potential relationships within the region.
June 27, 2001
33.
Puget Sound Regional ITS Architecture
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Washington State
Ferries
Pierce Transit
Coordination
Cooperation
Consultation
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Info Sharing
Data
Coordination
Cooperation
Consultation
Coordination
Cooperation
Consultation
Info Sharing
Data
Everett Transit
Coordination
Cooperation
Consultation
Info Sharing
Data
Coordination
Cooperation
Consultation
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Coordination
Cooperation
Consultation
Info Sharing
Data
Info Sharing
Data
Info Sharing
Data
Coordination
Cooperation
Consultation
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Community Transit
Info Sharing
Data
Coordination
Cooperation
Consultation
King County Metro
Kitsap Transit
Info Sharing
Data
All Transit Agencies Linked
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Coordination
Cooperation
Consultation
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Legend
Management Center
Operarator without
Management Center
Info Sharing
Data
Sound Transit
(Regional Express)
Sound Transit
(Sounder)
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Existing Link / Data Flow
Planned Link / Data Flow
Potential Link / Data Flow
Sound Transit
(LINK)
Figure 4.5-4 Transit Fare Management
June 27, 2001
34.
Puget Sound Regional ITS Architecture
4.5.3 Transit Data Management
Transit service providers in the central Puget Sound Region do not have near-term plans (in the next
one to five years) to support a regional Archived Data User System (ADUS), specific to transit data.
However, a regional data management system specific to transit has been included in the transit
architecture as a potential project that will require regional integration and data standards. As
agencies develop and deploy new systems during the next five-year period, consideration should be
given to future regional transit data archive requirements.
Transit data management functions are supported by the Transit Data Collection Equipment
Package. The transit data management equipment package collects and stores transit information that
is collected in the course of transit operations performed by the Transit Management Subsystem.
This data can be used directly by operations personnel or it can be made available to other data users
and archives in the region.
4.5.4 Transit Traveler Information
The Regional Automated Trip Planning (RATP) project is the beginning of regional transit traveler
information management. RATP will allow a traveler to call Pierce Transit, Community Transit, or
King County Metro and receive a transit itinerary for travel within all three of the transit agencies
service areas. The schedule and route information eventually will be stored in a central server with
updates electronically transmitted from the agencies. Common data standards will be necessary to
implement the RATP project.
This function is supported by the Transit Traveler Information, Broadcast Traveler Information, and
the Interactive Traveler Information market packages. With the implementation of this market
package, transit information is provided to transit users at transit stops and on-board transit vehicles
as well as at home and work via the internet or other means. Figure 4.5 -5 illustrates the existing and
planned regional relationships, along with the types of responsibilities and data exchanges shared
between entities. Figure 4.5 -6 illustrates potential relationships to be considered in the future.
June 27, 2001
35.
Puget Sound Regional ITS Architecture
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Terminal
Coordination
Cooperation
Consultation
Info Sharing
Data
Status
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Ferries
Coordination
Cooperation
Consultation
Info Sharing
Data
Status
Info Sharing
Data
Command
Request
Status
Info Sharing
Data
Command
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Washington State
Coordination
Cooperation
Consultation
Coordination
Cooperation
Consultation
Everett Transit
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Kingston Ferry
Community Transit
Bainbridge Ferry
Terminal
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
King County Metro
Coordination
Cooperation
Consultation
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Pierce Transit
Info Sharing
Data
Command
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Legend
Management Center
Operarator without
Management Center
Existing Link / Data Flow
Planned Link / Data Flow
Potential Link / Data Flow
Figure 4.5-5 Transit Traveler Information
(Existing and Planned)
June 27, 2001
36.
Puget Sound Regional ITS Architecture
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
King County Metro
Sound Transit
(LINK)
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Community Transit
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Pierce Transit
Sound Transit
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
(Regional Express)
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Sound Transit
(Sounder)
Legend
Management Center
Coordination
Cooperation
Consultation
Info Sharing
Data
Command
Request
Status
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
Operarator without
Management Center
Existing Link / Data Flow
Everett Transit
Planned Link / Data Flow
Potential Link / Data Flow
Figure 4.5-6 Transit Traveler Information
(Future)
June 27, 2001
37.
Puget Sound Regional ITS Architecture
4.5.5 Other Transit Applications
The following provides a brief description of other initiatives in the Central Puget Sound region that
either do, or will, support regional transit management.
Geographic Information Systems
Transit service providers and other transportation agencies in the Central Puget Sound region
maintain several non-integrated Geographic Information Systems. GIS can be used for a variety of
data management, analysis and operational functions that can support the provision of enhanced
transit services.
As regional data sharing and information management develops, the need for and benefit of a
common GIS based referencing system will be increasingly important. Within the next five years,
continued development of regional automated trip planning, real time transit vehicle location
systems, advanced transit traveler information systems, archive data user systems, and
implementation of major service improvements (e.g., Sound Transit), will warrant a focused review
of opportunities for a common GIS referencing system.
In addition, the need for a common GIS extends beyond the provision of transit services. A common
GIS can support other transportation operations such as traffic and emergency management, in
addition to all systems that benefit from sharing information that is geographically based.
Regional Communications
A brief description of communications being used to support regional transit management is
presented below. Detailed descriptions of communication linkages that support regional integration
are provided in the Integration Strategy.
As described in Puget Sound regional integration strategy, the trusted Information Service Provider
(ISP) would be the primary location for the distribution of real-time dynamic informat ion to public
agencies and private ISPs. This process would require regional transportation agencies, transit
service providers, and others to “publish” data and information to the trusted ISP. Data and
information would then be available to any agency, or private ISP who chooses to “subscribe” to it.
With respect to the regional transit agencies, this approach would apply primarily to transit traveler
information, but could be used to support general transit operations functions. This model was
demonstrated as part of the Smart Trek project through the BusView and MyBus features
(www.smarttrek.org).
The ITS Backbone demonstrated under the Smart Trek project represents a model for trusted ISP
implementation. The indivi dual as well as regional architectures identified as part of this current
process, highlight future enhancements and connections to the ITS backbone.
4.6
Incident Management
An incident management initiative would require the sharing of incident information and
transportation system condition information between traffic management agencies and emergency
management agencies. The National ITS Architecture market package that supports this concept is
Incident Management. “This market package manages both predicted and unexpected incidents so
that the impact to the transportation network and traveler safety is minimized. Requisite incident
June 27, 2001
38.
Puget Sound Regional ITS Architecture
detection capabilities are included in the Freeway Control market package and through the regional
coordination with other traffic and emergency management centers, weather service entities, and
event promoters supported by this market package. Information from these diverse sources are
collected and correlated by this market package to detect and verify incidents and implement an
appropriate response.”19
There are a variety of entities throughout the region that must have an active role within this market
package to accomplish a coordinated response to incident situations. From an emergency
management perspective the following stake holders have been identified:
•
•
•
•
•
•
•
Washington State DOT Incident Response
Police Departments
Fire Departments
Ambulance Services
911 Dispatch Centers
Hospitals
Emergency Operations Center
Depending on the level of jurisdiction (state, county, local), different relationships between traffic
management and emergency management occur. There is a need for future work to develop Incident
Management plans to lead the way in developing regional agreements for incident response. In
general several relationships have been identified as being necessary to support the Incident
Management function. These are:
Traffic, and Transit Management to Emergency Management: This relationship consists of
coordinated sharing of traffic conditions and incident information.
Traffic Management to Traffic Management: For some incidents multiple traffic management
agencies will need to take part, and coordinate. This coordination would include incident
information, traffic information, and response plan implementation.
Emergency, Transit or Traffic Management to Information Service Provider: This relationship
will involve the sharing of traffic condition information, and incident information with ISPs for the
dissemination to the general public.
4.7
Data Archiving
A need has been identified to enable transportation management systems to capture and archive
information for future analysis and planning.
The National ITS Architecture market package that supports this concept locally is the ITS Data
Mart. “This market package provides a focused archive that houses data collected and owned by a
single agency, district, private sector provider, research institution, or other organization. This
focused archive typically includes data covering a single transportation mode and one jurisdiction
that is collected from an operational data store and archived for future use.”20 Each agency will have
the responsibility of archiving their individual data internally, playing the role of the ITS Data Mart
19
20
USDOT, National ITS Architecture, Version 3.0
USDOT, National ITS Architecture, Version 3.0
June 27, 2001
39.
Puget Sound Regional ITS Architecture
for their local data. From a regional standpoint an ITS Data Warehouse supports the collection of
data from multiple agencies, varying jurisdictions and modes. PSRC will have the role of archiving
data regionally, while managing the creation of consistent data formats.
4.8
ITS Backbone
The Puget Sound region Smart Trek project was one of
four Metropolitan Model Deployment Initiative (MMDI)
projects sponsored by the US Department of
Transportation to demonstrate the integration of ITS
technologies. A critical component of the Smart Trek
project was the ITS Backbone. Developed by the
University of Washington, the ITS Backbone provides a
structured means to electronically share real -time
transportation system data among organizations. The
backbone is:
FOR MORE INFORMATION
Smart Trek
http://www.smarttrek.org/
ITS Backbone
http://www.its.washington.edu/bbone/
Self-Describing Data for Dummies
http://www.its.washington.edu/bbone/sdd_dum
my.pdf
•
Conceptual: Provides a coordinated method that specifies how participants organize
information flows (gathering, processing, and dissemination) from the data source to
the final user.
•
Functional: Receives information from various organizations that wish to share data;
redistributes information to processors, who process and add value; and gives to
traveler in desired form.
•
Technical: Provides a computer software system specification to be developed for and
integrated into computer systems at each participating organization to run processes to
allow for the sharing of information among the participating organizations via the
Internet.21
The specification is based upon a concept called self-describing data. “Self-Describing Data” (SDD)
is an approach to transmitting and delivering data, such as transportation data, where a stream of
actual data is prefixed with a set of data that “describes” it. The SDD protocols as well as any
currently available data streams are available to the public at the ITS Backbone website. The
Backbone is best suited for the exchange of real-time information (e.g., volumes, speeds) and not
static data (e.g., bus schedules)
The ITS Backbone provides a less formal approach for sharing real -time information without the
development of a formal agreement among jurisdictions. Each jurisdiction would be free to post any
information on the backbone that they are willing to share with others and use the information that is
provided on the ITS Backbone for their own applications. The type of information that could be
posted on the backbone includes freeway traffic flow, arterial traffic flow, bus location and schedule
adherence, and parking facility occupancy. The use of the backbone would provide a means for the
regional sharing of travel information while the more formal NTCIP interfaces are developed over
21
Seattle MMDI Integration Case Study: ITS Information Backbone, Presentation at the ITS America 9th Annual
Meeting -- Washington, DC -- April 22, 1999 by John Collura, James Chang, and Mark Carter.
June 27, 2001
40.
Puget Sound Regional ITS Architecture
time. The ITS Backbone provides a common place for private sector information service providers
(ISPs) to access real -time information from participating jurisdictions.
4.9
Regional Multi-Modal Traveler Information Center (RMTIC)
4.9.1 RMTIC Concept
This concept would create a virtual center to act as a repository for up-to-date traffic, traveler,
weather, and transit information. The Smart Trek website currently serves this function. This would
include surveillance and detection data, transit information (locations, schedule), weather conditions,
incident information, etc. all formatted into a user-friendly, single source of information. This would
provide for a link between the transportation system and the general public.
This concept would require a link from each traffic, transit, and private ISP to the RMTIC for static
information such as transit schedules, construction notices, etc. A link to the ITS Backbone, for
dynamic real-time information would also be needed from the RMTIC, to capture information and
data such as traffic conditions and transit AVL data. The RMTIC would then output information to
personal information access systems, as well as remote traveler systems. Agreements would need to
be reached with the RMTIC operator to determine what types of data and information would be
provided to the general public.
4.9.2 RMTIC Information
The function of the RMTIC concept will feature three types of information exchange:
Video: Video feeds from State and local agencies will be shared to provide images on the RMTIC
site.
Requests : A Request function will be necessary for RMTIC to retrieve information from the ITS
Backbone.
Data: A Data function will be necessary to share information between agencies and RMTIC. This
process will likely take place through the backbone.
4.10
Local Link to CVISN
Individual jurisdictions throughout the region regulate
and permit the movement of commercial vehicles on
their highway network. Permits are issued by each local
jurisdiction with limited coordination with other local
jurisdictions or state regulatory agencies. The bulk of
commercial vehicle regulatory activity occurs at the
state level where responsibilities are shared among
WSDOT, Washington State Patrol, and the Department
of Licensing. To add to the complexity, trucks that
travel outside the state are subject to the regulations of
the states in which they travel.
FOR MORE INFORMATION
Commercial Vehicle Information Systems and
Networks (CVISN) Website
http://www.avalon-ais.com/itscvo/cvisn.htm
Johns Hopkins University Applied Physics
Laboratory CVISN Program
http://www.jhuapl.edu/cvisn/
Introductory Guide To CVISN
http://www.jhuapl.edu/cvisn/downdocs/#general
The US Department of Transportation, Federal Motor Carrier Safety Administration (FMCSA) has
embarked on a program called CVISN (Commercial Vehicle Information Systems and Networks).
June 27, 2001
41.
Puget Sound Regional ITS Architecture
CVISN refers to the collection of information systems and communications networks that support
commercial vehicle operations (CVO). “These include information systems owned and operated by
governments, motor carriers, and other stakeholders. FMCSA’s CVISN program is not trying to
create a new information system, but rather to create a way for existing and newly designed systems
to exchange information through the use of standards and available communications infrastructure.
The CVISN program provides a framewo rk or “architecture” that will enable government agencies,
the motor carrier industry, and other parties engaged in CVO safety assurance and regulation to
exchange information and conduct business transactions electronically. The goal of the CVISN
program is to improve the safety and efficiency of commercial vehicle operations”.22
The three agencies in Washington who are responsible for aspects of CVO are participating in the
implementation of CVISN, which would include the eventual sharing of information with private
fleet management systems. The Puget Sound Regional ITS Architecture includes the provision of a
link from local agencies to gain access to relevant commercial vehicle regulatory information. Local
agencies could be given access to the state’s CVISN system for inquiry purposes. The WSDOT
electronic permitting system is called SNOOPI (System Network for Oversize, Overweight Permit
Information). Over time, a joint electronic permitting system with local agencies could be developed.
Formal agreements for access to this information will be required.
4.11
Railroad Operations Coordination
The Puget Sound region is well served by two major railroads – Burlington Northern Santa Fe
(BNSF) and Union Pacific. These two railroads provide service to the major ports in the region and
many local customers. The track upon which this service depends crosses many major roadways in
the region as at -grade crossings. When a train is in the crossing, vehicle traffic is delayed. The
market package that can help address this situation is Rail Operations Coordination. This market
package provides a level of strategic
coordination between rail operations and
traffic management centers. Rail
operations centers provide 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.23
Both railroads operate national train operation centers like the 45,000-square-foot center shown for
BNSF, which monitors 35,000 route miles. Because of the national scope of these centers,
developing a coordinated approach for a specific region could be a challenge. However, many
jurisdictions across the country face the same challenge and a national solution could be developed
22
23
Kim E. Richeson, Introductory Guide to CVISN (POR-99-7186) Preliminary Version P.2, February 2000
USDOT, National ITS Architecture, Version 3.0
June 27, 2001
42.
Puget Sound Regional ITS Architecture
that meets local and national needs. Locally, a relationship is necessary between the rail freight
carriers and the Sounder Commuter Rail to coordinate schedules.
June 27, 2001
43.
Puget Sound Regional ITS Architecture
5
AGREEMENTS BETWEEN ORGANIZATIONS
The Regional ITS Architecture provides both a technical and institutional framework for the
deployment of ITS in the Puget Sound region. Institutional integration involves coordination
between various agencies and jurisdictions to achieve seamless operations and/or interoperability.
The existing and recommended operational concepts defined in the previous section provide
guidance for the functional requirements of inter-jurisdictional interactions. These interjurisdictional operational concepts in turn point directly to the types of agreements that may
potentially be required between individual organizations. Either informal or formal agreements are
required to define the roles and respons ibilities for each of these interactions. This section of the
report discusses the status of agreements in the region and a checklist for consideration in
developing an agreement.
5.1
Existing, Planned and Potential Agreements
The operational concept section of the report identified the key market packages and ITS
deployment activities that would require establishment of an electronic link between and among
organizations. From an institutional integration perspective, these electronic links will require the
establishment of some form of agreement to define roles and responsibilities of each party. Table 5-1
summarizes the status of the existing, planned and potential agreements that would be needed for the
deployment of an integrated transportation management system in the region. Any considerations
relating to the development of agreements are also listed. Key points to consider included:
•
Regional Traffic Control: This may be the most complex area for the development of
inter-agency agreements. Section 4 illustrated the extensive nature of existing and
planned connections among traffic signal control systems in the region. The initial
implementations will be for the sharing of highway system data and control system
status. The complete implementation of this market package would result in the joint
sharing and potential control of traffic signals, detectors, cameras, ramp meters, and
dynamic message signs. Agreements that detail the limits of authority, operational
discretion, and liability will be required before “joint control” would be implemented.
A critical technical agreement required for interoperability will be the identification of
the preferred center-to-center NTCIP standard to enable this market package.
•
Multi-Modal Coordination: The deployment of transit signal priority in the region is
well under way with formal agreements defining roles and responsibilities.
•
Regional Parking Management: In the longer term, this market package may be
deployed beyond Seattle event venue sites.
•
Transit: Fare management and transit information activities are also well on their way
under a formal arrangement. These two activities may pave the way for the automated
gathering of transit data.
June 27, 2001
44.
Puget Sound Regional ITS Architecture
•
ITS Backbone : The ITS Backbone is operational and open to any user. It is
recommended that conditions for use for both suppliers and users of information be
formalized. The conditions would set expectations for what the ITS Backbone is and is
not. The Smart Trek Operations Plan24 defines these expectations.
•
Regional Multi-Modal Traveler Information Center: The Smart Trek website is
providing this service now by acting as a regional portal to other organizations
websites. In the longer term, Smart Trek may take on a more active role in
incorporating information from multiple organizations i nto an integrated, multi-modal
site.
•
Incident Management: The recommended development of corridor incident
management strategies will result in the better definition of how technology can
address incident management. Agreements between transportation and e mergency
management organizations will need to be developed at that time.
•
511 Three-Digit Traveler Information Telephone Number: The Federal
Communications Commission (FCC) has designated 511 as the new telephone number
for traveler information across the country. This number is designed to be the single
telephone number for obtaining traveler information for all modes. Jurisdictions within
the Puget Sound region have begun a cooperative process to transition the multiple
transportation information numbers in the region to this one number. The planning and
deployment process will take several years.
•
Data Archiving: Movement toward an automated system of archiving data at the
regional level will require the development of agreements on the format, access and use
of the information.
•
Communications : There are multiple examples and opportunities for the sharing of
communications infrastructure throughout the region. A regional plan and subsequent
agreements that define responsibilities could result in the communications network
required to link the various ITS applications together.
24
Smart Trek Operations Plan, prepared by David Evans and Associates, Inc, prepared for Washington State Department
of Transportation, November 1999.
June 27, 2001
45.
Puget Sound Regional ITS Architecture
Table 5-1: Summary of Inter-Agency Agreement Status
AREA
Regional Traffic
Control
EXISTING
PLANNED
POTENTIAL
ISSUES
King County, Snohomish County,
Pierce County, Bremerton, and
Lynnwood have agreements for
operations and maintenance with
multiple jurisdictions. (See
Section 4.2)
WSDOT is planning
additional links to
multiple jurisdictions for
data and video sharing.
(See Section 4.2)
Section 4.2 identifies potential
future links, which will require
agreements.
Agreements on shared control will
need to be developed for relevant
jurisdiction-to-jurisdiction operations.
An agreement pertaining to the
specific NTCIP Center-to-Center
Protocol to deploy will be needed.
Technology agreements may be
required in the longer term to meet
dedicated short-range communication
standards for transit signal priority
applications.
WSDOT, Seattle, and Bellevue
have agreements for data and
video sharing.
Multi-Modal
Coordination
Agreements are in place or under development for the
deployment of transit signal priority in all regional counties.
(See Section 4.3)
Additional agreements will be
required when the Light Rail
System is operational.
Regional Parking
Management
N/A
The sharing of parking condition
information could develop
around existing and planned
park-and-ride and transit station
parking facilities. (See Section
4.4)
Transit Fare
Management
Transit Traveler
Information
Transit Data
Management
Regional Fare Coordination Project provides the agreement
structure.
ITS Backbone
June 27, 2001
Seattle is working with
venue operators to
provide information to
the public.
N/A
Current transit information system
provides framework.
Should be able to expand on current arrangement.
N/A
Agreements on format,
access and use are
needed for regional
sharing of information.
Working agreements exist for
WSDOT and King County.
Expectations for suppliers and users of the ITS Backbone should be established as a terms of use
notification.
46.
Puget Sound Regional ITS Architecture
AREA
Regional MultiModal Traveler
Information Center
Incident Management
EXISTING
PLANNED
POTENTIAL
Smart Trek website provides this
function as portal to traveler
information sites.
N/A
Expanded services will require
the development of a more
formal agreement.
WSDOT and Washington State
Patrol share incident data and
video.
Other agreements will be
developed as part of
recommended incident
management strategies.
Electronic sharing agreements
will be required in the future.
ISSUES
Local Link to CVISN N/A
Agreements on access to CVISN information will be needed
with WSDOT, WSP, and Department of Licensing.
511 Three-Digit
Traveler Information
Telephone Number
Data Archiving
N/A
Local and State agencies are working together to develop a
transition plan. Formal agreements will be required.
Cooperation with local telephone
service carriers will be required.
WSDOT and other jurisdictions
provide information on websites
without restrictions.
Other jurisdictions are
planning to provide
information without
restrictions.
Agreements on format, access
and use are needed for regional
sharing of information.
Regional approach is recommended
but needs definition.
Communications
WSDOT and other jurisdiction
share communications links.
Other jurisdictions are
planning links with
WSDOT and adjacent
neighbors.
The WSDOT Light Lanes project
has the potential to provide an
upgraded communications
backbone within the region and
across the state.
Regional approach is recommended
but a communications plan should be
developed to provide a road map.
June 27, 2001
47.
Puget Sound Regional ITS Architecture
5.2
Elements of an Agreement
Agreements are established to clearly define responsibilities among the involved parties. The level of
formality generally increases as risks escalate and when financial transactions take place. Formality will
also increase when the performance or lack of performance on the part of one organization impacts the
operations of another. For example, if an agency maintains and operates the traffic signals of another
agency, failure to restore a failed traffic signal in a timely fashion could have a significant impact. As
different systems are linked together, they will depend upon each other. The clear definition of
responsibilities for all parties will help ensure smooth operations.
The following is an annotated checklist of elements to consider in the development of an agreement for
ITS operations and maintenance. Not all elements are relevant to each exchange of information. The
level of specificity will depend on the nature of the information link.
•
Operational Concept (A layman’s introduction to the nature and purpose of the agreement.)
•
Duties of Responsible Organizations (A summary of duties and responsibilities.)
•
Data Sharing (Aspects of sharing data to be considered.)
Provision of Data
Data Rights
Data Reuse
Data Identification
Data Availability
Data Accuracy
•
Control Sharing (Aspects of sharing control to be considered with rights and priorities
being clearly understood.)
Provision of Control
Control Rights
Control Restrictions
Control Priority
Control Availability
•
Connections (Defines how the connection is made.)
Provision o f Equipment
Physical Access Point
Demarcation Point
Security
Configuration Management
Standards and Protocols
•
System Documentation
•
Operations
Contacts
Hours of Operations
Responsibilities
June 27, 2001
48.
Puget Sound Regional ITS Architecture
•
Maintenance
Contacts
Hours of Operations
Responsibilities
Response Time
•
Liability
Indemnity
Damage to Equipment
Liability
•
Ownership
Equipment
Software
Intellectual Property
•
Coordination
Notification
Periodic Reporting
Pre-Change Coordination Meeting
•
Dispute Resolution
•
Termination of Agreement
•
Compensation
In Washington State, there is a long history of formal and informal inter-agency agreements. The
majority of formal agreements involve the transfer of funds from one organization to another and have
generally involved transportation construction projects. However, there are still a wide number of
existing agreements that address operations and maintenance, which can serve as models. Both King
County and Community Transit have developed agreements for the installation, operation, and
maintenance of transit signal priority equipment. Several jurisdictions (e.g., King County, Lynnwood,
Snohomish County) operate and maintain signals for other jurisdictions. These agreements touch all of
the issues listed above.
June 27, 2001
49.
Puget Sound Regional ITS Architecture
6
REGIONAL ARCHITECTURE OVERVIEW
A key objective for defining the Regional ITS Architecture is to provide jurisdictions with guidance
during the development of individual ITS projects. Previous sections have addressed operational
concepts and potential agreements between jurisdictions. This section provides high-level guidance in
the definition of system functional requirements, interface requirements and information exchanges. The
approach taken in this report is to develop a series of illustrative diagrams depicting:
•
Subsystems : “The principle structural element of the Physical Architecture. There are
19 subsystems in the National ITS Architecture, which are grouped into four classes:
Centers, Roadside, Vehicles, and Travelers. Example subsystems are the Traffic
Management Subsystem, the Vehicle Subsystem, and the Roadway Subsystem. These
correspond to existing things in the physical world: respectively traffic operations centers,
automobiles, and roadside signal controllers.”25
•
Equipment Packages: “The building blocks of the Physical Architecture subsystems.
Equipment Packages group like processes of a particular subsystem together into an
“implementable” package.”26
•
Architecture Flow Between the Subsystems : “Information that is exchanged between
subsystems and terminators in the Physical Architecture. Each architecture flow contains
one or more data flows from the Logical Architecture.”27
The descriptions of the equipment packages from the National ITS Architecture combined with the
architecture flows between the subsystems provides an excellent starting point for defining functional
requirements. The National ITS Architecture contains databases, which allow the user to link these items
back to the logical architecture when used to develop detailed functions specifications. Information
exchanges and interface requirements are primarily defined by the architecture flows. These diagrams
should provide a useful starting point and check list for these efforts.
Diagrams were developed for a wide range of organizations throughout the region. Some depict existing
operations and others provide illustrations of how a local or county jurisdiction might define its local
ITS architecture for compliance with the Regional ITS Architecture. The following sets of diagrams are
found in Appendix B:
•
•
•
•
•
•
•
•
Washington State Department of Transportation
Typical County with Traffic Operations Center
Typical City with Traffic Operations Center
Typical Traffic Management Center-to-Center Interface
Detailed Transit Architecture (one for each agency in the region)
ITS Backbone
Regional Multi-Modal Traveler Information Center (RMTIC)
Local Link to CVISN
25
National ITS Architecture Glossary, Version 3.2, September 2000
National ITS Architecture Glossary, Version 3.2, September 2000
27
National ITS Architecture Glossary, Version 3.2, September 2000
26
June 27, 2001
50.
Puget Sound Regional ITS Architecture
•
•
Typical Emergency Management Service Provider
Archived Data Management
6.1
Washington State Department of Transportation
The WSDOT architecture involves two separate Traffic Management Subsystems representing the
Northwest and Olympic regions. Coordination exists between the two centers with each operating their
own roadway devices, and having links to various transit agencies. Each center also has links for
coordination to counties and cities. Figure B-1, in Appendix B, illustrates the WSDOT architecture.
6.2
Typical County with Traffic Operations Center
Typical county architectures have several key components. One is the close coordination with other
traffic management agencies on the state, county and local levels, and links to the roadway system. This
includes both links to county owned roadways as well as those owned by other jurisdictions. This
represents a county’s unique role of providing comprehensive operations and maintenance functions to
other jurisdictions. Figure B-2 also illustrates connections to transit, emergency, and commercial vehicle
entities.
6.3
Typical City with Traffic Operations Center
The City of Seattle architecture was chosen as a representation of a city with a Traffic Operations
Center. This diagram illustrates a city operating roadside equipment, with links to transit agencies,
emergency agencies, parking management, commercial vehicle administration, as well as a link to traffic
management on the state level. Figure B-3, in Appendix B, illustrates a city level architecture.
6.4
Typical Traffic Center-to-Center Interface
A typical center-to-center interface architecture is represented most simply by illustrating two centers
with distinct roadways. Each agency operates their own equipment but with the coordinated ability to
share data and control with another agency. Other sources of data could also be shared across this
interface such as input from other centers or ISPs. A typical interface is illustrated in Figure B-4, in
Appendix B.
6.5
Transit Architecture
Transit architecture diagrams graphically represent the technology each transit agency is currently
supporting or expects to enhance/implement in the next one to five years. As defined in the National ITS
Architecture, the physical architecture includes t he four subsystems that are applicable to the transit
agencies in the Puget Sound region: 1) traveler, 2) center, 3) vehicle, and 4) roadside.
June 27, 2001
51.
Puget Sound Regional ITS Architecture
The following physical architecture diagrams are provided in Appendix B; Figures B-5 through B-12.
These diagrams are described in more detail in the Puget Sound Regional Transit Architecture.28
•
•
•
•
•
•
•
•
Community Transit
Everett Transit
King County Metro
Kitsap Transit
Pierce Transit
Sound Transit (Sounder)
Sound Transit (LINK)
Washington State Ferries
6.6
ITS Backbone
The ITS Backbone architecture illustrates the Backbone as a central entity for centers to publish real time data, for the purpose of agency to agency data exchange. Figure B-13 illustrates the relationships
and data flows that correspond to the ITS Backbone.
6.7
Regional Multi-Modal Traveler Information Center (RMTIC)
The architecture for the RMTIC application consists of both static and dynamic data inputs. Various
ISPs, such as traffic, transit, and private, will share static information with RMTIC. This includes such
information as transit schedules, construction notices, detour routes etc. Another input link to the
RMTIC application is from the ITS Backbone. This link will allow RMTIC to capture real -time dynamic
data from the various traffic, transit, and emergency f ield devices. This data could include traffic
conditions, and bus locations through AVL.
The function of the RMTIC is to process and format all incoming static and dynamic data and make it
available to the general public. Dissemination of data requires the RMTIC to be linked to the Traveler
Subsystems.
Figure B-14, in Appendix B, illustrates the RMTIC architecture. Inputs to RMTIC could be expanded to
include weather services, construction and maintenance, etc.
6.8
Local Link to CVISN
This architecture illustrates the local and state responsibilities for local CVISN applications. A link is
needed between these two entities for the exchange of commercial vehicle information. The state
function in this application is a link to the Fleet and Freight Management Subs ystem for the purpose of
credentials and compliance. The local Commercial Vehicle Administration role is to operate vehicle
checks within their jurisdictions for roadside safety inspections.
Figure B-15, in Appendix B, illustrates the Local Link to CVISN architecture.
28
Draft Puget Sound Regional Transit Architecture, prepared for Puget Sound Regional Council, prepared by Parsons
Brinckerhoff in association with IBI Group, Pacific Rim Resources, and Battelle Memorial Institute, January 2001.
June 27, 2001
52.
Puget Sound Regional ITS Architecture
6.9
Emergency Management Service Provider
The Emergency Management architecture represents three emergency market packages: Emergency
Response, Emergency Routing, and Mayday Support. Figure B-16, in Appendix B, illustrates a typical
emergency management center with connections to traffic and transit management entities, as well links
to Vehicle and Traveler subsystems.
6.10
Archived Data Management
The Archived Data Management architecture represents both local and regional data storage. Each
“center” e ntity will operate its own internal ITS Data Mart, for storage of its device data. Each center
will also have a link to a single regional Data Warehouse, which will act as a repository for region.
Figure B-17, in Appendix B, illustrates the Archived Data M anagement function. This figure could be
expanded to include input from such entities as parking management, emissions management, etc.
June 27, 2001
53.
Puget Sound Regional ITS Architecture
7
IDENTIFICATION OF ITS STANDARDS
“ITS standards are specifications that define how transportation system components interconnect and
interact within the overall framework of the National ITS Architecture. They specify how different
technologies, products, and components interconnect and interoperate among the different systems so
that information can be shared automatically.”29
In actuality, ITS standards contain and specify the technical details on how to do build and integrate ITS
systems and components consistently. The key point is that standards provide the spectrum of technical
detail that enables the design and deployment of an integrated ITS system throughout the region.
Standards allow different systems to speak to each other in a common language, using common data
elements, well-defined data structures or ”messages”, and well-understood protocols or rules for data
exchange and sharing. The use of common ITS standards completes the technical integration aspect of
the regional architecture. This section identifies the applicable ITS standards that support Puget Sound
regional interoperability, and national interoperability.
The ITS standards are being developed by several working groups composed of public and private
sector stakeholders within Standards Development Organizations (SDOs). The process is partially
supported by the US Department of Transportation. There are seven SDOs actively participating in ITS
standards development activities:
•
•
•
•
•
•
•
AASHTO (American Association of State Highway and Transportation Officials)
ANSI (American National Standards Institute)
ASTM (American Society for Testing and Materials)
IEEE (Institute of Electrical and Electronics Engineers)
ITE (Institute of Transportation Engineers)
NEMA (National Electrical Manufacturers Association)
SAE (Society of Automotive Engineers)
There are approximately 80 standards that are unique to ITS applications. Many of these 80 standards
have already passed through the development process, and have been approved and published by the
applicable SDO(s). Others are progressing and will be approved soon.
From the perspective of USDOT and its agencies, the use of ITS standards is not currently mandatory.
However in TEA-21, Congress required the USDOT to "ensure that ITS projects carried out using funds
made available from the Highway Trust Fund…conform to the national architecture, applicable
standards, or provisional standards and protocols." Thus the use of ITS standards will be made
mandatory by a rulemaking process that begins with the USDOT publishing a "Notice of Proposed
Rulemaking (NPRM)" in The Federal Register and includes a public comment period. If the rule is made
final, it will lead to USDOT “adopting” specific ITS standards. Once these particular published
standards are adopted, their use will be mandatory in applicable ITS projects that receive federal
funding30 . In the interim, it makes good sense to utilize approved ITS standards in system design and
29
30
Frequently Asked Questions About ITS Standards, USDOT ITS Standards Website, http://www.its-standards.net/FAQ.htm
Frequently Asked Questions About ITS Standards, USDOT ITS Standards Website, http://www.its-standards.net/FAQ.htm
June 27, 2001
54.
Puget Sound Regional ITS Architecture
implementation exclusive of their being mandatory. This approach has little risk and facilitates future
integration opportunities for pre-adopted standards -based legacy ITS systems.
7.1
Market Packages and Related ITS Standards
In Section 4 of the report, a set of market packages that have been or most likely will be deployed in the
Puget Sound Region was identified. These market packages were compared against applicable ITS
standards. The results of this analysis are presented in Table 7-1. Market packages are shown on the left
(rows) by functional type, and the standards are presented alphabetically across the top (columns).
Applicable standards for each market package are indicated by check marks.
The special market package labeled “ITS infrastructure” represents some of the underlying foundation
standards. USDOT maintains an up-to-date website summary on the status of all ITS standards
(http://www.its-standards.net/). A copy of the February 2001 summary is provided in Appendix C of this
report. This summary document provides an explanation of each standard and provides additional
contact information to obtain more details. However, because ITS standards are under active
development, new information is being updated regularly at the USDOT website and should be
consulted as needed for the latest information. The table provides an overview of relevant standards and
can serve as a starting point for determining applicable ITS standards to be used during project
development. Key standards that will support ITS interoperability in the region are discussed below.
June 27, 2001
55.
Puget Sound Regional ITS Architecture
Table 7-1: Market Packages and Applicable Standards
June 27, 2001
56.
Puget Sound Regional ITS Architecture
June 27, 2001
57.
Puget Sound Regional ITS Architecture
7.2
Common Standards
There are a series of standards that de fine terms, data elements and message sets, and foundation
standards that cut across many market packages. These standards form the basis for interoperability
among systems by defining a common set of terms and information elements. The several standards t hat
should be adopted and used by regional jurisdictions in the development of ITS applications include:
•
Data Dictionary for Advanced Traveler Information System (ATIS): A minimum set
of media-independent data elements needed by potential information servi ce providers to
deploy ATIS services and provide the basis for future interoperability of ATIS devices.
•
Message Set for Advanced Traveler Information System (ATIS): A basic message set
using the data elements from the ATIS data dictionary needed by potential information
service providers to deploy ATIS services and to provide the basis for future
interoperability of ATIS devices.
•
Message Sets for External TMC Communication (MS/ETMCC): A message set
standard for communication between transportation system management centers and other
ITS centers, including traffic and transit management systems, information service
providers, emergency management systems, and emissions management systems.
•
National Location Referencing Information Report: A basis for location referencing
standardization activities by various application communities and SDOs.
•
Standard for Common Incident Management Message Sets (IMMS) for use by
Emergency Management Centers (EMC): Standards describing the form and content of
the incident management message sets for emergency management systems to traffic
management systems and from emergency management systems to the emergency
telephone system or (E911).
•
Standard for Data Dictionaries for Intelligent Transportation Systems : A set of metaentities and meta-attributes for ITS data dictionaries, as well as associated conventions and
schemas, that enable describing, standardizing, and managing all ITS data.
•
Standard for Functional Level Traffic Management Data Dictionary (TMDD): This
document includes data elements for traffic control, ramp metering, traffic modeling, video
camera control traffic, parking management and weather forecasting, as well as data
elements related to detectors, actuated signal controllers, vehicle probes, and dynamic
message s igns. It also contains data elements for roadway links, for incidents and trafficdisruptive roadway events.
•
Standard for Traffic Incident Management Message Sets for Use by EMCs: Enables
consistent standardized communications among incident management centers, fleet and
freight management centers, information service providers, emergency management
centers, planning subsystems, traffic management centers and transit management centers.
These key baseline standards are critical for the deployment of a wide range of market packages because
they establish the common vocabulary of data elements and message structures that allow regional ITS
systems to exchange data and information with each other.
June 27, 2001
58.
Puget Sound Regional ITS Architecture
7.3
The National Transportation Communications for ITS Protocol Family
The National Transportation Communications for ITS Protocol (NTCIP) standards committee is a
specialized SDO focus group comprised of AASHTO, ITE and NEMA delegates. This joint committee
provides for the development of a family of ITS standards that apply to the majority of interfaces
between traffic and transit management systems and devices. These standards are referred to in
shorthand as the NTCIP for traffic systems, and the Transit Communications Interface Protocols, or
TCIP for transit systems.
7.3.1 NTCIP
The NTCIP standards provide a suite of communications protocols and data definitions for two different
types of traffic management ITS communications. The first type is between two transportation
management centers (or systems)—this is called center-to-center (C2C). The second type is the link
from a transportation management system or center to a field device like a traffic signal or dynamic
message sign—this second type is called center to field (C2F). Additional information on NTCIP
standards is found at the following website - http://www.ntcip.org/index.html.
NTCIP provides two alternative protocol choices for center-to-center communications. One is Data
Exchange Between Systems (DATEX) and the other is based on the widely used Internet standard
Common Object Request Broker Architecture (CORBA). These two different protocols were found
necessary to meet the variety of requirements for inter-system data exchanges. It is feasible to use both
protocols in t he same network, with some centers acting as a bridge, or translator, between the two. Each
C2C connection will likely have different functional and policy related requirements which will
determine what type(s) of protocols are necessary. Factors that influence DATEX or CORBA protocol
choices include:
•
•
•
•
•
Characteristics of systems to be linked
Functions to be supported
System life cycle considerations
System performance
Communications infrastructure and demand
Other issues that agencies must address when developing C2C communications links include levels of
security/access, location identification conventions, exchange and sharing of data for information and/or
control purposes, and when sharing control--device use conflict resolution. These issues should all be
resolved through operational agreements between participating agencies. Additional dialogue among the
transportation management center operators and managers will be required before a choice is made for
the region. This selection of a regional C2C standard will be critical to the deployment of the Regional
Traffic Control market package.
For C2F applications, NTCIP offers the potential for interchangeability and interoperability of
equipment from different suppliers on the same system. This family of standards provides both the
vocabulary (called objects) and the rules for communicating (called protocols) necessary to allow
electronic traffic control equipment from different manufacturers and transportation management centers
June 27, 2001
59.
Puget Sound Regional ITS Architecture
to operate with each other as a system.31 Key C2F standards that should be adopted and used by
regional jurisdictions are shown in Table 7-2 below.
Table 7-2: NTCIP Center to Field Standards
NTCIP
STANDARD
NTCIP 1201
NTCIP 1202
NTCIP 1203
NTCIP 1204
NTCIP 1205
NAME
DESCRIPTION
Global Object Definitions
Specification for those o bjects that are likely to be used
in and for multiple device types
Specifications for objects that are specific to actuated
signal controllers and definitions of standardized object
groups that can be used for conformance statements.
Defines data that is specific to dynamic message signs
including all types of signs that can change state, such
as blank- out signs, changeable signs, and variable
signs
Definitions of objects that are specific to
environmental sensor stations (ESS) and object groups,
which can be used for conformance statements.
Object Definitions for
Actuated Traffic Signal
Controller Units
Object
Definitions for
Dynamic Message
Signs
Object Definitions for
Environmental Sensor
Stations & Roadside
Weather Information
System
Data Dictionary for
Closed Circuit Television
(CCTV)
NTCIP 1206
Data Collection and
Monitoring Devices
NTCIP 1207
Ramp Meter Controller
Objects
Object Definitions for
Video Switches
NTCIP 1208
31
A database for Closed Circuit Television systems. The
format of the database is identical to other NTCIP
devices and uses ASN. 1 representation. Targeted
devices include cameras, lenses, video switches, and
positioning controls for aiming and identification, such
as videotext overlays.
Specifies object definitions that may be supported by
data collection and monitoring devices, such as
roadway loop detectors.
Specifications for objects that are specific to ramp
metering controller operations.
Deals with the data needed to control a video switch
enabling multiple monitors to view multiple video
feeds.
US Department of Transportation, Intelligent Transportation Systems, Standards Fact Sheet, October 1999,
AASHTO/ITE/NEMA TS 3.1, National Transportation Communications for ITS Protocol (NTCIP) Overview
June 27, 2001
60.
Puget Sound Regional ITS Architecture
NTCIP
STANDARD
NTCIP 1209
NTCIP 1210
NTCIP 1211
NAME
DESCRIPTION
Transportation System
Sensor Objects
Object definitions that are specific to and guide the
data exchange content between advanced sensors and
other devices in an NTCIP network. Advanced sensors
include video- based detection sensors, inductive loop
detectors, sonic detectors, infrared detectors, and
microwave/ radar detectors
Objects for Field
This standard will define the objects necessary to
Management Stations
manage a field master.
Objects for Signal Control Object definitions for the application of signal
Priority
prioritization by transit vehicles, rail, emergency
vehicles and trucks.
The WSDOT has already deployed an NTCIP compliant DMS sign and is investigating the use other
NTCIP standards for environmental sensor stations (ESS) and regional traffic management data
exchange.
7.3.2 TCIP
TCIP is a suite of data interface standards for the transit industry ( http://www.tcip.org/). This suite of
standards includes the wide range of transit ITS applications. A summary of the TCIP standards is found
in the Table 7 -3. This effort began after the three regional standards discussed below were already
adopted.
Table 7-3: TCIP Standards
TCIP
STANDARD NAME
1400
Framework Document
DESCRIPTION
Defines how the various TCIP standards work
together
1401
Common Public Transportation Defines those data elements and data frames that are
(CPT) Business Area Standard generic to multiple TCIP Business areas
1402
Incident Management (IM)
Business Area Standard
Defines the data elements and messages used for
exchanging information on incident management
operations
1403
Passenger Information (PI)
Business Area Standard
Defines the data elements and messages used for
passenger information data exchange
June 27, 2001
61.
Puget Sound Regional ITS Architecture
TCIP
STANDARD NAME
1404
Scheduling/Runcutting (SCH)
Business Area Standard
DESCRIPTION
Defines the data elements and messages used for
exchanging information about transit schedules and
runcutting information
1405
Spatial Representation (SP)
Business Area Standard
Defines the data elements and messages used for
exchange of location and spatial concepts
1406
Onboard (OB) Business Area
Standard
Defines the data elements and messages used for
exchanging information about devices and operations
aboard the transit vehicle
1407
Control Center (CC) Business
Area Standard
Defines the data elements and messages used for
exchanges between control centers
1408
Fare Collection (FC) Business
Area Standard
Defines the data elements and messages used for
exchanging information about fare collection
operations
Three regional standards for transit ITS applications have already been accepted by the regional
transportation agencies for implementation. They include:
•
Electronic Fare Collection: The transit agencies in the region are participating in the
selection and deployment of a common electronic fare collection system using a common
fare card. The use of this common fare medium and related business rules will enable
interoperability for transit electronic fare collection within the region.
•
Transit Traveler Information: The Regional Automated Trip Planning (RATP) project is
the beginning of a regional transit information system and provides a common format for
the exchange of information.
•
Transit Signal Priority: A common set of equipment for both roadside and bus TSP
equipment has been selected for King and Snohomish County. However, another approach
has been selected for Pierce and Kitsap County.
Both the regional fare coordination project and the RATP will provide common regional standards for
the exchange of fare and traveler information in the region for the middle term. TCIP standards should
be considered in the future when these two applications are updated. When other transit ITS applications
are considered for implementation, the emerging TCIP standards should be considered to ensure
interoperability among the regional transit agencies.
The TSP standard for vehicle to roadside communication should be revisited in the middle term once the
national standard for dedicated short-range communications (DSRC) is established. The Regional
Transit Technology Group (RTTG) will continue to serve as regional forum to facilitate the use of
common standards within the region.
June 27, 2001
62.
Puget Sound Regional ITS Architecture
7.4
Puget Sound ITS Backbone
The Puget Sound Regional Integration Strategy calls for the use of the ITS Backbone as a means to
speed the sharing of real -time transportation information among jurisdictions in the region. The
Backbone is based upon a solid foundation of information technology and research at the University of
Washington. It depends upon a set of paradigms and protocols called Self-Describing Data (SDD).
Information on the backbone, and the software required to implement SDD can be obtained free from
the following website - http://www.its.washington.edu/bbone/.
June 27, 2001
63.
Puget Sound Regional ITS Architecture
8
SEQUENCE OF PROJECTS REQUIRED FOR IMPLEMENTATION
There are several regional projects that will lay the foundation for other planned and future regional ITS
applications. Specific projects that will need to be implemented to support data and control sharing
amongst jurisdictions and agencies are:
•
•
•
•
ITS Backbone (Section 8.1)
Regional Center-to-Center Standard (Section 8.2)
Remote Multi-Modal Traveler Information Center (Section 8.3)
Communications Network (Section 8.4)
The significance of sequencing these projects as more near-term is described in the following sections.
8.1
ITS Backbone
The ITS Backbone is a near -term solution to regional data sharing. This will support various regionally
implemented market packages such as Regional Traffic Control, Incident Management, and MultiModal Coordination. This will be a benefit to many types of jurisdictional relationships. It will provide a
common place for jurisdictions to subscribe to other agencies traffic information, transit location
information, and any other real-time information that will support coordinated efforts. This information
will be used to implement incident response plans, and to provide traveler information. The Backbone
will serve not only transportation and transit management agencies, but will also provide a source for
ISPs to gather and disseminate information to the general public.
8.2
Determination of Regional Center-to-Center Standard
Critical to the deployment of an integr ated regional ITS system is the development of electronic
interfaces for the full exchange of information and future sharing of ITS devices among the
transportation management systems operated by local, county, state and transit organizations. The
acceptance of a standard interface would ease this deployment effort.
Center-to-center relationships are vital in the support of several market packages that will be
implemented regionally. For example, a fully active Regional Traffic Control function will allow for the
ability to control another jurisdictions field devices. This type of sharing of control is best supported
with a center-to-center connection. As center-to-center connections will need to be made between many
jurisdictions, it is important to determine a regionally “standard” protocol to support this concept.
8.3
Expansion of RMTIC
The development of an expanded site for traveler information is crucial in providing an efficient source
for pre-trip information. Smart Trek currently provides this function. Many other market packages will
use this project as a portal to get information on traffic conditions, construction notices, etc. out to the
general public. Since this will be a regional approach, it will create a single source for information
dissemination to the general public.
June 27, 2001
64.
Puget Sound Regional ITS Architecture
8.4
Communications Network
In order to support the majority of market packages that will be deployed regionally in the future, local
and regional communications networks will need to be implemented, and upgraded. Market packages
such as Incident Management, Multi-Modal coordination, and Regional Traffic Control require a range
of field devices to support their concepts. The ability to retrieve, process, control, and share devices and
data from the field is dependent on the communications network capacity and availability.
June 27, 2001
65.
APPENDIX A
Regional Market Package Databases
Table A-1: Regional Traffic Control
Data
Command
Request
Status
Maintenance
Existing
To
Video
Operations
Control Sharing
Info Sharing
Coordination
Cooperation
Consultation
Existing
From
Algona
King County
Existing
Arlington
Snohomish County
Existing
Auburn
Kent
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Auburn
WSDOT NW
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
Bellevue
Issaquah
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Bellevue
King County
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Bellevue
Seattle
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Bellevue
Redmond
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Bellevue
WSDOT NW
Planned
Planned
Potential
Existing
Planned
Potential
Planned
Planned
Bellevue
Kirkland
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Bothell
Snohomish County
Bothell
WSDOT NW
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Bremerton
Kitsap County
Existing
Existing
Existing
Bremerton
Silverdale
Existing
Existing
Existing
Bremerton
WSDOT Olympic
Burien
King County
Existing
Covington
King County
Existing
Des Moines
WSDOT NW
Edgewood
Pierce County
Existing
Edmonds
Lynnwood
Existing
Edmonds
Everett
Planned
Existing
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
Snohomish County
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Everett
WSDOT NW
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
Federal Way
WSDOT NW
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
Federal Way
King County
Issaquah
Bellevue
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
June 28, 2001
Existing
A-1 Page 1 of 6
Control Sharing
Video
Data
Command
Request
Status
Planned
Potential
Potential
Planned
Planned
Planned
Potential
Potential
Planned
Planned
Planned
Planned
Auburn
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Kent
King County
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Kent
Renton
Existing
Existing
Potential
Planned
Existing
Potential
Existing
Existing
Kent
Tukwila
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Kent
WSDOT NW
Planned
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
King County
Algona
Existing
King County
Bellevue
Planned
Planned
Potential
Planned
Planned
King County
Burien
Existing
Existing
Existing
King County
Covington
Existing
Existing
Existing
King County
Federal Way
Existing
Existing
Existing
King County
SeaTac
Existing
Existing
Existing
King County
Kenmore
Existing
Existing
Existing
King County
Issaquah
Planned
Planned
Potential
Existing
Planned
Planned
Potential
Planned
Planned
King County
Kirkland
Planned
Planned
Potential
Existing
Planned
Planned
Potential
Planned
Planned
King County
Pacific
King County
Pierce County
Potential
King County
Redmond
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
King County
Renton
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
King County
Sammamish
Existing
King County
WSDOT NW
Planned
Planned
Planned
Potential
Planned
Planned
King County
Woodinville
Existing
King County
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Planned
Planned
Potential
Planned
Planned
Issaquah
King County
Issaquah
WSDOT NW
Planned
Kenmore
King County
Existing
Kent
Existing
Planned
Planned
Existing
Existing
Potential
Existing
Planned
Planned
Potential
Tukwila
Potential
Potential
Potential
King County
Snohomish County
Potential
Potential
Potential
King County
Shoreline
Existing
King County
Seattle
Planned
June 28, 2001
Existing
Potential
Existing
Existing
Planned
Potential
Existing
Existing
Existing
Existing
Planned
Maintenance
Info Sharing
Planned
To
Operations
Coordination
Potential
Cooperation
Planned
Consultation
Planned
From
Existing
A-1 Page 2 of 6
Control Sharing
Video
Data
Command
Request
Status
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
King County
Kent
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Kirkland
WSDOT NW
Existing
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Kirkland
King County
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Kirkland
Seattle
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Kirkland
Redmond
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Kirkland
Bellevue
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Kitsap County
Bremerton
Existing
Lakewood
Pierce County
Existing
Lakewood
University Place
Planned
Planned
Existing
Planned
Planned
Existing
Planned
Planned
Lakewood
WSDOT Olympic
Lynnwood
Edmonds
Lynnwood
WSDOT NW
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Lynnwood
Snohomish County
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Lynnwood
Mountlake Terrace
Maple Valley
WSDOT NW
Marysville
Snohomish County
Mercer Island
WSDOT NW
Mill Creek
Snohomish County
Existing
Mountlake Terrace
Lynnwood
Existing
Mountlake Terrace
WSDOT NW
Pacific
King County
Existing
Pierce County
Edgewood
Existing
Pierce County
WSDOT Olympic
Pierce County
University Place
Pierce County
Tacoma
Potential
Potential
Pierce County
King County
Potential
Potential
Pierce County
Lakewood
June 28, 2001
Existing
Maintenance
Info Sharing
Snohomish County
Operations
Coordination
King County
Cooperation
To
Consultation
From
Potential
Potential
Existing
Existing
Existing
Existing
Existing
Existing
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
Planned
Planned
Potential
Planned
Planned
Existing
Existing
Existing
Planned
Existing
Existing
Existing
Planned
Existing
Existing
Potential
Potential
A-1 Page 3 of 6
Potential
Potential
Potential
Redmond
Kirkland
Planned
Planned
Potential
Redmond
Bellevue
Planned
Planned
Planned
Redmond
WSDOT NW
Planned
Planned
Renton
Kent
Existing
Renton
King County
Renton
Seattle
Renton
Status
King County
Request
Redmond
Command
Potential
Data
King County
Video
Pierce County
Maintenance
To
Operations
Control Sharing
Info Sharing
Coordination
Cooperation
Consultation
From
Potential
Potential
Potential
Potential
Potential
Potential
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Potential
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
Existing
Potential
Planned
Existing
Potential
Existing
Existing
Planned
Planned
Planned
Planned
Planned
Potential
Planned
Planned
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Tukwila
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Renton
WSDOT NW
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
Sammamish
King County
SeaTac
WSDOT NW
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
SeaTac
King County
SeaTac Airport
WSDOT NW
Planned
Planned
Planned
Planned
Planned
Planned
Seattle
WSDOT NW
Planned
Planned
Potential
Existing
Planned
Potential
Planned
Planned
Seattle
King County
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Seattle
Kirkland
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Seattle
Renton
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Seattle
Tukwila
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Seattle
Bellevue
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Seattle
Shoreline
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Shoreline
King County
Shoreline
Seattle
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Silverdale
Bremerton
Snohomish County
Everett
Planned
Planned
Planned
Planned
Potential
Planned
Planned
Snohomish County
Stanwood
Snohomish County
WSDOT NW
Planned
Planned
Potential
Planned
Planned
Snohomish County
Marysville
June 28, 2001
Planned
Existing
Existing
Existing
Planned
Existing
Existing
Existing
Existing
Planned
Existing
Planned
Existing
Potential
Existing
Existing
A-1 Page 4 of 6
Video
Data
Command
Request
Status
Control Sharing
Potential
Maintenance
Info Sharing
Potential
Operations
Coordination
Cooperation
Consultation
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
From
To
Snohomish County
King County
Snohomish County
Bothell
Existing
Snohomish County
Arlington
Existing
Snohomish County
King County
Snohomish County
Mill Creek
Snohomish County
Lynnwood
Stanwood
Snohomish County
Existing
Tacoma
WSDOT Olympic
Existing
Tacoma
Pierce County
Tacoma Narrows Bridge
WSDOT Olympic
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Tukwila
WSDOT NW
Planned
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
Tukwila
King County
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Tukwila
Seattle
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Tukwila
Renton
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Tukwila
Kent
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
University Place
Lakewood
Planned
Planned
Existing
Planned
Planned
Potential
Planned
Planned
University Place
Pierce County
University Place
WSDOT Olympic
Woodinville
King County
Woodinville
WSDOT NW
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Everett
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Tukwila
Planned
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
WSDOT Olympic
Existing
Existing
Existing
Existing
Existing
Existing
Existing
Existing
Existing
WSDOT NW
Edmonds
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Seattle
Planned
Planned
Potential
Existing
Planned
Potential
Planned
Planned
WSDOT NW
Lynnwood
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
WSDOT NW
Mountlake Terrace
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
SeaTac Airport
Planned
Planned
Planned
Planned
Planned
Planned
June 28, 2001
Potential
Potential
Existing
Existing
Existing
Existing
Potential
Existing
Existing
Existing
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Existing
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Potential
Potential
Existing
Potential
Potential
Existing
A-1 Page 5 of 6
Control Sharing
Video
Data
Command
Request
Status
Planned
Potential
Planned
Planned
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Federal Way
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
Des Moines
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Woodinville
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Bellevue
Planned
Planned
Potential
Existing
Planned
Potential
Planned
Planned
WSDOT NW
SeaTac
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Issaquah
Planned
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Kent
Planned
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Kirkland
Existing
Existing
Potential
Potential
Potential
Potential
Potential
Potential
Potential
WSDOT NW
Snohomish County
Planned
Planned
Potential
Planned
Planned
Potential
Planned
Planned
WSDOT NW
Maple Valley
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Mercer Island
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Redmond
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Renton
Planned
Planned
Planned
Potential
Planned
Potential
Planned
Planned
WSDOT NW
Auburn
Planned
Planned
Potential
Potential
Planned
Potential
Planned
Planned
WSDOT Olympic
Pierce County
Planned
Planned
Planned
Planned
Potential
Planned
Planned
WSDOT Olympic
WSDOT NW
Existing
Existing
Existing
Existing
Existing
Existing
Existing
WSDOT Olympic
University Place
WSDOT Olympic
Tacoma
WSDOT Olympic
Lakewood
Potential
WSDOT Olympic
Bremerton
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
WSDOT Olympic
Tacoma Narrows Bridge
Existing
Planned
Planned
Planned
Planned
Planned
Planned
Planned
WSDOT NW
King County
WSDOT NW
WSDOT NW
June 28, 2001
Planned
Planned
Planned
Existing
Existing
Maintenance
Info Sharing
Potential
Bothell
Operations
Coordination
Potential
WSDOT NW
Cooperation
Planned
To
Consultation
Planned
From
Existing
Potential
Existing
Existing
Existing
Potential
Planned
Potential
Planned
Planned
Potential
Planned
Planned
Potential
A-1 Page 6 of 6
Table A-2: Regional Parking Management
Request
Status
Potential
Community Transit
ITS Data Backbone
Potential
Potential
Potential
Potential
Potential
Community Transit
Lynnwood
Planned
Planned
Potential
Planned
Planned
Planned
Community Transit
WSDOT
Potential
Potential
Potential
Potential
Everett Transit
ITS Data Backbone
Potential
Potential
Everett Transit
WSDOT
Potential
Potential
ITS Data Backbone
King County
Potential
Potential
Potential
Potential
Potential
ITS Data Backbone
Sound Transit
Potential
Potential
Potential
Potential
Potential
ITS Data Backbone
Smart Trek
Potential
Potential
Potential
Potential
Potential
ITS Data Backbone
Seattle
Potential
Potential
Potential
Potential
Potential
ITS Data Backbone
Pierce Transit
Potential
Potential
Potential
Potential
Potential
ITS Data Backbone
SeaTac Airport
Potential
Potential
Potential
ITS Data Backbone
Kitsap Transit
Potential
Potential
Potential
Potential
Potential
ITS Data Backbone
Everett Transit
Potential
Potential
Potential
Potential
Potential
ITS Data Backbone
Community Transit
Potential
Potential
Potential
Potential
Potential
ITS Data Backbone
Amtrak
Potential
Potential
Potential
Potential
Potential
ITS Data Backbone
Lynnwood
Potential
Potential
Potential
Potential
Potential
King County Metro
ITS Data Backbone
Potential
Potential
Potential
Potential
Potential
King County Metro
WSDOT
Potential
Potential
Potential
Potential
Potential
Potential
Kitsap Transit
WSDOT
Potential
Potential
Potential
Potential
Potential
Potential
Kitsap Transit
ITS Data Backbone
Potential
Potential
Potential
Potential
Potential
Lynnwood
ITS Data Backbone
Potential
Potential
Potential
Potential
Potential
Lynnwood
Community Transit
Planned
Planned
Potential
Planned
Planned
Planned
Other Seattle Venue
Seattle
Planned
Planned
Potential
Planned
Planned
Planned
Parking Operator
Seattle
Potential
Potential
Potential
Potential
Potential
Pierce Transit
ITS Data Backbone
Potential
Potential
Potential
Potential
Potential
June 28, 2001
Command
Potential
Data
Potential
Video
Potential
Maintenance
Potential
Operations
Info Sharing
Control Sharing
Coordination
ITS Data Backbone
Cooperation
To
Amtrak
Consultation
From
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
A-2 Page 1 of 2
Seattle
ITS Data Backbone
Existing
Existing
Seattle
Other Seattle Venue
Planned
Planned
Seattle
Parking Operator
Potential
Seattle
Seattle Center
Seattle Center
Smart Trek
Potential
Potential
Status
Potential
Potential
Request
Potential
Command
ITS Data Backbone
Data
SeaTac Airport
Video
Potential
Maintenance
Potential
Operations
Info Sharing
WSDOT
Control Sharing
Coordination
Pierce Transit
Cooperation
To
Consultation
From
Potential
Potential
Potential
Existing
Existing
Existing
Planned
Planned
Planned
Potential
Potential
Potential
Potential
Planned
Planned
Planned
Planned
Planned
Seattle
Planned
Planned
Planned
Planned
Planned
ITS Data Backbone
Potential
Potential
Potential
Potential
Potential
Sound Transit
WSDOT
Potential
Potential
Sound Transit
ITS Data Backbone
Potential
Potential
WSDOT
Community Transit
Potential
Potential
Potential
Potential
Potential
Potential
WSDOT
Everett Transit
Potential
Potential
Potential
Potential
Potential
Potential
WSDOT
King County Metro
Potential
Potential
Potential
Potential
Potential
Potential
WSDOT
Kitsap Transit
Potential
Potential
Potential
Potential
Potential
Potential
WSDOT
Pierce Transit
Potential
Potential
Potential
Potential
Potential
Potential
WSDOT
Sound Transit
Potential
Potential
Potential
Potential
Potential
Potential
June 28, 2001
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
A-2 Page 2 of 2
Table A-3: Multi-Modal Coordination
Request
Status
Planned
Planned
Community Transit
City of Edmonds
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Community Transit
City of Everett
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Community Transit
Snohomish County
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Community Transit
City of Lynwood
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Everett Transit
City of Everett
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Everett Transit
Snohomish County
Planned
Planned
Planned
Planned
Planned
Planned
Planned
King County Metro
City of Redmond
Planned
Planned
Planned
Planned
Planned
Planned
Planned
King County Metro
City of Seattle
Existing
Existing
Existing
Existing
Existing
Existing
Existing
King County Metro
City of Kirkland
Planned
Planned
Planned
Planned
Planned
Planned
Planned
King County Metro
City of Renton
Planned
Planned
Planned
Planned
Planned
Planned
Planned
King County Metro
City of Bellevue
Planned
Planned
Planned
Planned
Planned
Planned
Planned
King County Metro
King County
Existing
Existing
Existing
Existing
Existing
Existing
Existing
King County Metro
City of Auburn
Planned
Planned
Planned
Planned
Planned
Planned
Planned
King County Metro
City of Federal Way
Planned
Planned
Planned
Planned
Planned
Planned
Planned
King County Metro
City of Sea-Tac
Planned
Planned
Planned
Planned
Planned
Planned
Planned
King County Metro
City of Tukwila
Planned
Planned
Planned
Planned
Planned
Planned
Planned
King County Metro
WSDOT
Existing
Existing
Existing
Existing
Existing
Existing
Existing
King County Metro
City of Shoreline
Planned
Planned
Planned
Planned
Planned
Planned
Planned
King County Metro
City of Kent
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Kitsap Transit
City of Bremerton
Existing
Existing
Existing
Existing
Existing
Existing
Existing
June 28, 2001
Command
Planned
Data
Planned
Video
Planned
Maintenance
Info Sharing
Planned
Operations
Coordination
Control Sharing
Cooperation
City of Mountlake Terrace Planned
To
Consultation
Community Transit
From
A-3 Page 1 of 3
Request
Status
Planned
Planned
Planned
Planned
Pierce Transit
City of Lakewood
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Pierce Transit
City of Puyallup
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Pierce Transit
City of Gig Harbor
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Pierce Transit
City of University Place
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Pierce Transit
Pierce County
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Pierce Transit
WSDOT
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Sound Transit (LINK)
City of Seattle
Existing
Existing
Existing
Planned
Planned
Planned
Planned
Sound Transit (LINK)
City of Tukwila
Existing
Existing
Existing
Planned
Planned
Planned
Planned
Sound Transit (LINK)
City of Tacoma
Existing
Existing
Existing
Planned
Planned
Planned
Planned
Sound Transit (Sounder)
City of Seattle
Existing
Existing
Existing
Existing
Existing
Existing
Existing
Sound Transit (Sounder)
Everett Transit
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Sound Transit (Sounder)
WSDOT
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Sound Transit (Sounder)
City of Everett
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Sound Transit (Sounder)
City of Edmonds
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Sound Transit (Sounder)
Pierce County
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Sound Transit (Sounder)
King County
Existing
Existing
Existing
Existing
Existing
Existing
Existing
Sound Transit (Sounder)
City of Tacoma
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Sound Transit (Sounder)
City of Puyallup
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Sound Transit (Sounder)
City of Sumner
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Sound Transit (Sounder)
City of Auburn
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Sound Transit (Sounder)
City of Kent
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Sound Transit (Sounder)
City of Renton
Planned
Planned
Planned
Planned
Planned
Planned
Planned
June 28, 2001
Command
Planned
Data
Planned
Video
Info Sharing
Planned
Maintenance
Coordination
City of Tacoma
To
Operations
Cooperation
Control Sharing
Consultation
Pierce Transit
From
A-3 Page 2 of 3
Status
Request
Command
Data
Video
Maintenance
Operations
Cooperation
Coordination
Info Sharing
Existing
Control Sharing
Consultation
Existing
A-3 Page 3 of 3
June 28, 2001
Existing
Existing
Existing
Existing
King County Metro
WSDOT
To
From
Table A-4: Transit Fare Management
Planned
Community Transit
Everett Transit
Existing
Existing
Existing
Planned
Planned
Community Transit
Kitsap Transit
Existing
Existing
Existing
Planned
Planned
Community Transit
Sound Transit (LINK)
Existing
Existing
Existing
Planned
Planned
Community Transit
Sound Transit (Regional
Express)
Existing
Existing
Existing
Planned
Planned
Community Transit
Sound Transit (Sounder)
Existing
Existing
Existing
Planned
Planned
Community Transit
Washington State Ferries
Existing
Existing
Existing
Planned
Planned
Community Transit
King County Metro
Existing
Existing
Existing
Planned
Planned
Everett Transit
King County Metro
Existing
Existing
Existing
Planned
Planned
Everett Transit
Community Transit
Existing
Existing
Existing
Planned
Planned
Everett Transit
Kitsap Transit
Existing
Existing
Existing
Planned
Planned
Everett Transit
Pierce Transit
Existing
Existing
Existing
Planned
Planned
Everett Transit
Sound Transit (LINK)
Existing
Existing
Existing
Planned
Planned
Everett Transit
Sound Transit (Regional
Express)
Existing
Existing
Existing
Planned
Planned
Everett Transit
Sound Transit (Sounder)
Existing
Existing
Existing
Planned
Planned
Everett Transit
Washington State Ferries
Existing
Existing
Existing
Planned
Planned
King County Metro
Everett Transit
Existing
Existing
Existing
Planned
Planned
King County Metro
Kitsap Transit
Existing
Existing
Existing
Planned
Planned
King County Metro
Pierce Transit
Existing
Existing
Existing
Planned
Planned
King County Metro
Sound Transit (LINK)
Existing
Existing
Existing
Planned
Planned
King County Metro
Sound Transit (Regional
Express)
Existing
Existing
Existing
Planned
King County Metro
Sound Transit (Sounder)
Existing
Existing
Existing
Planned
Planned
King County Metro
Washington State Ferries
Existing
Existing
Existing
Planned
Planned
June 28, 2001
Status
Planned
Request
Existing
Command
Existing
Data
Info Sharing
Existing
Video
Coordination
Pierce Transit
Maintenance
Cooperation
Community Transit
Operations
To
Consultation
Control Sharing
From
A-4 Page 1 of 3
Kitsap Transit
Everett Transit
Existing
Existing
Existing
Planned
Kitsap Transit
Sound Transit (Sounder)
Existing
Existing
Existing
Planned
Planned
Kitsap Transit
Sound Transit (LINK)
Existing
Existing
Existing
Planned
Planned
Kitsap Transit
Pierce Transit
Existing
Existing
Existing
Planned
Planned
Kitsap Transit
King County Metro
Existing
Existing
Existing
Planned
Planned
Kitsap Transit
Community Transit
Existing
Existing
Existing
Planned
Planned
Kitsap Transit
Washington State Ferries
Existing
Existing
Existing
Planned
Planned
Kitsap Transit
Sound Transit (Regional
Express)
Existing
Existing
Existing
Planned
Planned
Pierce Transit
Sound Transit (Sounder)
Existing
Existing
Existing
Planned
Planned
Pierce Transit
Sound Transit (LINK)
Existing
Existing
Existing
Planned
Planned
Pierce Transit
Kitsap Transit
Existing
Existing
Existing
Planned
Planned
Pierce Transit
Sound Transit (Regional
Express)
Existing
Existing
Existing
Planned
Planned
Pierce Transit
Community Transit
Existing
Existing
Existing
Planned
Planned
Pierce Transit
Washington State Ferries
Existing
Existing
Existing
Planned
Planned
Pierce Transit
Everett Transit
Existing
Existing
Existing
Planned
Planned
Pierce Transit
King County Metro
Existing
Existing
Existing
Planned
Planned
Sound Transit (LINK)
Washington State Ferries
Existing
Existing
Existing
Planned
Planned
Sound Transit (LINK)
Community Transit
Existing
Existing
Existing
Planned
Planned
Sound Transit (LINK)
Everett Transit
Existing
Existing
Existing
Planned
Planned
Sound Transit (LINK)
King County Metro
Existing
Existing
Existing
Planned
Planned
Sound Transit (LINK)
Kitsap Transit
Existing
Existing
Existing
Planned
Planned
Sound Transit (LINK)
Pierce Transit
Existing
Existing
Existing
Planned
Planned
Sound Transit (LINK)
Sound Transit (Sounder)
Existing
Existing
Existing
Planned
Planned
Sound Transit (LINK)
Sound Transit (Regional
Express)
Existing
Existing
Existing
Planned
Planned
June 28, 2001
Status
Planned
Request
Existing
Command
Existing
Data
Info Sharing
Existing
Video
Coordination
Community Transit
Maintenance
Cooperation
King County Metro
Operations
To
Consultation
Control Sharing
From
A-4 Page 2 of 3
Planned
Sound Transit (Regional
Express)
Everett Transit
Existing
Existing
Existing
Planned
Planned
Sound Transit (Regional
Express)
King County Metro
Existing
Existing
Existing
Planned
Planned
Sound Transit (Regional
Express)
Kitsap Transit
Existing
Existing
Existing
Planned
Planned
Sound Transit (Regional
Express)
Pierce Transit
Existing
Existing
Existing
Planned
Planned
Sound Transit (Regional
Express)
Sound Transit (LINK)
Existing
Existing
Existing
Planned
Planned
Sound Transit (Regional
Express)
Sound Transit (Sounder)
Existing
Existing
Existing
Planned
Planned
Sound Transit (Sounder)
Sound Transit (LINK)
Existing
Existing
Existing
Planned
Planned
Sound Transit (Sounder)
Community Transit
Existing
Existing
Existing
Planned
Planned
Sound Transit (Sounder)
Everett Transit
Existing
Existing
Existing
Planned
Planned
Sound Transit (Sounder)
Pierce Transit
Existing
Existing
Existing
Planned
Planned
Sound Transit (Sounder)
Sound Transit (Regional
Express)
Existing
Existing
Existing
Planned
Planned
Sound Transit (Sounder)
Washington State Ferries
Existing
Existing
Existing
Planned
Planned
Sound Transit (Sounder)
King County Metro
Existing
Existing
Existing
Planned
Planned
Washington State Ferries
Sound Transit (Regional
Express)
Existing
Existing
Existing
Planned
Planned
Washington State Ferries
Kitsap Transit
Existing
Existing
Existing
Planned
Planned
Washington State Ferries
Pierce Transit
Existing
Existing
Existing
Planned
Planned
Washington State Ferries
Community Transit
Existing
Existing
Existing
Planned
Planned
Washington State Ferries
Everett Transit
Existing
Existing
Existing
Planned
Planned
Washington State Ferries
King County Metro
Existing
Existing
Existing
Planned
Planned
Washington State Ferries
Sound Transit (Sounder)
Existing
Existing
Existing
Planned
Planned
Washington State Ferries
Sound Transit (LINK)
Existing
Existing
Existing
Planned
Planned
June 28, 2001
Status
Planned
Request
Existing
Command
Existing
Data
Info Sharing
Existing
Video
Coordination
Community Transit
Maintenance
Cooperation
Sound Transit (Regional
Express)
Operations
To
Consultation
Control Sharing
From
A-4 Page 3 of 3
Table A-5: Transit Traveler Information
Info Sharing
Data
Command
Request
Status
Existing
Existing
Existing
Planned
Planned
Planned
Planned
Planned
Community Transit
Everett Transit
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Community Transit
Pierce Transit
Existing
Existing
Existing
Planned
Planned
Planned
Planned
Planned
Everett Transit
Community Transit
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Everett Transit
King County Metro
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Everett Transit
Pierce Transit
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Planned
King County Metro
Community Transit
Existing
Existing
Existing
Planned
Planned
Planned
Planned
Planned
King County Metro
Everett Transit
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Planned
King County Metro
Pierce Transit
Existing
Existing
Existing
Planned
Planned
Planned
Planned
Planned
Pierce Transit
Community Transit
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Pierce Transit
Everett Transit
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Pierce Transit
King County Metro
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Planned
Pierce Transit
Sound Transit (Regional
Express)
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Pierce Transit
Sound Transit (LINK)
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Pierce Transit
Sound Transit (Sounder)
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Sound Transit (LINK)
Community Transit
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Sound Transit (LINK)
King County Metro
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Sound Transit (LINK)
Pierce Transit
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Sound Transit (LINK)
Sound Transit (Regional
Express)
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Sound Transit (LINK)
Sound Transit (Sounder)
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Sound Transit (Regional
Express)
Community Transit
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Sound Transit (Regional
Express)
Everett Transit
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Sound Transit (Regional
Express)
King County Metro
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
June 28, 2001
Video
Coordination
King County Metro
Maintenance
Cooperation
Community Transit
Operations
To
Consultation
Control Sharing
From
A-5 Page 1 of 2
Info Sharing
Data
Command
Request
Status
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Sound Transit (Regional
Express)
Sound Transit (LINK)
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Sound Transit (Regional
Express)
Sound Transit (Sounder)
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Potential
Washington State Ferries
Kingston Ferry Terminal
Existing
Existing
Existing
Existing
Existing
Existing
Washington State Ferries
Bainbridge Ferry Terminal
Existing
Existing
Existing
Existing
Existing
Existing
June 28, 2001
Video
Coordination
Pierce Transit
Maintenance
Cooperation
Sound Transit (Regional
Express)
Operations
To
Consultation
Control Sharing
From
A-5 Page 2 of 2
APPENDIX B
ITS Architecture Diagrams
traffic information coordination
Other Emissions
Management
TRANSIT MANAGEMENT
Washington State Ferries
Transit Center Tracking
and Dispatch
widearea statistical
pollution information
transit and fare
schedultes,
transit vehicle
location data,
transit vehicle
schedule adherence
TRAFFIC MANAGEMENT
WSDOT
Olympic Region
Traffic Maintenance
Other Emergency
Management
TMC Road Weather
Monitoring
WSDOT Incident
Response Team
& Other
Emergency
Management
Centers
Traffic Data Collection
Collect Traffic
Surveillance
Roadway Environmental
Monitoring
Roadway Signal Control
Roadway Freeway
Control
Roadway Traffic
Info
Dissemination
Roadway Incident
Detection
Roadway Basic
Surveillance
Other Traffic
Management
Cities and
Counties within
and outside
Region
environmental conditions,
incident data,
traffic flow,
traffic images,
fault reports,
freeway control status,
HRI status,
signal control status,
roadway information
system status
incident Information,
incident information
request, resource
deployment status,
current network conditions
(traffic images)
Collect Traffic
Surveillance
TMC Freeway
Management
TMC Traffic Info
Dissemination
TMC Incident Dispatch
Coord/Communication
maintenance resource request,
closure conditions, traffic
equipment status
TMC Signal Control
HRI Traffic Management
(Future)
TMC Regional Traffic
Control
toll demand
management
response,
probe data
Remote Interactive
Information Reception
traveler
request
Basic Information
Broadcast
Remote Basic
Information Reception
Roadway Basic
Surveillance
Roadside Data Collection
ITS Backbone
(Other ISP)
Roadway Reversible
Lanes
HRI Traffic Management
(Future)
Rail Operations
Corrdination
Information Service Provider
WSDOT MIS
Roadway Incident
Detection
Roadside Signal Priority
TMC Regional Traffic
Control
broadcast
information,
traveler
information
Roadway Traffic
Info
Dissemination
TMC Freeway
Management
request for traffic information,
road network use
request for traffic information,
road network use
Roadway Freeway
Control
Standard Rail Crossing
traffic information,
incident information
TMC Signal Control
maintenance resource request,
closure conditions, traffic equipment status
traffic information
CCTV images
Roadway Signal Control
TMC Incident Detection
maintenance resource
response, equipment
maintenance status
Construction &
Maintenance
Roadway Environmental
Monitoring
environmental conditions,
incident data,
traffic flow,
traffic images,
fault reports,
freeway control status,
HRI status,
reversible lane status,
signal control status,
roadway information
system status
Traffic Data Collection
maintenance resource response,
equipment maintenance status
TMC Incident Detection
toll demand
management
request
Roadside Signal Priority
TMC Road Weather
Monitoring
traffic images,
traffic control coordination (cameras)
ROADWAY
WSDOT
NW Region
freeway control data,
HRI control data,
HRI request,
sensor and
surveillance control,
signal control data,
roadway information
system data
Traffic Maintenance
incident Information,
incident response
status, remote
surveillance control,
resource request
Other Traffic
Management
Cities and
Counties within
and outside
Region
TRAFFIC MANAGEMENT
WSDOT TSMC
NW Region
traffic information coordination
Standard Rail Crossing
Roadside Data Collection
WSDOT Incident
Response Team
& Other
Emergency
Management
Centers
Emergency Dispatch
traffic images,
traffic control
coordination (cameras)
incident response
coordination
incident Information,
incident information
request, resource
deployment status,
current network conditions
(traffic images)
Emergency Response
Management
incident Information,
incident response
status, remote
surveillance control,
resource request
Remote Traveler Support
traffic control
priority status,
traffic information
for transit
EMERGENCY MANAGEMENT
Washington State Patrol
TMC Incident Dispatch
Coord/Communication
freeway control data,
HRI control data,
HRI request,
sensor and
surveillance control,
signal control data,
roadway information
system data
Other Emergency
Management
incident response
coordination
TMC Traffic Info
Dissemination
incident response
coordination
ROADWAY
WSDOT
Olympic Region
traffic images,
traffic control
coordination (cameras)
pollution state
data request
traffic information coordination
HRI Advisories
TMC Reversible Lane
Management
traffic information
CCTV images
railroad advisories,
railroad schedules
TMC HOV Lane
Management
CVAS information
exchange
Traffic and Roadside
Data Archival
traffic information
for media
traffic control
priority status,
traffic information
for transit
ITS Data Repository
(Future)
Interactive Infrastructure
Information
Rail Operations
(Future)
environmental conditions
Media
transit vehicle location data
TRANSIT MANAGEMENT
Transit Operations Center
broadcast
information,
traveler
information
Local Broadcast
TV and Radio
weather information
Toll Administration
Personal Information Access
Transit Center Tracking
and Dispatch
Toll Administration
Personal Basic
Information Reception
Toll Data Collection
Personal Interactive
Information Reception
trip confirmation,
traveler profile,
traveler request
ISP
Coordination
pollution
state
data
request
widearea
statistical
pollution
information
TRANSIT MANAGEMENT
Transit Operations Center
Northwest Weather
Consortium
Other Emissions
Management
Other Roadway
Environmental Monitoring
Other Weather
Data
Other ISP
environmental
conditions
traffic control
priority request
Figure B-1: State (WSDOT) ITS Architecture
Commercial Vehicle
Administration
CV Information
Exchange
Credentials and Taxes
Administration
Transit Center MultiModal Coordination
CV Safety Administration
TRAVELER
broadcast information,
traveler information
Personal Information Access
CVAS information exchange
Information Service Provider
trip confirmation,
traveler profile,
traveler request
Personal Basic
Information Reception
(Future)
Personal Interactive
Information Reception
(Future)
Basic Information
Broadcast
traveler request
Remote Traveler Support
broadcast information,
traveler information
transit info
request, selected
routes, demand
responsive
transit requests
Traffic Management
(County TCC)
TMC Multi-Modal
Coordination
Other ISP
transit and fare
schedules,
demand responsive
transit plan
Transit Management
Transit Center Fixed
Route Operations
Emergency Management
Emergency Response
Management
CENTER
Emergency Vehicle
local signal preemption request
transit
system
data, bus
schedule
& location,
traveler
info
suggested route
On-Board EV En Route
Support
maintenance
resources
response
ITS Backbone
(Other ISP)
traffic info
for media
Media
weather info
Weather Services
Traffic and Roadside
Data Archival
request for right-of-way,
traffic flow, traffic images,
signal control status,
freeway control status,
incident data,
intersection blockage notifications
Other Transit
Management (Sound
Transit and others)
sensor and surveillance control,
freeway control data
Other Jurisdiction Roadway
County Roadway
Roadside Signal Priority
Roadside Signal Priority
Roadway Basic
Surveillance
Roadway Basic
Surveillance
Roadway Signal Controls
Roadway Signal Controls
Roadway Traffic Info
Dissemination (Future)
Roadway Traffic Info
Dissemination (Future)
Roadway Incident
Detection (Future)
Roadway Incident
Detection (Future)
Figure B-2: Prototypical County Highway ITS Architecture
Other Traffic Management
(WSDOT)
TMC Multi-Modal
Coordination
TMC Signal Control
Construction &
Maintenance
TMC HOV Lane
Management
local signal priority request
ROADSIDE
Ports
maintenance resource request,
closure coordination
TMC Reversible Lane
Management
ITS Data Repository
(Future)
CV Safety Administration
(Future)
traffic archive data
TMC Regional Traffic
Control
Emergency Dispatch
emergency vehicle tracking
port information
TMC Incident Detection
incident information,
current network
status, current
network conditions
and emergency traffic
control response,
emergency traffic
control request
transit vehicle schedule p
performance
On-board Transit Signal
Priority (Future)
Credentials and Taxes
Administration (Future)
archive status
archive reports
traffic control
priority status
Transit Center MultModal Coordination
(Future)
TMC Signal Control
traffic images
TMC Incident Dispatch
Coord/Communication
Transit Center
Paratransit Operations
VEHICLE
CV Information
Exchange (Future)
traffic info coordination
traffic control coordination
TMC Signal Control
TMC Traffic Info
Dissemination
transit system data,
traffic control
priority request,
signal control data
Transit Center Tracking
and Dispatch
TMC Multi-Modal
Coordination
Traffic Maintenance
transit vehicle
location data,
traffic information
for transiit,
traffic control
priority status
Remote Basic
Information Reception
Commercial Vehicle
Administration
Collect Traffic
Surveillance
transit vehicle schedule performance,
traffic control priority request,
transit system data
Remote Transit
Information Services
Other Traffic Management
(Cities and other counties)
traffic info
coordination,
traffic control
coordination
ISP traffic
coordination
information
Interactive Infrastructure
Information
Remote Interactive
Information Reception
Transit Vehicle
request for traffic information,
road network use
Collect Traffic
Surveillance
tsp data & parameters
local signal priority request
transit system data, traffic control priority request, signal control data
traffic control priority status
CVAS
information
exchange
transit vehicle schedule performance,
traffic control priority request,
transit system data
Transit Management (King
County Metro and Others)
Transit Vehicle
On-board Transit Signal
Priority (Future)
transit
vehicle
schedule
performance
Transit Center Fixed
Route Operations
transit vehicle location data,
traffic information for transit,
traffic control priority status
Transit Center Multimodal Coordination
(Future)
Remote Traveler Support
transit information
request, selected
routes, demand
responsive
transit requests
Remote Interactive
Information Reception
(Future)
Transit Information
Displays (Future)
Remote Basic
Information Reception
braodcast
information,
traveler
information
Information Service Provider
Basic Information
Broadcast (Future)
broadcast
information,
traveler
informaiton
TMC Multi-modal
Coordination
Other Traffic Management
(WSDOT)
Credentials and Taxes
Administration (Future)
Collect Traffic
Surveillance
TMC HOV Lane
Management
Roadside Signal Priority
Roadway Basic
Surveillance
CV Safety Administration
(Future)
TMC Freeway
Management
TMC Signal Control
TMC Traffic Info
Dissemination
TMC Traffic Info
Dissemination
Collect Traffic
Surveillance
TMC Incident Dispatch
Coord/Communication
(Future)
TMC Incident Detection
hri operational
status,
intersection
blockage
notification
Roadway Signal Controls
Traffic Maintenance
HOV data,
traffic images,
traffic flow
request for traffic information,
road network use
HRI Traffic Management
(Future)
traffic information
Rail Operations
Coordination (Future)
hri advisories
railroad advisories,
railroad schedules
maintenance
resource
request, clousure
maintenance
coordination
resource
response
Interactive Infrastructure
Information (Future)
Personal Basic
Information Reception
(Future)
Personal Interactive
Information Reception
(Future)
Roadway (SEATRAN)
Wayside Equipment
(Future)
track status,
arriving train information
Roadway Traffic Info
Dissemination (Future)
sensor and surveillance control,
freeway control data, hri request,
hri control data
Roadway Incident
Detection (Future)
request for right-of-way,
traffic flow, traffic images,
signal control status,
freeway control status,
incident data, hri status,
intersection blockage notification
Standard Rail Crossing
(Future)
Advanced Rail Crossing
(Future)
local signal
preemption request
event
plans
Event Promoter
traveler
request
Personal Information Access
transit and fare
schedules,
demand responsive
transit plan
Traffic Management
(SEATRAN)
CV Information
Exchange (Future)
Transit Center Tracking
and Dispatch
Transit Center
Paratransit Operations
Commercial Vehicle
Administration
trip confirmation,
traveler profile,
traveler request
parking
parking
information coordination
traffic information
for media
incident information,
current network
status, current
network conditions
and emergency traffic
control response,
emergency traffic
control request
Rail Operations (Future)
Construction &
Maintenance
Hazmat information
Emergency Management
(EMC)
Parking Management
(Seattle Center)
ISP
coordination
Fleet and Freight
Management
Emergency Response
Management
Emergency Dispatch
Other ISP
parking lot data request
ITS Backbone
(Other ISP)
parking information
emergency
vehicle
tracking
suggested
route
Media
Parking Coordination
Emergency Vehicle (Fire)
Parking Management
Parking Surveillance
Figure B-3: City (Seattle) ITS Architecture Diagram
On-Board EV En Route
Support (Future)
Traffic Management
ITS (State)
Backbone
Traffic
ITS Management
Backbone
Roadway
Collect Traffic
Surveillance
Traffic Maintenance
TMC Signal Control
Emergency
ITS Backbone
Management
(State)
Roadway Basic
Surveillance
Sensor and Surveillance Control
Signal Control Data
Roadway Information System Data
Freeway Control Data
TMC Traffic Info
Dissemination
incident information
incident response status
TMC Regional Traffic
Control
TMC Reversible Lane
Management
Roadway Freeway
Control
Roadway Traffic
Information
Dissemination
TMC Incident Dispatch
Coord/Communication
TMC Incident Detection
Roadway Signal Controls
Traffic Images
Traffic Flow
Fault Reports
Signal Control Status
Incident Data
Roadway Information System Status
Freeway Control Status
Reversible Lane Status
Roadway Incident
Detection
Roadway Reversible
Lanes
TMC Freeway
Management
Traffic Coordination
Traffic Control Coordination
Traffic Management
Traffic
ITS Management
Backbone
(Local)
Sensor and Surveillance Control
Signal Control Data
Roadway Information System Data
Collect Traffic
Surveillance
Roadway Basic
Surveillance
Traffic Maintenance
Emergency
ITS Backbone
Management
(Local)
Roadway Signal Controls
TMC Signal Control
incident information
incident response status
TMC Traffic Info
Dissemination
TMC Incident Dispatch
Coord/Communication
Traffic
ITS Management
Backbone
Roadway
Traffic Images
Traffic Flow
Fault Reports
Signal Control Status
Incident Data
Roadway Information System Status
TMC Incident Detection
TMC Regional Traffic
Control
Figure B-4: Typical Center to Center Interface
Roadway Traffic
Information
Dissemination
Roadway Incident
Detection
TRAVELER
1) transit user inputs
2) transit user outputs
Signal Priority
CT Traveler
Information (RTS)
Transit Center
Security
Remote Transit
Information Services
Remote Transit
Information Services
Remote Interactive
Transit User
X50
Information Reception
= Not implemented
= Equip m e n t P a c k a g e
Implementation
= Existing Market
Packa g e
Implementation
= Future Enhancement/
Implementation (1-5
years)
= Future A r c h i t e c t u r e F l o w
CT Transit
Management
Center (TRMS)
X53
X49
CT
Bus Maintenance
Staff
Transit Center Fare &
Load Management
Remote Transit Fare
Management
Transit Data Collection
Transit Garage
Maintenance
VEHICLE
1) driver instructions
2) transit vehicle schedule performance
1) driver instructions
2) transit vehicle schedule performance
route/schedule info
On-Board Transit Fare &
Load Management
transit
user
output
CT Bus Rider
(1) transit information user request
(2) transit traveler information
RATP
On-Board Transit
Security
On-Board Transit Signal
Priority
ITS
Backbone
transit fare payment data
In f o r m a t i o n
transit traveler information
vehicle measures
local traffic control priority request
transit vehicle location data
Transit Vehicle
X52
*Transit Vehicle
*Transit Vehicle
Transit Vehicle
Transit Vehicle
X51
X52
X51
X52
CT
CT Fixed
Route Vehicle
CT Fixed
Route Driver
CT
Paratransit
Vehicle
CT
Paratransit
Driver
Mobile
Supervisor
Roadside
Subsystem
Signal Priority
transit driver inputs
* Includes Regional Express buses with service provided by Community Transitt
Other Regional
Center
Other
Regional
Center
Lynnwood
Traffic
Operations
Center
Clearinghouse System
(SmartCard)
WSDOT
Traffic
Management
Center
1) TSP Status
2) TSP Data & Parameters
driver inputs
vehicle measures
Other
Regional
Center
CENTER
1) emergency notification
2) emergency acknowledge
On-Board Transit Trip
Monitoring
CT
Paratransit
Driver
(1) route assignment
(2) transit driver availability
Other
Regional
Center
transit
driver
inputs
On - B o a r d T r a n s i t
CT
Paratransit
Central Dispatch /
Operations Staff
traffic information for transit
Transit Garage
Operations
On-Board Maintenance
Transit User
X50
transit fare payment data
X52
transit fare payment data
CT Paratransit
Vehicle Subsystem
(TRVS)
On-Board Paratransit
X49
1) transit operator display
2) transit operator
management display
Transit Center Tracking
& Dispatch
1) driver instructions
2) transit vehicle schedule performance
(support on-board fixed route
schedule management)
transit emergency data
1) TSP Status
2) TSP Data & Parameters
(1) transit user inputs
(2) transit user outputs
Fixed-Route Schedule
Management
Regional
Geographic
Information
System
Database
(1) transit operator display
(2) transit operator management data
Transit Center
Paratransit Operations
Transit Center Security
On-Board Fixed-Route
Schedule Management
CT
Fixed Route
Bus Driver
regional map data
Transit Center MultiModal Coordination
Personal Interactive
Information Reception
CT Vehicle
Subsystem (TRVS)*
CT
Fixed Route
Central Dispatch /
Operations Staff
(1) route assignment
(2) transit driver availability
Transit Center
Information Services
CT Traveler
Information (PIAS)
CT Mobile
Supervisor Vehicle
Subsystem
X52
Transit Center FixedRoute Operations
Secure Area Monitoring
CT Bus Rider
Community Transit
Physical Architecture
Figure B-5
Lege n d
Automatic Vehicle
Location
City of Lynnwood
City of Mountlake
Terrace
City of Edmonds
City of Everett
Snohomish County
ROADSIDE
Other
Regional
Center
Emergency
Services
Automatic Vehicle
Location
ET Traveler
Information (RTS)
= Not implemented
= Equip m e n t P a c k a g e
Implementation
Signal Priority
Remote Transit
Information Services
Transit Center
Security
Remote Interactive
Information Reception
Remote Transit
Information Services
Secure Area Monitoring
Transit User
X50
Everett Transit
Physical Architecture
Figure B-6
Lege n d
TRAVELER
1) transit user inputs
2) transit user outputs
= Existing Market
Packa g e
Implementation
= Future Enhancement/
Implementation (1-5
years)
= Future A r c h i t e c t u r e F l o w
Remote Transit Fare
Management
ET Transit
Management
Center (TRMS)
X53
X49
ET
Bus Maintenance
Staff
Transit Center Fare &
Load Management
1) emergency notification
2) emergency acknowledge
Remote Mayday I/F
1) secure area monitoring support
2) secure area surveillance data
Transit Center
Information Services
(1) transit operator display
(2) transit operator management data
X49
Transit Center
Paratransit Operations
Transit Center Security
1) transit operator display
Paratransit
2) transit operator
Central Dispatch /
management display
Operations Staff
(1) transit work schedule
(1) route assignment
(2) maintenance status
transit emergency data
(2) transit driver availability
regional map data
Transit Center Tracking
& Dispatch
Transit Data Collection
driver instructions
Transit Garage
Maintenance
VEHICLE
ET Paratransit
Vehicle Subsystem
(TRVS)
On-Board Paratransit
transit emergency
data
route/schedule info
1) TSP Status
2) TSP Data & Parameters
(1) route assignment
(2) transit driver availability
Other Regional
Center
Community
Transit
Clearinghouse System
(SmartCard)
(RATP via CT)
transit fare payment data
On - B o a r d T r a n s i t
In f o r m a t i o n
On-Board Transit
Security
On-Board Transit Signal
Priority
CENTER
transit
driver
inputs
1) emergency notification
2) emergency acknowledge
vehicle measures
vehicle location data
local traffic control priority request
On-Board Transit Trip
Monitoring
vehicle measures
Roadside
Subsystem
Signal Priority
transit driver inputs
Transit Vehicle
Transit Vehicle
Transit Vehicle
Transit Vehicle
X51
X52
X51
X52
ET Fixed
Route Vehicle
ET Fixed
Route Driver
City of Everett
Snohomish County
ET Paratransit ET Paratransit
Vehicle
Driver
ROADSIDE
ET
transit fare payment data
Other
Regional
Center
On-Board Maintenance
X52
Paratransit
Driver
Transit Garage
Operations
1) driver instructions
2) transit vehicle schedule performance
Regional
Geographic
Information System
Database
ET
transit fare payment data
Personal Interactive
Information Reception
On-Board Transit Fare &
Load Management
ET
Fixed Route
Bus Driver
Transit Center MultiModal Coordination
ET Traveler
Information (PIAS)
On-Board Fixed-Route
Schedule Management
ET
Fixed Route
Central Dispatch /
Operations Staff
Transit Center FixedRoute Operations
ET Bus Rider
ET Vehicle
Subsystem (TRVS)
X52
Other
Regional
Center
ITS
Backbone
Other
Regional
Center
Emergency
Services
TRAVELER
Lege n d
(1) transit user outputs
(2) transit user inputs
Automatic Vehicle
Location
KCM Traveler
Information (RTS)
Transit Center
Security
Remote Interactive
Information Reception
Remote Transit
Information Services
Secure Area Monitoring
(Transit Center)
= Not implemented
= Equip m e n t P a c k a g e
Implementation
Signal Priority
Remote Transit
Information Services
(Transit Watch)
Transit User
X50
= Existing Market
Packa g e
Implementation
= Future Enhancement/
Implementation (1-5
years)
= Future A r c h i t e c t u r e F l o w
Secure Area Monitoring
(Transit Tunnel)
KCM Transit
Management
Center (TRMS)
X49
Transit Center Fare &
Load Management
KCM
KCM
Fixed Route
Central Dispatch /
Operations Staff
Fixed Route
Bus Driver
Transit Center FixedRoute Operations
TRMS Coordination
(1) secure area surveillance video data
(2) emergency acknowledge
(3) emergency notification
Personal Interactive
Information Reception
(BusView, MyBus)
transit fare payment data
KCM
Transit Center
Paratransit Operations
(1) transit operator display
(2) transit operator management data
Transit Center Security
1) transit operator display
2) transit operator management data
VEHICLE
Fixed-Route Schedule
Management
transit driver inputs
On-Board Fixed-Route
Schedule Management
On-Board Transit Fare &
Load Management
On - B o a r d T r a n s i t
KCM
On-Board Transit
Security
transit driver inputs
KCM Paratransit
Vehicle Subsystem
(TRVS)
1) transit information user request
2) transit traveler information
ITS Backbone
On-Board Paratransit
UW ISP (Transit
Watch, BusView,
MyBus)
(1) transit information user request
(2) transit traveler information
(1) TSP Status
(2) TSP Data & Parameters
On-Board Transit
Security
Mobile
Supervisor
CENTER
Other Regional
Transit Center
Other Regional
Center
Other Regional
Center
Clearinghouse
System
(SmartCard)
City of Seattle
King County
WSDOT
Emergency
Services
Traf Ops Ctrs
RATP
In f o r m a t i o n
1) emergency notification
2) emergency acknowledge
On-Board Transit Signal
Priority
On-Board Transit Trip
Monitoring
transit vehicle location data
1) TSP Status
2) TSP Data & Parameters
transit fare payment
data
local traffic control priority request
vehicle measures
transit driver
inputs
roadside data (signpost ID data)
Transit Vehicle
X52
PT
(1) route assignment
(2) transit driver availability
Other Regional
Transit Center
1) driver instructions
2) transit vehicle schedule performance
transit emergency data
(1) route assignment
(2) transit driver availability
On-Board Maintenance
On-Board Maintenance
Transit Vehicle
X52
Mobile
Supervisor
route/schedule info
transit fare payment data
KCM Vehicle
Subsystem (TRVS)*
KCM
Paratransit
Driver
KCM
Bus
Maintenance
(1) transit work schedule
Staff
(2) maintenance status
Transit Garage
Operations
KCM Mobile
Supervisor Vehicle
Subsystem
(support on-board fixed route
schedule management)
Transit Garage
Maintenance
X52
X53
Transit Data Collection
emergency notification
Paratransit
Central Dispatch /
Operations Staff
vehicle measures
transit driver inputs
Roadside
Subsystem
Roadside Subsystem
Automatic Vehicle
Location (Signpost)
Signal Priority
(county wide)
*Transit Vehicle
*Transit Vehicle
Transit Vehicle
Transit Vehicle
X51
X52
X51
X52
KCM Fixed
Route Driver
KCM
Paratransit
Vehicle
KCM
Paratransit
Driver
KCM Fixed
Route Vehicle
ROADSIDE
*Includes Regional Express buses with service provided by King County Metro
Regional
Geographic
Information
System
Database
regional map data
Transit Center Tracking
& Dispatch
1) driver instructions
2) transit vehicle schedule performance
transit emergency data
X49
Transit Center MultiModal Coordination
KCM Traveler
Information (PIAS)
1) driver
instructions
2) transit vehicle
schedule
performance
X52
Transit Center
Information Services
Remote Transit Fare
Management
(1) transit user inputs
(2) transit user outputs
King County Metro
Physical Architecture
Figure B-7
City of Seattle
City of Shoreline
City of Kirkland
City of Redmond
City of Renton
City of Bellevue
King County
City of Auburn
City of Federal Way
City of Kent
City of SeaTac
City of Tukwila
WSDOT
Kitsap Transit
Physical Architecture
Figure B-8
Lege n d
TRAVELER
1) transit user inputs
2) transit user output
Automatic Vehicle
Location
Signal Priority
= Equip m e n t P a c k a g e
Implementation
Transit Center
Security
= Existing Market
Packa g e
Implementation
Remote Transit
Information Services
= Future Enhancement or
Implementation (1-5 years)
KT Traveler
Information (RTS)
Remote Transit
Information Services
Remote Interactive
Transit User
X50
Information Reception
Secure Area Monitoring
(Bremerton)
KT Bus Rider
= Not implemented
= Future A r c h i t e c t u r e F l o w
Remote Transit Fare
Management
KT Transit
Management
Center (TRMS)
X53
KT
Bus Maintenance
Staff
Transit Center Fare &
Load Management
Transit Center FixedRoute Operations
1) transit operator display
2) transit operator
management display
Transit Center
Information Services
Transit Center MultiModal Coordination
KT Traveler
Information (PIAS)
emergency notification
(System currently not functional do
to hardware problems. 12/00)
driver instructions
KT Vehicle
Subsystem (TRVS)
KT Mobile
Supervisor Vehicle
Subsystem
Fixed-Route Schedule
Management
(support on-board fixed route
schedule management)
On-Board Fixed-Route
Schedule Management
On-Board Maintenance
On-Board Transit Fare &
Load Management
1) driver instructions
2) transit vehicle schedule performance
transit emergency data
transit emergency data
X49
1) transit work schedule
2) maintenance status
1) TSP Status
2) TSP Data & Parameters
On-Board Paratransit
Paratransit
Central Dispatch /
Operations Staff
KT
Paratransit
Driver
(1) route assignment
(2) transit driver availability
Other Regional
Center
Other Regional
Center
ITS Backbone
Clearinghouse System
(SmartCard)
transit fare payment data
CENTER
transit drive inputs
On-Board Transit
Security
On-Board Transit Signal
Priority
local signal priority request
vehicle location data
On-Board Transit Trip
Monitoring
Roadside
Subsystem
Signal Priority
Transit Vehicle
X52
transit driver inputs
transit driver inputs
KT
Transit Vehicle
Transit Vehicle
Transit Vehicle
Transit Vehicle
Mobile
Supervisor
X51
X52
X51
X52
KT Fixed
Route Driver
KT
X52
Other
Regional
Center
On-Board Transit
Security
In f o r m a t i o n
KT Fixed
Route Vehicle
Transit Garage
Maintenance
transit fare payment data
On - B o a r d T r a n s i t
transit driver inputs
route/schedule info
Transit Garage
Operations
KT Paratransit
Vehicle Subsystem
(TRVS)
KT
Fixed Route
Bus Driver
transit fare payment data
Transit Center Security
Transit Data Collection
VEHICLE
KT
Fixed Route
Central Dispatch /
Operations Staff
(1) transit operator display
(2) transit operator management data
Transit Center Tracking
& Dispatch
1) driver instructions
2) transit vehicle schedule performance
X52
(1) route assignment
(2) transit driver availability
Transit Center
Paratransit Operations
Personal Interactive
Information Reception
X49
City of Bremerton
KT Paratransit KT Paratransit
Vehicle
Driver
ROADSIDE
Emergency
Services
Pierce Transit
Physical Architecture
Figure B-9
Lege n d
TRAVELER
Automatic Vehicle
Location
Signal Priority
= Equip m e n t P a c k a g e
Implementation
Transit Center
Security
= Existing Market
Packa g e
Implementation
Remote Transit
Information Services
= Future Enhancement or
Implementation (1-5 years)
1) transit user inputs
2) transit user output
PT Traveler
Information (RTS)
Remote Transit
Information Services
Remote Interactive
Transit User
X50
Information Reception
= Future A r c h i t e c t u r e F l o w
Remote Mayday I/F
(Tacoma Dome)
PT Bus Rider
= Not implemented
Remote Transit Fare
Management
X53
Transit Center FixedRoute Operations
PT
1) transit operator display
2) transit operator
management display
PT
PT
Fixed Route
Central Dispatch /
Operations Staff
Fixed Route
Bus Driver
transit fare payment data
(1) route assignment
(2) transit driver availability
Transit Center
Paratransit Operations
PT
(1) transit operator display
(2) transit operator management data
Paratransit
Central Dispatch /
Operations Staff
transit emergency data
1) driver instructions
2) transit vehicle schedule performance
Regional
Geographic
Information System
Database
transit emergency data
Transit Center Security
emergency notification
X52
X49
Transit Center MultiModal Coordination
Personal Interactive
Information Reception
X49
Bus Maintenance
Staff
Transit Center Fare &
Load Management
Transit Center
Information Services
1) transit information user request
2) transit traveler information
PT Traveler
Information (PIAS)
(1) transit user inputs
(2) transit user outputs
PT Transit
Management
Center (TRMS)
Transit Center Tracking
& Dispatch
1) transit work schedule
2) maintenance status
regional map data
X52
PT
Paratransit
Driver
Transit Data Collection
driver instructions
PT Vehicle
Subsystem (TRVS)*
PT Mobile
Supervisor Vehicle
Subsystem
Fixed-Route Schedule
Management
(support on-board fixed route
schedule management)
1) driver instructions
2) transit vehicle schedule performance
VEHICLE
On-Board Fixed-Route
Schedule Management
On-Board Maintenance
On-Board Transit Fare &
Load Management
Transit Garage
Operations
PT Paratransit
Vehicle Subsystem
(TRVS)
Transit Vehicle
X52
route/schedule info
1) TSP Status
2) TSP Data & Parameters
(1) route assignment
(2) transit driver availability
transit fare payment data
Other
Regional
Center
On-Board Paratransit
1) emergency notification
2) emergency acknowledge
On-Board Transit
Security
ITS
Backbone
(1) transit information user request
(2) transit traveler information
transit fare payment data
CENTER
In f o r m a t i o n
On-Board Transit
Security (ST Regional Exp
transit drive inputs
emergency notification
Only)
PT
Mobile
Supervisor
On-Board Transit Signal
Priority
local signal priority request
vehicle location data
Roadside
Subsystem
On-Board Transit Trip
Monitoring
transit driver inputs
Signal Priority
Transit Vehicle
X52
King County
Metro
Mobile
Supervisor
transit driver inputs
transit driver inputs
*Transit Vehicle
*Transit Vehicle
Transit Vehicle
Transit Vehicle
X51
X52
X51
X52
PT Fixed
Route Vehicle
PT Fixed
Route Driver
City of Tacoma
City of Lakewood
City of Puyallup
City of Gig Harbor
City of Univ. Place
Pierce County
WSDOT
PT Paratransit PT Paratransit
Vehicle
Driver
* Includes Regional Express buses with service provided by Pierce Transit
Other Regional
Center
Other
Regional
Center
RATP
On - B o a r d T r a n s i t
transit driver inputs
Transit Garage
Maintenance
ROADSIDE
Clearinghouse System
(SmartCard)
Emergency
Services
Sound Transit - LINK
Physical Architecture - LINK
Figure B-10
Legend
TRAVELER
Sound Transit Traveler
Information (RTS)
Remote Transit Fare
Management
Remote Transit
Information Services
(1) user inputs
(2) user outputs
Automatic Vehicle
Location
= Not implemented
Signal Priority
= Equipment Package
Implementation
Transit Center
Security
= Existing Market Package
Implementation
Remote Transit
Information Services
Remote Interactive
Information Reception
= Future Enhancement/
Implementation (1-5 years)
= Future A r c h i t e c t u r e F l o w
Secure Area Monitoring
Remote MayDay I/F
(2) user outputs
X49
ST
Central Control
System Dispatch
& Operations
Staff
(1) transit operator display
Regional
Geographic
Information System
Database
(2) transit operator
management data
Transit Center Rail
Operations
regional map data
Transit Data Collection
transit fare payment data
transit emergency
Sound Transit Traveler
Information (PIAS)
(1) user inputs
Transit Center Fare &
Load Management
Transit Center
Information Services
secure area surveillance data
transit traveler information
(ad hoc messaging, real time arrival)
Transit User
X50
ST Transit
Management
Center (TRMS)
Transit Center Security
Transit Center Tracking
& Dispatch
Personal Interactive
Information Reception
Transit Garage
Operations
driver instructions via radio
coordination data (voice only)
X52
schedule, fare, real time
performance Information
(1) route assignment
ST
LRT Operator
(2) transit operator availability
Transit Garage
Maintenance
X53
(1) transit work schedule
VEHICLE
LRT Vehicle
Subsystem (TRVS)
LRT Maintenance
Staff
transit fare payment data
On-Board Fixed-Route
Schedule Management
Other Regional Transit
Center
On-Board Transit
Security
RATP
On-Board Transit Trip
Monitoring
ITS Backbone
transit vehicle conditions (direct laptop download only)
operator inputs
Monitoring &
Control
(2) vehicle location
Emergency Services
Fire Detection
1) transit vehilcle location data
2) transit vehicle schedule performance
On-Board Transit Signal
Priority
X51
Clearinghouse
System (SmartCard)
Other Regional
Centers
Tunnel
On-Board Transit
Information
(1) vehicle measures
Other Regional
Transit Center
CENTER
On-Board Maintenance
LRT Vehicle
ST
(2) maintenance status
local traffic control priority request
Roadside
Subsystem
Wayside
Subsystems
Tunnel
Subsystems
Signal Priority
Vehicle Location
Determination
Ventilation
Security
Lighting
Fire Detection/
Suppression
City of Seattle
City of Tukwila
LRT Operator
X52
City of Tacoma
Vehicle
Identification
transit vehicle location data
ROADSIDE
WAYSIDE/OTHER
TRAVELER
1) transit user inputs
2) transit user outputs
Automatic Vehicle
Location
Signal Priority
ST Traveler
Information (RTS)
Remote Transit
Information Services
Remote Interactive
Transit User
X50
Transit Center
Security
Remote Transit
Information Services
Information Reception
Secure Area Monitoring
Sounder Rider
Remote Transit Fare
Management
Sound Transit - Sounder
Physical Architecture
Figure B-11
Lege n d
= Not implemented
= Equip m e n t P a c k a g e
Implementation
= Existing Market
Packa g e
Implementation
= Future Enhancement/
Implementation (1-5
years)
= Future A r c h i t e c t u r e F l o w
1) transit traveler information
2) transit traveler request
secure area surveillance data
transit fare payment data
ST Transit
Management
Center (TRMS)
Transit Center Fare &
Load Management
Transit Center FixedRoute Operations
X53
X49
X52
Sounder
Maintenance
Staff
(AMTRAK)
Sounder Central
Dispatch/
Operations Staff
(BNSF/Ft. Worth)
Sounder Crew
(BNSF)
1) transit operator display
2) transit operator management display
Transit Center
Information Services
1) transit operator display
2) transit operator management display
1) transit operator display
2) transit operator management display
3) Transit emergency coordination (voice only)
Transit Center MultiModal Coordination
ST Traveler
Information (PIAS)
transit fare payment data
Transit Center Security
Personal Interactive
Information Reception
1) transit operator display
2) transit operator
management display
Transit Data Collection
(1) transit user inputs
(2) transit user outputs
Transit Garage
Maintenance
Transit Garage
Operations
transit emergency data
Transit Emergency
Coordination Data
(voice only)
route/schedule info
VEHICLE
1)transit traveler request
2) travel traveler
information
1) TSP Status
2) TSP Data & Parameters
(1) transit information user request
(2) transit traveler information
ST Vehicle
Subsystem (TRVS)
On-Board Fixed-Route
Schedule Management
Other
Regional
Center
1) driver instructions
2) transit vehicle schedule
performance
On-Board Maintenance
RATP
On-Board Transit Fare &
Load Management
CENTER
On-Board Transit
Information
On-Board Transit
Security
On-Board Transit Signal
Priority
local traffic control priority request
On-Board Transit Trip
Monitoring
Roadside
Subsystem
driver inputs
Signal Priority
Transit Vehicle
Transit Vehicle
X51
X52
Locations To Be
Determined
Sounder
Vehicle
Sounder Crew
(BNSF)
ROADSIDE
Other Regional
Center
Clearinghouse System
(SmartCard)
Other
Regional
Center
Emergency
Services
TRAVELER
1) transit user inputs
2) transit user outputs
Automatic Vehicle
Location
WSF Traveler
Information (RTS)
Signal Priority
Remote Transit
Information Services
Transit Center
Security
Remote Interactive
Information Reception
Remote Transit
Information Services
Secure Area Monitoring
(Bremerton)
Transit User
X50
= Not implemented
= Equip m e n t P a c k a g e
Implementation
= Existing Market
Packa g e
Implementation
= Future Enhancement/
Implementation (1-5
years)
= Future A r c h i t e c t u r e F l o w
Secure Area Monitoring
(Edmonds)
WSF Ferry Rider
Washington State Ferries
Physical Architecture
Figure B-12
Lege n d
WSF Transit
Management
Center (TRMS)
X53
Transit Center Fare &
Load Management
X49
X52
WSF
WSF
Maintenance
Staff
Central Dispatch
/Operations Staff
Passenger Only &
Vehicle
Passenger Only &
Vehicle
WSF
Vessel Driver
(Passenger-Only &
Vehicle)
Transit Center FixedRoute Operations
Remote Mayday I/F
(Terminals)
emergency notification
Remote Transit Fare
Management (Includes
Terminals)
Transit Center
Information Services
Transit Center MultiModal Coordination
secure area
surveillance
Transit Center Security
WSF Traveler
Information (PIAS)
transit emergency data
transit fare payment data
transit traveler information
1) emergency notification
2) emergency acknowledge
1) transit operator display
2) transit operator
management display
Transit Center Tracking
& Dispatch
Personal Interactive
Information Reception
1) transit work schedule
2) maintenance status
Transit Data Collection
(1) transit user inputs
(2) transit user outputs
Transit Garage
Maintenance
VESSEL
1) emergency notification
2) emergency acknowledge
Transit Garage
Operations
traffic flow
(1) route assignment
(2) transit driver availability
vessel conditions
secure area surveillance
driver instructions
WSF PassengerOnly Vessel
Subsystem (TRVS)
WSF Vessel
Subsystem (TRVS)
On-Board Fixed-Route
Schedule Management
On-Board Fixed-Route
Schedule Management
On-Board Maintenance
On-Board Maintenance
On-Board Transit Fare &
Load Management
On-Board Transit Fare &
Load Management
On - B o a r d T r a n s i t
On - B o a r d T r a n s i t
In f o r m a t i o n
In f o r m a t i o n
On-Board Transit
Security
On-Board Transit
Security
On-Board Transit Trip
Monitoring
On-Board Transit Trip
Monitoring
vessel conditions
Other Regional
Center
Other
Regional
Center
Other
Regional
Center
Other
Regional
Center
Other
Regional
Center
Clearinghouse System
(SmartCard)
Coast Guard/
Port of
Seattle
ITS
Backbone
WSDOT TMC
Emergency
Services
CENTER
vessel location
driver instructions
driver inputs
vessel measures
vessel location
Roadside
Subsystem
(Terminals)
driver inputs
vessel measures
Vessel
Vessel
Vessel
Vessel
X51
X52
X51
X52
Roadway Basic
Surveillance
WSF Vessel
WSF Vessel
Driver
WSF Vessel
WSF Vessel
Driver
Seattle
Edmonds
Mukilteo
Bremerton
Bainbridge
Kingston
ROADSIDE
ITS
State
Backbone
TMS
ITS
County
Backbone
TMS
ITS Backbone
Park Service
traffic information
request for traffic information
traffic information
request for traffic information
ITS Backbone
traffic information
request for traffic information
traffic information
traffic information
incident information
ITS Backbone
Private ISP
ITSCity
Backbone
TMS
request for incident information
request for traffic information
request for transit
system data
transit system data
ITS
Transit
Backbone
TRMS
Emergency
ITS Backbone
Operations
Figure B-13: ITS Backbone
State ISP
traffic information
traffic information
County ISP
RMTIC
City ISP
County TMS
ITS Backbone
Dynamic
Real-time
Data
ISP Coordination
State TMS
traffic information
City TMS
transit system data
Transit TRMS
Transit ISP
traveler request
incident data
incident information
Private ISP
Emergency
Operations
traveler request
traveler information
traveler information
traffic information
Park Service
Remote Traveler Support
Personal Information Access
Figure B-14: Regional Multi-Modal Traveler Information Center
Park Service
TRAVELER
Fleet and Freight Management
credential application
Fleet Credentials and
Taxes Management and
Reporting
electronic credentials
compliance review report
Commercial Vehicle Administration
(State)
Credentials and Taxes
Administration
CV Information
Exchange
CVAS information exchange
Commercial Vehicle Administration
(Local/City)
CV Safety Administation
VEHICLE
CV Information
Exchange
CENTER
safety information
CVO database update
CVO database update
credentials information
roadside log update
credentials info request
roadside log update
safety information request
Commercial Vehicle
screening data
CVO weight & presence
clearance event record
screening request
pass/pull in
Commercial Vehicle Check
(Local)
Commercial Vehicle Check
(State)
On-Board CV Electronic
Data
Citation and Accident
Electronic Recording
Roadside Safety
Inspection
screening request
clearance event record
pass/pull-in
screening data
CVO weight and presence
ROADSIDE
Figure B-15: Local Link to CVISN
Roadside WIM
Roadside Electronic
Screening
transit emergency data
TRAVELER
transit emergency coordination data
Transit Management
Personal Information Access
emergency notification
Personal Mayday I/F
Typical Emergency Management
emergency acknowledge
HAZMAT
information
request
Freight Management System
Personal Location
Determination
Transit Center Security
Fleet HAZMAT
Management
Emergency Call-Tracking
HAZMAT
information
Emergency Response
Management
Remote Traveler Support
Emergency Dispatch
incident information
Mayday Support
emergency notification
Remote Mayday I/F
Information Service Provider
incident information request
Basic Information
Broadcast
weather info
Weather Service
emergency acknowledge
Interactive Infrastructure
Information
incident report
emergency acknowledge
Other EM
VEHICLE
Traffic Management
current network conditions
emergency traffic control response
resource deployment status
incident information request
incident information
Vehicle
TMC Signal Control
emergency notification
emergency traffic control request
resource request
remote surveillance control
incident response status
incident information
remote surveillance control
emergency vehicle tracking data
incident status
Vehicle Mayday I/F
Vehicle Location
Determination
suggested route
emergency dispatch requests
Vehicle Safety
Monitoring System
TMC Incident Detection
TMC Incident Dispatch
Coordination/
Communication
TMC Traffic Information
Dissemination
CENTER
Emergency Vehicle
On-Board EV En Route
Support
Roadway
Vehicle Location
Determination
On-Board EV Incident
Management
Communication
signal control data
local signal preemption request
ROADSIDE
Figure B-16: Emergency Management Service Provider
Roadside Signal Priority
request for right of way
Traffic Management
Transit
ITS Backbone
Management
ITS Data Mart
(Internal ITS Data Mart)
Transit Data Collection
Government Reporting
System Support
ITS Data Repository
archive request
transit archive data
Archived
Traffic
ITSData
Management
Backbone
Management
(Data Warehouse)
Traffic Management
Traffic
ITS Management
Backbone
ITS Data Mart
(Internal ITS Data Mart)
Government Reporting
System Support
traffic archive data
Traffic Data Collection
ITS Data Repository
Government Reporting
System Support
On-Line Analysis and
Mining
ITS Data Repository
Traffic Management
Emergency
ITS Backbone
Management
ITS Data Mart
(Internal ITS Data Mart)
archive request
Emergency Data
Collection
Government Reporting
System Support
emergency archive data
archive request
Traffic and Roadside
Data Archival
commercial vehicle archive data
ITS Data Repository
traveler archive data
archive request
archive request
Traffic Management
Commercial
ITS
Vehicle
Backbone
Administration
ITS Data Mart
(Internal ITS Data Mart)
Traffic Management
Information
ITS Backbone
Service Provider
ITS Data Mart
(Internal ITS Data Mart)
CV Data Collection
ISP Data Collection
Government Reporting
System Support
Government Reporting
System Support
ITS Data Repository
ITS Data Repository
Figure B-17: Archived Data Management
APPENDIX C
Standards Summary
SUMMARY OF ITS STANDARDS DOCUMENTS
Table 1: Organization Contact Information
Table 2: Summary of ITS Standards Documents
The following are the table column headings:
Title: The current title of the standards document, or the committee or working group’s designation for the document.
SDO and Document Number: The name of the lead standards development organization (SDO) responsible for the
standard and the current document number.
Description: A brief description or intended scope of the standards document.
Web Address and Order Information: The Web site where additional information may be found. Ordering information is
provided for those standards documents that have been published and are currently available for purchase.
Contact: The name of the person most familiar with the standard document’s content. In some cases, the contact person
is the committee chair for the committee or working group, while in others it may be the person assigned to manage the
standards document.
TABLE 1: ORGANIZATION AND CONTACT INFORMATION
ORGANIZATION
American National Standards Institute, Accredited Standards Committee X12, Electronic
Data Interchange (ANSI X12)
11 West 42nd Street
New York, New York 10036
Telephone: 212-642.4900
Fax: 212-398.0023
www.ansi.org
American Association of State Highway and Transportation Officials (AASHTO)
444 North Capitol Street, NW, Suite 249
Washington, DC 20001
Telephone: 202-624-5800
Fax: 202-624-5806
www.aashto.org
American Society for Testing & Materials (ASTM)
100 Barr Harbor Drive
West Conshohocken, PA 19428
Telephone: 610-832-9585
Fax: 610-832-9555
www.astm.org
Electronic Industries Alliance (EIA)/
Consumer Electronics Association (CEA)
2500 Wilson Blvd.
Arlington, VA 22201
Telephone: 703-907-7600
Fax: 703-907-7601
www.ce.org
CONTACT
Karen Goldee
Johns Hopkins University - Applied Physics Laboratory
240-228-5000 x8315
karen.goldee@jhuapl.edu
Sheldon (Bo) Strickland
Transportation Consultant
703-281-6510
strickbo@aol.com
Lee Armstrong
Armstrong Consulting, Inc.
617-261-7151
LRA@TIAC.net
Jean Johnson
CEA Technology and Standards Dept.
703-907-7972
jeanj@ce.org
ORGANIZATION AND CONTACT INFORMATION
(Continued)
ORGANIZATION
Institute of Electrical and Electronics Engineers (IEEE)
445 Hoes Lane, P.O. Box 1331
Piscataway, New Jersey 08855
Telephone: 732-981-0060
Fax: 732-981-1721
www.ieee.org
Institute of Transportation Engineers (ITE)
1099 14th Street, NW
Suite 300 West
Washington, DC 20005-3438
Telephone: 202-289-0222
Fax: 202-289-7722
www.ite.org
National Electrical Manufacturers Association (NEMA)
1300 N. 17th Street
Arlington, VA 22200
Telephone: 703-841-3200
Fax: 703-841-3300
www.nema.org
Society of Automotive Engineers (SAE)
400 Commonwealth Drive
Warrendale, PA 15096
Telephone: 724-776-4841
Fax: 724-776-0243
www.sae.org
CONTACT
Anita C. Ricketts
IEEE
732-562-3847
a.ricketts@ieee.org
James M. Cheeks, Jr.
ITE
202-289-0222 x131
jcheeks@ite.org
Bruce Schopp
NEMA
703-841-3231
bru_schopp@nema.org
Richard Cox
SAE
724-772-4013
rcox@sae.org
TABLE 2: SUMMARY OF ITS STANDARDS DOCUMENTS
Title
A Conceptual ITS
Architecture: An ATIS
Perspective
Adaptive Cruise
Control: Operating
Characteristics and
User Interface
Advanced
Transportation
Controller (ATC)
ATC Application
Program Interface
(API)
SDO and
Document
Number
SAE
J1763
SAE
J2399
ITE
9603-3
ITE
9603-1
ITE
ATC Cabinet
9603-2
Description
This Information Report describes a general reference architecture for
integration of multiple advanced traveler information system (ATIS)
devices. This conceptual architecture provides a general view of ITS
functions and interfaces, however the National ITS Architecture
reflects a more current conceptual model in this area.
This standard presents the minimum requirements for safety-related
elements of the operating characteristics and user interface of
vehicles equipped with adaptive cruise control (ACC). It also
coordinates the operating characteristics and user interface with
collision warning and avoidance, along with other driver systems.
Web Address and
Order Information
Order from www.sae.org,
or call 724-776-4970.
To link directly to SAE
J1763, click here.
Contact
Richard Cox
SAE
724-772-4013
rcox@sae.org
Richard Cox
http://www.sae.org/TECHC SAE
724-772-4013
MTE/safety.htm
rcox@sae.org
James M. Cheeks, Jr.
Standard for advanced transportation controller (ATC) devices to
support ITS data flows and standards that enable deployment of ITS. http://www.ite.org/standard ITE
s/atc/index.htm
202-289-0222 x131
Capable of operating in the ATC cabinet and using the ATC
jcheeks@ite.org
application program interfaces.
An advanced transportation controller (ATC) software application
program interfaces (APIs) that support ITS data flows and standards
enabling the deployment of ITS functions. The APIs provide a
template for API programming for specific functionality associated
with equipment and market packages defined by the National ITS
Architecture.
James M. Cheeks, Jr.
http://www.ite.org/standard ITE
202-289-0222 x131
s/atc/index.htm
jcheeks@ite.org
Functional physical design requirements for an advanced
transportation controller (ATC) cabinet that supports the deployment
of multiple ITS functions in a single cabinet.
James M. Cheeks, Jr.
http://www.ite.org/standard ITE
202-289-0222 x131
s/atc/index.htm
jcheeks@ite.org
Note: Order information is only available for published standards documents.
February 2001
Page 4 of 21
Title
Commercial Vehicle
Credentials
Commercial Vehicle
Safety and
Credentials
Information Exchange
Commercial Vehicle
Safety Reports
Comparison of GATS
Messages to SAE
ATIS Standards
Information Report
Data Dictionary for
Advanced Traveler
Information System
(ATIS)
SDO and
Document
Number
ANSI
TS286
ANSI
TS285
ANSI
TS284
SAE
J2539
SAE
J2353
Description
Web Address and
Order Information
Order from
http://www.disa.org/ or call
703-548-7005.
To link directly to ANSI
TS286, go to
http://www.jhuapl.edu/cvisn
/downdocs
Order from
http://www.disa.org/ or call
An electronic data interchange (EDI) transaction set to permit
703-548-7005.
enforcement officials, government administrators and other
To link directly to ANSI
authorized parties to retrieve information electronically on the safety
TS285, go to
performance, regulatory compliance, and credentials status of
http://www.jhuapl.edu/cvisn
commercial motor vehicles, carriers, and drivers.
/downdocs
Order from
http://www.disa.org/ or call
An electronic data interchange (EDI) transaction set to allow
703-548-7005.
authorized parties to electronically request and send reports on
information related to the safe operation of commercial road vehicles, To link directly to ANSI
such as inspection reports, safety and compliance review reports, and TS284, go to
http://www.jhuapl.edu/cvisn
hazardous material incident reports.
/downdocs
An electronic data interchange (EDI) transaction set that can be used
by owners, leasers, and drivers of commercial motor vehicles to apply
electronically for credentials necessary to legally operate those
vehicles, and by authorizing jurisdictions to electronically transmit
credential data to applicants and other authorized entities.
An overview and comparison of Global Automotive Telematics
Standard (GATS) messages developed for use on global system
mobile (GSM) cellular phone systems (European).
A minimum set of medium-independent data elements needed by
potential information service providers to deploy ATIS services and
provide the basis for future interoperability of ATIS devices.
Note: Order information is only available for published standards documents.
February 2001
www.sae.org
Order from www.sae.org,
or call 724-776-4970.
To link directly to SAE
J2353, click here.
Contact
Karen Goldee
Johns Hopkins Applied
Physics Laboratory
240-228-5000
karen.goldee@jhuapl.edu
Karen Goldee
Johns Hopkins Applied
Physics Laboratory
240-228-5000
karen.goldee@jhuapl.edu
Karen Goldee
Johns Hopkins Applied
Physics Laboratory
240-228-5000
karen.goldee@jhuapl.edu
Richard Cox
SAE
724-772-4013
rcox@sae.org
Richard Cox
SAE
724-772-4013
rcox@sae.org
Page 5 of 21
Title
Data Radio Channel
(DARC) System
Field Test Analysis
Information Report
Forward Collision
Warning: Operating
Characteristics and
User Interface
Guide for Microwave
Communications
System Development
Information Report on
ITS Terms and
Definitions
SDO and
Document
Number
EIA/CEA
EIA-794
SAE
J2372
SAE
J2400
IEEE
Std 14041998
SAE
J1761
Description
Specifies the DARC FM Subcarrier waveform for the delivery of
traveler information, messages and data services to mobile, portable
and fixed receivers.
This information report presents the results of field tests on locationreferencing standards.
Web Address and
Order Information
Order from
http://www.global.ihs.com/
or call Global Engineering
Documents at 800-8547179.
Order from www.sae.org,
or call 724-776-4970.
To link directly to SAE
J2372, click here.
Contact
Jean Johnson
CEA
703-907-7972
jjohnson@ce.org
Richard Cox
SAE
724-772-4013
rcox@sae.org
Minimum safety and human factor requirements for front collision
warning (FCW) operating characteristics and driver interfaces to
ensure consistency across vehicles so that drivers can quickly
understand and safely use a FCW-equipped vehicle.
Richard Cox
http://www.sae.org/TECHC SAE
724-772-4013
MTE/safety.htm
rcox@sae.org
A guide that addresses all the requirements for microwave system
design, procurement, construction, maintenance, and subsequent
operations.
Order from
http://standards.ieee.org/ca Anita C. Ricketts
talog/its.html, or call 800- IEEE
678-IEEE
732-562-3847
a.ricketts@ieee.org
To link directly to IEEE
1404, click here.
Order from www.sae.org,
or
call 724-776-4970.
A dictionary of terminology in the ITS field, with a focus on the vehicle
and interfaces to the vehicle.
To link directly to SAE
J1761, click here.
Note: Order information is only available for published standards documents.
February 2001
Richard Cox
SAE
724-772-4013
rcox@sae.org
Page 6 of 21
Title
In-Vehicle Navigation
System
Communication
Device Message Set
Information Report
ISP-Vehicle Location
Referencing Standard
ITS Data Bus
Architecture
Reference Model
Information Report
ITS Data Bus Data
Security Services
Recommended
Practice
ITS Data Bus Protocol
- Application Layer
Recommended
Practice
SDO and
Document
Number
SAE
J2256
SAE
J1746
SAE
J2355
SAE
J1760
SAE
J2366-7
Description
Web Address and
Order Information
Contact
Defines the form and content of the messages sent between a traffic
management center (TMC) or information service provider (ISP) and
vehicles, including traffic information, emergency service, and route
guidance information.
Richard Cox
http://www.sae.org/TECHC SAE
724-772-4013
MTE/navcom.htm
rcox@sae.org
A referencing format for information service provider (ISP)-to-vehicle
and vehicle-to-ISP references. This standard will reflect the crossstreets profile of the current location reference message specification
(LRMS) document as expressed in the National Location Referencing
Information Report (SAE J2374).
Order from www.sae.org,
or call 724-776-4970.
To link directly to SAE
J1746, click here.
Order from www.sae.org,
A reference model for an in-vehicle data bus. The ITS data bus (IDB)
or call 724-776-4970.
will enable manufacturers, dealers, and vehicle owners to install a
wide range of electronics equipment reliably and safely in a vehicle at
To link directly to SAE
any time during the vehicle lifecycle.
J2355, click here.
Richard Cox
SAE
724-772-4013
rcox@sae.org
Richard Cox
SAE
724-772-4013
rcox@sae.org
Richard Cox
Specifies definition of data security requirements between devices on
the ITS data bus (IDB) and definitions of device and message level
http://www.sae.org/TECHC SAE
724-772-4013
security. Also includes a mechanism to discourage theft of data bus MTE/databus.htm
rcox@sae.org
modules.
Requirements for the application layer (layer 7 of the OSI model) for
the ITS data bus.
Note: Order information is only available for published standards documents.
February 2001
Richard Cox
http://www.sae.org/TECHC SAE
724-772-4013
MTE/databus.htm
rcox@sae.org
Page 7 of 21
Title
ITS Data Bus Protocol
- Link Layer
Recommended
Practice
ITS Data Bus Protocol
- Physical Layer
Recommended
Practice
ITS Data Bus Protocol
- Thin Transport Layer
Recommended
Practice
ITS In-Vehicle
Message Priority
Mayday Industry
Survey Information
Report
SDO and
Document
Number
SAE
J2366-2
SAE
J2366-1
SAE
J2366-4
SAE
J2395
SAE
J2352
Description
Requirements for the link layer (layer 7 of the OSI model) for the ITS
data bus.
Web Address and
Order Information
Contact
Richard Cox
http://www.sae.org/TECHC SAE
724-772-4013
MTE/databus.htm
rcox@sae.org
A physical interface device (connector) that will ensure compatibility
Richard Cox
http://www.sae.org/TECHC SAE
between vehicles and aftermarket devices. Physical interface
performance requirements, circuit identification and configuration, and MTE/databus.htm
724-772-4013
electrical requirements for the physical layer of the ITS data bus.
rcox@sae.org
Requirements for the thin transport layer (Layer 4 of the OSI model)
for the ITS data bus.
Richard Cox
http://www.sae.org/TECHC SAE
724-772-4013
MTE/databus.htm
rcox@sae.org
Richard Cox
Specifies orderly temporal and spatial presentation of ITS information http://www.sae.org/technic SAE
to the driver.
alcommittees/ivshome.htm 724-772-4013
rcox@sae.org
A summary of information obtained by way of a survey conducted in
1997 of MAYDAY system manufacturers. The information is limited
to technical data as it pertains to vehicle and on-board MAYDAY
system operations. This survey's purpose was to determine whether
the general concept and architecture on which the J2313 MAYDAY
Message Set that was consistent with those of current MAYDAY
system hardware manufacturers.
Note: Order information is only available for published standards documents.
February 2001
Order from www.sae.org,
or call 724-776-4970.
To link directly to SAE
J2352, click here.
Richard Cox
SAE
724-772-4013
rcox@sae.org
Page 8 of 21
Title
Measurement of
Driver Visual Behavior
Using Video Based
Methods (Def. &
Meas.)
Message Set for
Advanced Traveler
Information System
(ATIS)
Message Sets for
External TMC
Communication
(MS/ETMCC)
Messages for
Handling Strings and
Look -Up Tables in
ATIS Standards
National Location
Referencing
Information Report
SDO and
Document
Number
SAE
J2396
SAE
J2354
ITE
TM 2.01
SAE
J2540
SAE
J2374
Description
Web Address and
Order Information
Contact
Procedures for collecting, reducing, analyzing, and reporting on
Richard Cox
driver-eye glance data in a manner suitable for evaluating ITS
http://www.sae.org/TECHC SAE
systems and comparing alternative designs for a particular system in
724-772-4013
MTE/safety.htm
terms of visual demand. Helps insure that systems minimize the time
rcox@sae.org
a driver's eyes are off the road.
Order from www.sae.org,
A basic message set using the data elements from the ATIS data
or call 724-776-4970.
dictionary needed by potential information service providers to deploy
ATIS services and to provide the basis for future interoperability of
To link directly to SAE
ATIS devices.
J2354, click here.
Richard Cox
SAE
724-772-4013
rcox@sae.org
A message set standard for communication between traffic
management centers and other ITS centers, including information
service providers, emergency management systems, missions
management systems, and transit management systems.
http://www.ite.org/tmdd
James M. Cheeks, Jr.
ITE
202-289-0222 x131
jcheeks@ite.org
www.sae.org
Richard Cox
SAE
724-772-4013
rcox@sae.org
Describes the process used in various SAE ATIS message set
standards to deliver textual strings and provides national tables used
in the delivery of incident description.
A basis for location referencing standardization activities by various
application communities and SDOs.
Note: Order information is only available for published standards documents.
February 2001
Order from www.sae.org,
or call 724-776-4970.
To link directly to SAE
J2374, click here.
Richard Cox
SAE
724-772-4013
rcox@sae.org
Page 9 of 21
Title
NTCIP Transportation
Transport Profile
NTCIP - Application
Profile for Common
Object Request
Broker Architecture
(CORBA)
NTCIP - Application
Profile for Data
Exchange ASN.1
(DATEX)
NTCIP - Application
Profile for File
Transfer Protocol
(FTP)
NTCIP - Application
Profile for Simple
Transportation
Management
Framework (STMF)
SDO and
Document
Number
AASHTO
2201
AASHTO
2305
AASHTO
2304
AASHTO
2303
AASHTO
2301
Description
Web Address and
Order Information
Contact
Defines a bandwidth efficient mechanism to transmit data when the
subject devices are directly connected and do not require network
services.
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
Real time peer-to-peer exchange (including some remote
control/command capability) between transportation management
centers and systems such as traffic operations centers, transit
operations centers, emergency management centers, and traveler
information systems. (Formerly TS 3.AP- CORBA)
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
Fulfills the need for a communications stack that supports routing,
sequencing, and file transfer over point-to-point links, based on
(sockets) TCP, IP, and PPP. (Formerly TS 3.AP- DATEX)
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
A common application profile providing connection-oriented file
transfer services. (Formerly TS 3.AP- FTP-199x)
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
Bruce Schopp
A set of application, presentation, and session layer protocols to
http://www.ntcip.org/library/ NEMA
provide simple information management services. (Formerly TS 3.AP703-841-3231
documents/
STMF)
bru_schopp@nema.org
Note: Order information is only available for published standards documents.
February 2001
Page 10 of 21
Title
NTCIP - Application
Profile for Trivial File
Transfer Protocol
NTCIP - Base
Standard: Octet
Encoding Rules
(OER)
NTCIP - Class B
Profile
NTCIP - CORBA
Naming Convention
NTCIP - CORBA
Near-Real Time Data
Service
SDO and
Document
Number
AASHTO
2302
AASHTO
1102
AASHTO
2001
AASHTO
1104
AASHTO
1106
Description
Web Address and
Order Information
Contact
Bruce Schopp
Defines how to use the Trivial File Transfer Protocol within
http://www.ntcip.org/library/ NEMA
transportation networks. A common application profile providing
703-841-3231
documents/
connectionless file transfer services. (Formerly TS 3.AP- TFTP-199x)
bru_schopp@nema.org
A set of encoding/decoding rules to prepare data for transmission or
to decode data before sending it to the application. Developed as a
derivative of the Basic Encoding Rules (BER), as defined in ISO
8825-1. Within the NTCIP suites of protocols, OER is to be used in
conjunction with NTCIP-STMF and NTCIP-DATEX ASN. (Formerly
TS 3.BP-OER-1999)
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
A general method of interconnecting ITS field equipment such as
traffic controllers and variable message signs. Includes the protocol
and procedures for establishing communications between those
components and the reference common data sets to be used by all
such equipment. (Formerly TS 3.3) Amendment 1 is in ballot.
Bruce Schopp
Order from
NEMA
http://www.ntcip.org/order/ 703-841-3231
bru_schopp@nema.org
Specifies requirements for establishing names for management
centers and for the devices managed by those centers in a CORBA
based NTCIP Center to Center implementation.
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
Defines the way that participating centers can use CORBA to
interchange data in a near real-time manner.
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
Note: Order information is only available for published standards documents.
February 2001
Page 11 of 21
Title
NTCIP - CORBA
Security Service
NTCIP - Data
Collection &
Monitoring Devices
NTCIP - Data
Dictionary for Closed
Circuit Television
(CCTV)
NTCIP - Global Object
Definitions
NTCIP - Information
Profile for DATEX
SDO and
Document
Number
AASHTO
1105
AASHTO
1206
AASHTO
1205
AASHTO
1201
AASHTO
2501
Description
Web Address and
Order Information
Contact
Specifies the protocols and application interfaces needed to
implement a CORBA based NTCIP center-to-center security
interface.
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
Specifies object definitions that may be supported by data collection
and monitoring devices, such as roadway loop detectors. (Formerly
TS 3.DCM)
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
A database for closed circuit television systems. The format of the
database is identical to other NTCIP devices and uses ASN.1
representation. Targeted devices include cameras, lenses, video
switches, and positioning controls for aiming and identification, such
as videotext overlays. The standard will support various levels of
conformance. (Formerly TS 3.CCTV)
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
This document defines those pieces of data that are likely to be used
in multiple device types such as actuated signal controllers and
dynamic message signs. Examples of this data include time, report
generation, scheduling concepts, etc. (Formerly TS 3.4) Amendment
1 is in ballot.
Bruce Schopp
NEMA
Order from
http://www.ntcip.org/order/ 703-841-3231
bru_schopp@nema.org
Bruce Schopp
This standard defines what services are required within DATEX
http://www.ntcip.org/library/ NEMA
centers, namely a mechanism to determine what messages and data
703-841-3231
documents/
a center supports.
bru_schopp@nema.org
Note: Order information is only available for published standards documents.
February 2001
Page 12 of 21
Title
NTCIP – Information
Profile for CORBA
NTCIP - Internet
(TCP/IP and UDP/IP)
Transport Profile
NTCIP - Message Set
for Weather Reports
NTCIP - Object
Definitions for
Actuated Traffic
Signal Controller Units
NTCIP - Object
Definitions for
Dynamic Message
Signs
SDO and
Document
Number
AASHTO
2502
AASHTO
2202
AASHTO
1301
AASHTO
1202
AASHTO
1203
Description
This standard defines which CORBA services are required in ITS
systems.
Web Address and
Order Information
Contact
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
Bruce Schopp
A set of transport and network layer protocols to provide
http://www.ntcip.org/library/ NEMA
connectionless and connection-oriented transport services. (Formerly
703-841-3231
documents/
TS 3.TP- INTERNET)
bru_schopp@nema.org
This standard defines messages used to exchange weather and
pavement data between centers.
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
Specifications for objects that are specific to actuated signal
controllers and definitions of standardized object groups that can be
used for conformance statements. (Formerly TS 3.5)
Bruce Schopp
NEMA
Order from
http://www.ntcip.org/order/ 703-841-3231
bru_schopp@nema.org
Defines data that is specific to dynamic message signs including all
types of signs that can change state, such as blank-out signs,
changeable signs, and variable signs. (Formerly TS 3.6)
Bruce Schopp
Order from
NEMA
http://www.ntcip.org/order/ 703-841-3231
bru_schopp@nema.org
Note: Order information is only available for published standards documents.
February 2001
Page 13 of 21
Title
NTCIP - Object
Definitions for
Environmental Sensor
Stations & Roadside
Weather Information
System
SDO and
Document
Number
AASHTO
1204
NTCIP - Object
Definitions for Video
Switches
AASHTO
NTCIP - Objects for
Signal Systems
Master
AASHTO
NTCIP - Point to MultiPoint Protocol Using
RS-232 Subnetwork
Profile
NTCIP - Profiles Framework and
Classification of
Profiles
1208
1210
AASHTO
2101
AASHTO
8003
Description
Web Address and
Order Information
Definitions of objects that are specific to environmental sensor
stations (ESS) and object groups which can be used for conformance
statements. The communication between remote entities and ESS is Order from
accomplished by using the NTCIP application layer services to
http://www.ntcip.org/order/
convey requests to access or modify values of ESS objects.
(Formerly TS 3.7) Amendment 1 is in ballot.
Contact
Bruce Schopp
NEMA
703-841-3231
bru_schopp@nema.org
Bruce Schopp
Deals with the data needed to control a video switch enabling multiple http://www.ntcip.org/library/ NEMA
monitors to view multiple video feeds.
703-841-3231
documents/
bru_schopp@nema.org
This standard will define the objects necessary to manage a field
master.
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
A set of data link and physical layer protocols applicable to roadside
devices. (Formerly TS 3.SP-PMPP232-1998)
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
A framework and classification scheme for developing combinations
and/or sets of protocols related to communication in an ITS
environment. (Formerly TS 3.PRO)
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
Note: Order information is only available for published standards documents.
February 2001
Page 14 of 21
Title
NTCIP - Ramp Meter
Controller Objects
NTCIP - Simple
Transportation
Management
Framework (STMF)
NTCIP - Simple
Transportation
Management Protocol
(STMP)
NTCIP - Subnet
Profile for PMPP Over
FSK modems
NTCIP - Subnet
Profile for Point-toPoint Protocol using
RS 232
SDO and
Document
Number
AASHTO
1207
AASHTO
1101
AASHTO
1103
AASHTO
2102
AASHTO
2103
Description
Web Address and
Order Information
Contact
Bruce Schopp
Specifications for objects that are specific to ramp metering controller http://www.ntcip.org/library/ NEMA
703-841-3231
operations. (Formerly TS 3.RMC)
documents/
bru_schopp@nema.org
A set of rules and protocols for organizing, describing and exchanging
transportation management information between transportation
Order from
management applications and transportation equipment such that
http://www.ntcip.org/order/
they interoperate with each other. (Formerly TS 3.2) Amendment 1 is
in ballot.
Bruce Schopp
NEMA
703-841-3231
bru_schopp@nema.org
Specifies a set of rules and procedures for exchanging information
Bruce Schopp
with a minimum of overhead to provide an interoperability standard for http://www.ntcip.org/library/ NEMA
transportation-related devices that operate over bandwidth-limited
703-841-3231
documents/
communications links. (Currently part of TS 3.2)
bru_schopp@nema.org
This standard defines how to communicate over twisted wire using
FSK modems. It may be used with any Transport Profile.
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
A subnetwork profile that defines requirements for the data link and
physical layers of a communications stack. It specifies the rules and
Bruce Schopp
procedures for using the point-to-point protocol over RS-232 related http://www.ntcip.org/library/ NEMA
circuits. The intent is to provide an interoperability standard for
703-841-3231
documents/
transportation-related devices that communicate over dial-up circuits.
bru_schopp@nema.org
(Formerly TS 3.SP-PPP/RS232)
Note: Order information is only available for published standards documents.
February 2001
Page 15 of 21
Title
NTCIP - Subnetwork
Profile for Ethernet
NTCIP Transportation
System Sensor
Objects
On-Board Land
Vehicle Mayday
Reporting Interface
Recommended
Practice for the
Selection and
Installation of Fiber
Optic Cable
Rules for
Standardizing Street
Names and Route IDs
SDO and
Document
Number
AASHTO
2104
AASHTO
1209
SAE
J2313
IEEE
P1454
SAE
J2529
Description
Web Address and
Order Information
Contact
A subnetwork profile that defines requirements for the data link and
physical layers of a communications stack. It specifies the rules and
procedures for using the IEEE Link Layer Control (802.2) and Media
Access Control (802.3) protocols over coaxial, twisted pair, or fiberoptic media. The intent is to provide an interoperability standard for
transportation-related devices that communicate over local area
network (LAN) interfaces. (Formerly TS 3.SP-Ethernet)
Bruce Schopp
http://www.ntcip.org/library/ NEMA
documents/
703-841-3231
bru_schopp@nema.org
Object definitions that are specific to and guide the data exchange
content between advanced sensors and other devices in an NTCIP
network. Advanced sensors include video-based detection sensors,
inductive loop detectors, sonic detectors, infrared detectors, and
microwave/radar detectors. (Formerly TS 3.EP- TSS)
Bruce Schopp
http://www.ntcip.org/library/ NEMA
703-841-3231
documents/
bru_schopp@nema.org
Order from www.sae.org,
A general specification that prescribes protocol methods which enable or call 724-776-4970.
vendors with different communication methods to communicate with
To link directly to SAE
response agencies in a standard format.
J2313, click here.
Guidelines for the installation approach, splicing, connecting of fiberoptic cable, and Description being developed. in urban, suburban,
and rural communication requirements as well as for transportation
operations centers.
Anita C. Ricketts
http://grouper.ieee.org/grou IEEE
732-562-3847
ps/scc32/index.html
a.ricketts@ieee.org
Specifies the rules for standardizing street names for use in ATIS and
www.sae.org
other ITS applications.
Note: Order information is only available for published standards documents.
February 2001
Richard Cox
SAE
724-772-4013
rcox@sae.org
Richard Cox
SAE
724-772-4013
rcox@sae.org
Page 16 of 21
Title
Serial Data Comm.
Between
MicroComputer
Systems in HeavyDuty Vehicle
Applications
Spec. for Dedicated
Short Range Comm.
(DSRC) Data Link
Layer: Medium
Access and Logical
Link Control
Spec. for Dedicated
Short Range Comm.
(DSRC) Physical
Layer using
Microwave in the 902928 MHz Band
Stakeholders
Workshop Information
Report
Standard for ATIS
Message Sets
Delivered Over
Bandwidth Restricted
Media
SDO and
Document
Number
SAE
J1708
ASTM
PS 105-99
Description
Defines a recommended practice for implementing a bi-directional,
serial communication link among modules containing
microcomputers. Defines those parameters of the serial link that
relate primarily to hardware and basic software compatibility such as
interface requirements, system protocol, and message format.
Specification for the protocol (data link) communications. Supports
both synchronous and asynchronous modes for operations.
Specification for the RF characteristics (physical layer) for DSRC
operating in the range of 902-928 MHz. Supports both active and
PS 111-98 backscatter transponders.
ASTM
SAE
J2373
SAE
J2369
Web Address and
Order Information
Order from www.sae.org,
or call 724-776-4970.
To link directly to SAE
J1708, click here.
Contact
Richard Cox
SAE
724-772-4013
rcox@sae.org
Order from www.astm.org,
Dan Smith
or call 610-832-9585.
ASTM
610-832-9727
To link directly to ASTM PS
dsmith@astm.org
105-99, click here.
Order from www.astm.org,
Dan Smith
or call 610-832-9585.
ASTM
610-832-9727
To link directly to ASTM PS
dsmith@astm.org
111-98, click here.
Richard Cox
Results of workshops to solicit and discuss stakeholder requirements www.sae.org/TECHCMTE/ SAE
724-772-4013
for location referencing standardization.
mapscop.htm
rcox@sae.org
A general framework allowing transmission of traveler information via
Richard Cox
www.sae.org/TECHCMTE/f SAE
bandwidth reduced media such as found in wireless applications.
Creates a uniform coding and message structure for link travel times, mscope.htm
724-772-4013
incident text, weather and transit for broadcast delivery.
rcox@sae.org
Note: Order information is only available for published standards documents.
February 2001
Page 17 of 21
Title
Standard for Common
Incident Management
Message Sets (IMMS)
for use by EMCs
Standard for Data
Dictionaries for
Intelligent
Transportation
Systems
Standard for
Functional Level
Traffic Management
Data Dictionary
(TMDD)
Standard for Message
Sets for
Vehicle/Roadside
Communications
Standard for Traffic
Incident Management
Message Sets for Use
by EMCs
SDO and
Document
Number
IEEE
Std 15122000
IEEE
Std 14891999
ITE
TM 1.03
IEEE
Std 14551999
IEEE
P1512.1
Description
Standards describing the form and content of the incident
management messages sets for emergency management systems
(EMS) to traffic management systems (TMS) and from emergency
management systems to the emergency telephone system (ETS) or
(E911).
Web Address and
Order Information
Contact
Order from
http://standards.ieee.org/ca Anita C. Ricketts
talog/its.html, or call 800- IEEE
678-IEEE
732-562-3847
a.ricketts@ieee.org
To link directly to IEEE
1512, click here.
Order from
http://standards.ieee.org/ca Anita C. Ricketts
A set of meta entities and meta attributes for ITS data dictionaries, as talog/its.html, or call 800IEEE
well as associated conventions and schemas, that enable describing, 678-IEEE
732-562-3847
standardizing, and managing all ITS data.
a.ricketts@ieee.org
To link directly to IEEE
1489, click here.
This document contains data elements for roadway links and for
incidents and traffic-disruptive roadway events. Includes data
elements for traffic control, ramp metering, traffic modeling, video
http://www.ite.org/tmdd/
camera control traffic, parking management and weather forecasting,
as well as data elements related to detectors, actuated signal
controllers, vehicle probes, and dynamic message signs.
James M. Cheeks, Jr.
ITE
202-289-0222 x131
jcheeks@ite.org
Order from
http://standards.ieee.org/ca Anita C. Ricketts
Standard messages for commercial vehicle, electronic toll, and traffic talog/its.html, or call 800- IEEE
678-IEEE
732-562-3847
management applications.
a.ricketts@ieee.org
To link directly to IEEE
1455, click here.
Enables consistent standardized communications among Incident
Management centers, fleet and freight management centers,
information service providers, emergency management centers,
planning subsystems, traffic management centers and transit
management centers.
Note: Order information is only available for published standards documents.
February 2001
Anita C. Ricketts
http://grouper.ieee.org/grou IEEE
732-562-3847
ps/scc32/index.html
a.ricketts@ieee.org
Page 18 of 21
Title
SDO and
Document
Number
Description
A flexible waveform defined for the physical and data link layers for
delivery of data to mobile and fixed users using a sub-carrier on a
broadcast FM station. It supports: ATIS message sets (SAE J2369);
differential GPS message sets defined by Radio Technical
Commission for Maritime Services Special Committee No. 104;
emergency alert system messages defined by CFR Title 47, Part 11;
and Retransmission of Radio Broadcast Data System data.
Web Address and
Order Information
Contact
Order from
http://www.global.ihs.com/,
or call Global Engineering
Documents at 800-8547179.
Jean Johnson
CEA
703-907-7972
jjohnson@ce.org
The survey and analysis of existing standards (and those under
IEEE
development) that include requirements for both wireline and wireless
Survey and Analysis
transmissions. Full title of this standard is "Survey and Analysis of
of Existing Standards
Bks 1-6:
Existing Standards and Those Under Development Applicable to the
and Communications
SH94633-SH
Needs of the Intelligent Transportation System (ITS) Short-Range and
Technologies
94638
Wide-Area Wireless Communications."
Order from
http://standards.ieee.org/ca
talog/its.html, or call 800678-IEEE
Anita C. Ricketts
IEEE
732-562-3847
a.ricketts@ieee.org
TCIP - Common
Public Transportation
(CPT) Business Area
Standard
James M. Cheeks, Jr.
http://www.ntcip.org/library/ ITE
202-289-0222 x131
documents/
jcheeks@ite.org
Subcarrier Traffic
Information Channel
(STIC) System
TCIP - Control Center
(CC) Business Area
Standard
TCIP - Fare Collection
(FC) Business Area
Standard
EIA/CEA
EIA-795
ITE
1401
ITE
1407
ITE
1408
Data objects for standard data types, data elements and messages
shared by, and common to other transit business areas. Includes
general data concepts related to vehicle, equipment and facility.
James M. Cheeks, Jr.
Data objects for transit management center functions related to
http://www.ntcip.org/library/ ITE
providing, monitoring and measuring real-time transit revenue service. documents/
202-289-0222 x131
jcheeks@ite.org
James M. Cheeks, Jr.
Data objects related to passenger fare collection, including cash,
electronic and non-electronic payment. Also provides output data to http://www.ntcip.org/library/ ITE
202-289-0222 x131
the fare media, processing of financial transactions, equipment status documents/
jcheeks@ite.org
and planning. (Formerly TS 3.TCIP-FC)
Note: Order information is only available for published standards documents.
February 2001
Page 19 of 21
Title
TCIP - Framework
Document
TCIP - Incident
Management (IM)
Business Area
Standard
TCIP - Onboard (OB)
Business Area
Standard
TCIP - Passenger
Information (PI)
Business Area
Standard
TCIP Scheduling/Runcutting
(SCH) Business Area
Standard
SDO and
Document
Number
ITE
1400
ITE
1402
ITE
1406
ITE
1403
ITE
1404
Description
Web Address and
Order Information
Contact
Framework document for business area object standards for transit
ITS. (Formerly TS 3.TCIP-FW)
James M. Cheeks, Jr.
http://www.ntcip.org/library/ ITE
202-289-0222 x131
documents/
jcheeks@ite.org
Data objects for detecting, verifying, prioritizing, responding to and
clearing unplanned events (accidents, weather conditions, crime,
etc.), as well as information for travelers. (Formerly TS 3.TCIP-IM)
James M. Cheeks, Jr.
http://www.ntcip.org/library/ ITE
202-289-0222 x131
documents/
jcheeks@ite.org
Data elements for onboard transit vehicle applications. Includes all
data for communications between onboard components within the
vehicle and other transit applications.
James M. Cheeks, Jr.
http://www.ntcip.org/library/ ITE
202-289-0222 x131
documents/
jcheeks@ite.org
Data objects relating to providing passengers (and potential
passengers) with information for planning and making public
transportation trips. Includes schedules, fares, on-line services, trip
planning and facility information.
James M. Cheeks, Jr.
http://www.ntcip.org/library/ ITE
202-289-0222 x131
documents/
jcheeks@ite.org
Data objects relating to scheduling and runcutting. Includes
James M. Cheeks, Jr.
requirements for master schedules, trip sheets, run guides, inventory http://www.ntcip.org/library/ ITE
files, etc., as well as output data for garage management, roadside
202-289-0222 x131
documents/
devices, performance history, etc. (Formerly TS 3.TCIP-SCH)
jcheeks@ite.org
Note: Order information is only available for published standards documents.
February 2001
Page 20 of 21
Title
TCIP - Spatial
Representation (SP)
Business Area
Standard
TCIP - Traffic
Management (TM)
Business Area
Standard
Trial-Use Standard for
Message Set
Template for
Intelligent
Transportation
Systems
Truth-in-Labeling
Standard for
Navigation Map
Databases
SDO and
Document
Number
ITE
1405
ITE
TS 3.TM
Description
SAE
J1663
Contact
James M. Cheeks, Jr.
Data objects for spatial representations to support other TCIP object
ITE
sets. Allows for the transfer of location of transit objects and includes http://www.ntcip.org/library/
202-289-0222 x131
primitive elements and complex objects.
documents/
jcheeks@ite.org
Data objects relating to traffic conditions including planned changes in
James M. Cheeks, Jr.
http://www.ntcip.org/library/
roadways and real-time traffic movement. This standard is based on
ITE
documents/
the ITE Traffic Management Data Dictionary and uses the TMDD data
202-289-0222 x131
elements for data flowing into the transit agency.
jcheeks@ite.org
IEEE
Std 14882000
Web Address and
Order Information
A standard for an ITS message set template. Approved for trial use
through June 2002.
This standard defines consistent terminology, metrics, and tests for
describing the content and quality of navigable map databases. (This
standard does NOT specify the physical format of the database or
minimum performance standards.) The focus of this document is to
support the navigation applications that automotive manufacturers
and suppliers are currently developing for marketplace delivery.
Note: Order information is only available for published standards documents.
February 2001
Order from
http://standards.ieee.org/ca Anita C. Ricketts
talog/its.html, or call 800- IEEE
678-IEEE
732-562-3847
a.ricketts@ieee.org
To link directly to IEEE
1488, click here.
Order from www.sae.org,
or call 724-776-4970.
To link directly to SAE
J1663, click here.
Richard Cox
SAE
724-772-4013
rcox@sae.org
Page 21 of 21
APPENDIX D
National ITS Architecture Definitions
1. National ITS Architecture Terms
Architecture Flow
Information that is exchanged between subsystems and terminators in the Physical
Architecture. Each architecture flow contains one or more data flows from the Logical
Architecture. These architecture flows and their communication requirements define the
interfaces which form the basis for much of the ongoing standards work in the ITS
program.
Center Subsystems
Subsystems that provide management, administrative, and support functions for the
transportation system. The center subsystems each communicate with other centers to
enable coordination between modes and across jurisdictions. The nine center subsystems
are Traffic Management, Transit Management, Commercial Vehicle Administration,
Archived Data Management, Emissions Management, Toll Administration, Emergency
Management, Information Service Provider, and Fleet and Freight Management. One of
four general subsystem classes defined in the National ITS Architecture.
Equipment Package
The building blocks of the Physical Architecture subsystems. Equipment Packages group
like processes of a particular subsystem together into an “implementable” package. The
grouping also takes into account the user services and the need to accommodate various
levels of functionality. The equipment packages were used as a basis for estimating
deployment costs (as part of the evaluation that was performed). Since equipment
packages are both the most detailed elements of the physical architecture and tied to
specific market packages, they provide the common link between the interface-oriented
architecture definition and the deployment-oriented Market Packages.
Logical Architecture
The Logical Architecture defines what has to be done to support the ITS User Services. It
defines the processes that perform ITS functions and the information or data flows that
are shared between these processes. The Logical Architecture was developed using
Structured Analysis techniques and consists of Data Flow Diagrams, Process
Specifications, and Data Dictionary Entries. The Logical Architecture has also been
called an "Essential Model" because it is not technology specific, nor does it dictate a
particular implementation. This implementation independence makes the logical
architecture accommodating to innovation, scalable from small scale implementations to
large regional systems, and supportive of widely varied system designs.
Market Package
The market packages provide an accessible, deployment oriented perspective to the
national architecture. They are tailored to fit - separately or in combination - real world
transportation problems and needs. Market packages collect together one or more
Equipment Packages that must work together to deliver a given transportation service and
the Architecture Flows that connect them and other important external systems. In other
words, they identify the pieces of the Physical Architecture that are required to
implement a particular transportation service. Because they were evaluated during the
architecture development, supporting benefits and costs analyses are also available for the
market packages.
Physical Architecture
The Physical Architecture provides agencies with a physical representation (though not a
detailed design) of the important ITS interfaces and major system components. It
provides a high-level structure around the processes and data flows defined in the Logical
Architecture. The principal elements in the Physical Architecture are the 19 subsystems
and architecture flows that connect these subsystems and terminators into an overall
structure. A physical architecture takes the processes identified in the logical architecture
and assigns them to subsystems. In addition, the data flows (also from the logical
architecture) are grouped together into architecture 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.
Roadside Subsystems
Intelligent infrastructure distributed along the transportation network which perform
surveillance, information provision, and plan execution control functions and whose
operation is governed by center subsystems. Direct interface to vehicle subsystems exist.
One of four general subsystem classes defined in the National ITS Architecture.
Terminator
Terminators define the boundary of the National ITS Architecture. The terminators
represent the people, systems, and general environment that interface to ITS. The
interfaces between terminators and the subsystems and processes within the National ITS
Architecture are defined, but no functional requirements are allocated to terminators. The
Logical and Physical Architectures both have exactly the same set of terminators. The
only difference is that Logical Architecture processes communicate with terminators
using data flows, while Physical Architecture subsystems use architecture flows.
Traveler Subsystems
Equipment used by travelers to access ITS services pre-trip and en-route. This includes
elements that are owned and operated by the traveler as well as elements that are owned
by transportation and information providers. One of four general subsystem classes
defined in the National ITS Architecture.
Vehicle Subsystems
Covers ITS related elements on vehicle platforms. Vehicle subsystems include general
driver information and safety systems applicable to all vehicle types. Three fleet vehicle
subsystems (Transit, Emergency, and Commercial Vehicles) add ITS capabilities unique
to these special vehicle types. One of four general subsystem classes defined in the
National ITS Architecture.
2. Applicable Market Package Definitions
Broadcast Traveler Information
This market package provides the user with a basic set of ATIS services; its objective is
early acceptance. It involves the collection of traffic conditions, advisories, general public
transportation, toll and parking information, incident information, air quality and weather
information, and the near real time dissemination of this information over a wide area
through existing infrastructures and low cost user equipment (e.g., FM subcarrier, cellular
data broadcast). Different from the market package ATMS6--Traffic Information
Dissemination--which provides the more basic HAR and DMS information capabilities,
ATIS1 provides the more sophisticated digital broadcast service. Successful deployment
of this market package relies on availability of real-time traveler information from
roadway instrumentation, probe vehicles or other sources.
CV Administrative Processes
This market package provides for electronic application, processing, fee collection,
issuance, and distribution of CVO credential and tax filing. Through this process,
carriers, drivers, and vehicles may be enrolled in the electronic clearance program
provided by a separate market package which allows commercial vehicles to be screened
at mainline speeds at commercial vehicle check points. Through this enrollment process,
current profile databases are maintained in the Commercial Vehicle Administration
Subsystem and snapshots of this database are made available to the commercial vehicle
check facilities at the roadside to support the electronic clearance process.
Dynamic Ridesharing
This market package enhances the Interactive Traveler Information package by adding an
infrastructure provided dynamic ridesharing/ride matching capability. In terms of
equipment requirements, ATIS8 is similar to ATIS7.
Electronic Clearance
This market package provides for automated clearance at roadside check facilities. The
roadside check facility communicates with the Commercial Vehicle Administration
subsystem over wireline to retrieve infrastructure snapshots of critical carrier, vehicle,
and driver data to be used to sort passing vehicles. This package allows a good
driver/vehicle/carrier to pass roadside facilities at highway speeds using transponders and
dedicated short range communications to the roadside. The roadside check facility may
be equipped with AVI, weighing sensors, transponder read/write devices, computer
workstation processing hardware, software, and databases.
Emergency Routing
This market package supports dynamic routing of emergency vehicles and coordination
with the Traffic Management Subsystem for special priority on the selected route(s). The
Information Service Provider Subsystem supports routing for the emergency fleet based
on real-time traffic conditions and the emergency routes assigned to other responding
vehicles. In this market package, the Information Service Provider Subsystem would
typically be integrated with the Emergency Management Subsystem in a public safety
communications center. The Emergency Vehicle would also optionally be equipped with
dedicated short range communications for local signal preemption.
Incident Management System
This market package manages 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 the
regional coordination with other traffic management and emergency management centers,
weather service entities, and event promoters supported by this market package.
Information from these diverse sources are collected and correlated by this market
package to detect and verify incidents and implement an appropriate response. This
market package provides Traffic Management Subsystem equipment that supports traffic
operations personnel in developing an appropriate response in coordination with
emergency management and other incident response personnel to confirmed incidents.
The response may include traffic control strategy modifications and presentation of
information to affected travelers using the Traffic Information Dissemination market
package. The same equipment assists the operator by monitoring incident status as the
response unfolds. The coordination with emergency management might be through a
CAD system or through other communication with emergency field personnel. The
coordination can also extend to tow trucks and other field service personnel.
Interactive Traveler Information
This market package provides tailored information in response to a traveler request. Both
real-time interactive request/response systems and information systems that "push" a
tailored stream of information to the traveler based on a submitted profile are supported.
The traveler can obtain current information regarding traffic conditions, transit services,
ride share/ride match, parking management, and pricing information. A range of two-way
wide-area wireless and wireline communications systems may be used to support the
required digital communications between traveler and the information service provider. A
variety of interactive devices may be used by the traveler to access information prior to a
trip or en-route to include phone, kiosk, Personal Digital Assistant, personal computer,
and a variety of in-vehicle devices. Successful deployment of this market package relies
on availability of real-time transportation data from roadway instrumentation, probe
vehicles or other means.
ITS Data Mart
This market package provides a focused archive that houses data collected and owned by
a single agency, district, private sector provider, research institution, or other
organization. This focused archive typically includes data covering a single transportation
mode and one jurisdiction that is collected from an operational data store and archived for
future use. It provides the basic data quality, data privacy, and meta data management
common to all ITS archives and provides general query and report access to archive data
users.
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.
Network Surveillance
This market package includes traffic detectors, other surveillance equipment, the
supporting field equipment, and wireline communications to transmit the collected data
back to the Traffic Management Subsystem. The derived data can be used locally such as
when traffic detectors are connected directly to a signal control system or remotely (e.g.,
when a CCTV system sends data back to the Traffic Management Subsystem). The data
generated by this market package enables traffic managers to monitor traffic and road
conditions, identify and verify incidents, detect faults in indicator operations, and collect
census data for traffic strategy development and long range planning. The collected data
can also be analyzed and made available to users and the Information Service Provider
Subsystem.
Parking Facility Management
This market package provides enhanced monitoring and management of parking
facilities. The included equipment assists in the management of parking operations,
coordinates with transportation authorities, and supports electronic collection of parking
fees. This is performed by sensing and collecting current parking facilities status, sharing
the data with information service providers and traffic operations, and automatic fee
collection using short range communications with the same in-vehicle equipment utilized
for electronic toll collection.
Regional Parking Management
This market package supports coordination between parking facilities to enable regional
parking management strategies.
Regional Traffic Control
This market package advances the Surface Street Control and Freeway Control Market
Packages by adding the communications links and integrated control strategies that
enable integrated Interjurisdictional traffic control. This market package provides for the
sharing of traffic information and control among traffic management centers to support a
regional control strategy. The nature of optimization and extent of information and
control sharing is determined through working arrangements between jurisdictions. This
package relies principally on roadside instrumentation supported by the Surface Street
Control and Freeway Control Market Packages and adds hardware, software, and
wireline communications capabilities to implement traffic management strategies which
are coordinated between allied traffic management centers. Several levels of coordination
are supported from sharing of information through sharing of control between traffic
management centers.
Road Weather Information System
This market package monitors current and forecast road and weather conditions using a
combination of weather service information and data collected from environmental
sensors deployed on and about the roadway. The collected road weather information is
monitored and analyzed to detect and forecast environmental hazards such as icy road
conditions, dense fog, and approaching severe weather fronts. This information can be
used to more effectively deploy road maintenance resources, issue general traveler
advisories, and support location specific warnings to drivers using the Traffic Information
Dissemination Market Package.
Roadside CVO Safety
This market package provides for automated roadside safety monitoring and reporting. It
automates commercial vehicle safety inspections at the Commercial Vehicle Check
roadside element. The capabilities for performing the safety inspection are shared
between this market package and the On-Board CVO Safety Market Package which
enables a variety of implementation options. The basic option, directly supported by this
market package, facilitates safety inspection of vehicles that have been pulled in, perhaps
as a result of the automated screening process provided by the Electronic Clearance
Market Package. In this scenario, only basic identification data and status information is
read from the electronic tag on the commercial vehicle. The identification data from the
tag enables access to additional safety data maintained in the infrastructure which is used
to support the safety inspection, and may also inform the pull-in decision if system timing
requirements can be met. More advanced implementations, supported by the On-Board
CVO Safety market package, utilize additional vehicle safety monitoring and reporting
capabilities in the commercial vehicle to augment the roadside safety check.
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. (Note
that passive systems exercise only the single interface between the roadway subsystem
and the driver in the architecture definition.) 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.
Health monitoring of the HRI equipment and interfaces is performed; detected
abnormalities are reported to both highway and railroad officials through wayside
interfaces and interfaces to the traffic management subsystem. Similar interfaces and
services are provided for other types of multimodal crossings (e.g., draw bridges).
Surface Street Control
This market package provides the central control and monitoring equipment,
communication links, and the signal control equipment that support local surface street
control and/or arterial traffic management. A range of traffic signal control systems are
represented by this market package ranging from static pre-timed control systems to fully
traffic responsive systems that dynamically adjust control plans and strategies based on
current traffic conditions and priority requests. Additionally, general advisory and traffic
control information can be provided to the driver while en-route. This market package is
generally an intra-jurisdictional package that does not rely on real-time communications
between separate control systems to achieve area-wide traffic signal coordination.
Systems that achieve coordination across jurisdictions by using a common time base or
other strategies that do not require real time coordination would be represented by this
package. This market package is consistent with typical urban traffic signal control
systems.
Traffic Information Dissemination
This market package allows traffic information to be disseminated to drivers and vehicles
using roadway equipment such as dynamic message signs or highway advisory radio.
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. This package also covers the equipment and interfaces that provide traffic
information from a traffic management center to the media (for instance via a direct tie-in
between a traffic management center and radio or television station computer systems),
transit management center, emergency management center, and information service
provider.
Transit Passenger and Fare Management
This market package allows for the management of passenger loading and fare payments
on-board vehicles using electronic means. The payment instrument may be either a stored
value or credit card. This package is implemented with sensors mounted on the vehicle to
permit the driver and central operations to determine vehicle loads, and readers located
either in the infrastructure or on-board the transit vehicle to allow fare payment. Data is
processed, stored, and displayed on the transit vehicle and communicated as needed to
the Transit Management Subsystem using existing wireless infrastructure.
Transit Security
This market package provides for the physical security of transit passengers. An on-board
security system is deployed to perform surveillance and warn of potentially hazardous
situations. Public areas (e.g. stops, park and ride lots, stations) are also monitored.
Information is communicated to the Transit Management Subsystem using the existing or
emerging wireless (vehicle to center) or wireline (area to center) infrastructure. Security
related information is also transmitted to the Emergency Management Subsystem when
an emergency is identified that requires an external response. Incident information is
communicated to the Information Service Provider.
Transit Traveler Information
This market package provides transit users at transit stops and on-board transit vehicles
with ready access to transit information. The information services include transit stop
annunciation, imminent arrival signs, and real-time transit schedule displays that are of
general interest to transit users. Systems that provide custom transit trip itineraries and
other tailored transit information services are also represented by this market package.