Chapter 16 – Regional Integration
Page 1 of 2
The basic institutional fabric of the surface transportation network
is multi-jurisdictional, multi-agency, multi-functional, and multi-modal.
This structure can lead to a fragmented delivery system for transportation
service. At the same time, the public (i.e., the "customers") generally
does not care which jurisdiction or agency is responsible for the road
or mode on which they are currently traveling. As taxpayers (and in some
cases fare / toll payers), they want and deserve a safe, reliable, and
predictable trip; and the ability to determine the real time operating
conditions of the network. To achieve this vision of a "seamless" transportation
network, the involved agencies and practitioners must recognize and address
the many inter-facility, inter-jurisdictional, and inter-modal dependencies.
As noted in the introduction to "Regional Planning for Operations Primer"
(Reference 1), an introductory document
that discusses a formal collaborative activity called "regional planning
"More than ever, the safe, reliable, and secure operation of our
Nation's transportation systems depends on collaboration and coordination
across traditional jurisdictional and organizational boundaries. Nowhere
is this more apparent than in our metropolitan regions where numerous
jurisdictions, agencies, and service providers are responsible for safely
and efficiently operating various aspects of the transportation system.
Many of these operations activities in a metropolitan region must cross
agency and jurisdictional boundaries to be successful. They may include
traffic incident management, emergency management, communications networks,
traveler information services, response to weather events, and electronic
payment services. These regional operations activities depend on collaboration,
coordination, and integration to be effective and truly benefit those
that use or depend upon the regional transportation system."
The integration of multiple systems within a region – creating an "Integrated
Transportation Management System" – provides for the "real-time sharing
of information between ITS based systems and the coordination of management
activities between transportation agencies, thereby enhancing system interoperability
and enabling an areawide view of the transportation network. These systems
and agencies provide for the management and operation of a variety of
different transportation facilities and functions, including freeways,
arterial streets, transit (bus and rail), toll facilities (e.g., bridges,
tunnels), airports and seaports, emergency service providers, commercial
vehicle operators, and information service providers" (Note: Definition
of an ITMS as developed by the Freeway Operations Committee of the Transportation
Regional integration allows agencies to exchange information and (with
authorization) issue commands to field devices. This enables any agency
to monitor conditions on other agencies' facilities, and to implement
coordinated responses to incidents and other changes in operating conditions
when needed. Such data exchange and coordinated response can be implemented
either manually or automatically. Potential applications of regional integration
in support of interagency coordination include:
- All agencies and systems providing real-time information to a shared
traveler information clearinghouse, where the information is combined
into a regional ATIS database for access by Information Service Providers
and by users (e.g., via the Internet).
- Freeway and traffic signal systems exchanging information regarding
mainline and ramp volumes and incidents such that the signal system
can change timing parameters to accommodate traffic diverting from the
freeway, and the freeway can adjust metering rates.
- Two or more traffic signal management systems exchanging information
to achieve coordinated operation of traffic signals across jurisdiction
- An emergency management system reporting an incident or emergency
condition to a freeway management system (and other systems), followed
by the sharing of incident / emergency status and management information
during the response / evacuation process.
- Freeway and surface street traffic management systems supplying information
to an emergency management center so that appropriate routes may be
identified for routing emergency vehicles and / or evacuations.
- Freeway management system informing adjacent and nearby transportation
management systems (e.g., freeway, signal, airport landside operations)
of a warning message just posted on a changeable message sign on the
freeway in response to a notification of an incident or other problem.
Additionally, similar messages may be displayed on CMS belonging to
other near-by agencies.
In essence, the goal of regional integration is to bring the operation
and management of the surface transportation network into a unified whole,
and to incorporate this singular management of the surface transportation
network with the management of the broader transportation network. Such
"synergy" between multiple systems and agencies is absolutely necessary
to achieve the vision of an efficient, effective, and seamless transportation
network – one where the various users perceive it as being under single
ownership and management. In fact, the definition of the word "synergy"
aptly describes the goal of regional integration. From the Greek word
"synergos" (working together), it refers to the interaction of discrete
agencies and their systems such that the total effect is greater than
the sum of the individual effects.
16.1.1 Purpose of Chapter
As noted in Chapter 2, the surface transportation
network can be "integrated" in many ways – physical, technical, operational,
institutional, and procedural. This chapter focuses on the aspect of "technical
integration", including network topologies, database considerations, related
elements of the National ITS Architecture, standards for message sets
and protocols, etc. that enable different management centers (e.g., transportation,
emergency services, information providers) to readily (and automatically)
exchange, store, and access information from one another – a process known
as "center-to-center" communications.
The technical aspects of regional integration must not be viewed in isolation
from other considerations. Information sharing is a collaborative effort,
geared towards identifying problems, coordinating activities, and planning
for future investment needs. Technical integration can therefore not occur
without institutional integration (e.g., the various agencies agreeing
on the need to share information, their respective roles, the information
to be shared, standards). Accordingly, the institutional issues associated
with regional integration are also discussed herein. Beyond technical
and institutional integration, successful regional operations also depend
on procedural integration (e.g., coordinated planning and programming
processes that address the entire surface transportation network as a
whole) as discussed in Chapter 2. Moreover, after the information has
been exchanged between TMCs, something useful needs be done with it (e.g.,
coordinated incident management, regional traveler information, adjusted
signal timing and ramp metering rates) – that is, there must be operational
integration as discussed in nearly every chapter (as it relates the chapter
The reader is advised of another FHWA document entitled "Coordinated
Freeway and Arterial Operational Plans and Procedures". This technical
reference provides direction, guidance, and recommended practices related
to the coordinating and managing traffic on freeways and surface streets
for a range of typical re-current and non-recurrent congestion causing
16.1.2 Relation to Other Freeway Management Activities
Regional integration, and the creation of an ITMS, involves a variety
of activities that support and complement a freeway management and operations
program. Integrated transportation management systems and the associated
regional organizations (where they exist) develop policies and plans intended
to manage and operate systems and programs in a coordinated fashion. Practically
every freeway management strategy discussed in previous chapters is improved
– often dramatically – by regional integration. In fact, the real-time
information sharing supported by regional integration (and the associated
multi-agency coordination) is essentially a prerequisite for the success
of several freeway management strategies, including traffic incident management
(Chapter 10), planned special event management
(Chapter 11), emergency evacuation management
(Chapter 12), and information dissemination
(Chapter 13). The focal points of regional
integration are typically the transportation management centers (Chapter
14) and their respective information as collected by surveillance
subsystems (Chapter 15). Moreover, the
real-time exchange of this information between centers requires appropriate
communication links (Chapter 17).
18.104.22.168 Regional Planning for Operations
Regional planning for operations – a formal collaborative activity discussed
in Reference 1 (and summarized in Chapter 2 herein) – and regional integration
are closely linked. As stated in the reference (i.e., "Regional Planning
for Operations Primer"): "regional planning for operations relies heavily
on information sharing among regional operators and other agencies and
organizations that affect or interact with transportation facilities (e.g.,
public safety, goods movement)". The primer includes the figure below,
the shaded areas of which show aspects of information/data sharing (as
provided by regional integration) on which regional planning for operations
primarily relies. Specific considerations include:
- The strategic thinking associated with planning for operations requires
data accumulated over time, that can be mined to discover relationships,
trends, and opportunities, and that can then be acted upon. For example,
a regional traffic incident management strategy requires collection
and analysis of real-time data over time in order to learn where incidents
occur, what response is needed, where response assets should be positioned,
and how regional agencies and authorities can best collaborate to provide
the most effective response possible (1).
- The needed analyses depend on meaningful performance data and a reliable
estimate of future requirements based on historical trends and knowledge
of future requirements. These analyses enable operators regionwide to
evaluate options for achieving agreed-upon performance levels (1).
- The information generated by the analysis is used in outreach and
education efforts to bring all stakeholders to a common plan or concept
of operations. The regional concept of operations drives decision making
(e.g., roles and responsibilities, multilateral operating agreements,
standards, and protocols) among jurisdictions and agencies that enables
the operators to implement improved practices (1).
16.2 Current Practices, Methods, Strategies, & Technologies
The technical integration of two or more systems – thereby creating
an Integrated Transportation Management System (ITMS) – involves the implementation
of interfaces and communication links between the systems that permit
them to exchange information, exchange control status, and / or exchange
control commands. This type of communication is referred to as "center-to-center",
and typically involves peer-to-peer communications between any number
of systems (computers) in what is called a balanced, many-to-many network.
This type of communication is similar to the Internet, in that any center
can request information from, or provide information to, any number of
While reaching the vision of ITMS was difficult in the past, it is now
very possible – at least in terms of technical integration – due to the
development of various tools including intelligent transportation systems,
a national architecture, and the necessary standards to support ITMS.
ITS provides the tools to allow operating agencies to share information
and resources, and to provide coordinated operations. The National ITS
Architecture and associated standards facilitate sharing information and
coordinated operations because the meaning of various data elements is
known and consistent across agencies.
An ITMS (and the concomitant sharing of real-time information and coordination
of operations between multiple transportation agencies) requires a Regional
ITS Architecture, which is defined in a FHWA Rule 940 (Reference
2) as "a regional framework for ensuring institutional agreement and
technical integration for the implementation of ITS projects or groups
of projects". This rule, which became effective in April 2001, requires
that the National ITS Architecture be used to develop a local implementation
of the National ITS Architecture. The local implementation is referred
to as a "regional ITS architecture". The rule states that "the
regional ITS architecture is based on the National ITS Architecture and
consists of several parts including the system functional requirements
and information exchanges with planned and existing systems and subsystems
and identification of applicable standards, and would be tailored to address
the local situation and ITS investment needs." Rule 940 identifies what
the regional architecture shall include as a minimum – specifically:
- A description of the region;
- Identification of participating agencies and other stakeholders;
- An operational concept that identifies the roles and responsibilities
of participating agencies and stakeholders in the operation and implementation
of the systems included in the regional ITS architecture;
- Any agreements (existing or new) required for operations, including
at a minimum those affecting ITS project interoperability, utilization
of ITS related standards, and the operation of the projects identified
in the regional ITS architecture;
- System functional requirements;
- Interface requirements and information exchanges with planned and
existing systems and subsystems (for example, subsystems and architecture
flows as defined in the National ITS Architecture);
- Identification of ITS standards supporting regional and national
- The sequence of projects required for implementation.
Several terms are regularly used when describing regional integration
and regional architectures, including:
- Architecture – In the context of ITS, an "architecture"
describes what a system does and, from a high-level perspective, how
it does it. It provides the overall framework for system design and
deployment; identifying the functions and operations to be performed,
the basic subsystems and elements that make up the system and what functions
each performs, and the flows of information between these components.
In essence, an ITS architecture defines how system elements interact
and work together to achieve system goals. From a regional perspective,
a regional ITS architecture is concerned with what types of information
are exchanged among transportation agencies and their respective transportation
management systems and centers, how the center-to-center connections
are accomplished, and the additional functionality this integrated information
provides to users.
- Data Dictionary / Message Sets – In order to share
data across subsystems and between systems, a standardized data dictionary
is necessary. A data dictionary provides a rigorous, unambiguous definition
of the form of data that will be stored in a computer or other processor.
It includes items such as: a unique descriptive name, a domain-specific
description, range of values, permissible values, minimum and maximum
size, relationship to other data elements in the data dictionary, data
type of element (integer, real, character), format, etc. Data dictionary
elements are bundled into messages that can be transferred between computers.
These messages comprise the data flows within the architecture. Without
a standardized data dictionary, a uniform interpretation of messages
and their meanings is not possible. In a simple analogy, message sets
are the sentences, whereas the data elements in the dictionary are the
- Protocols – A protocol may be defined as a set of
rules or conventions formulated to govern the exchange of information
(i.e., data, messages) between two computers or two processes within
a computer. Basic elements of a protocol include data format, message
sequence, and maintenance of data integrity. Continuing the analogy
from above, human speech is a form of protocol typically involving half-duplex
communications (i.e., one person speaks while the other listens, and
vice versa), an agreed-upon format (i.e., an alphabet, vocabulary, and
the associated rules of grammar), an interspeaker delay (i.e., typically
a minimum amount of time elapses after one person stops speaking and
another begins), and error handling (i.e., "excuse me, what did you
- Interfaces – An interface is the point at which systems
and centers within the architecture interact. An interface device is
typically a combination of hardware and/or software—sometimes
referred to "middleware"—that receives information in one protocol
or format, and converts it to another protocol or format as required.
If a protocol is considered a language, then the interface may be thought
of as a translator—receiving information from one system, and
transforming this information into a format (or protocol) which can
be understood by the receiving system, while retaining the original
meaning or content of the information. In essence, the interface device
permits disparate components in a system or network of systems to exchange
meaningful and useful information.
Regional coordination from an operational and organizational perspective
is not new. A simple example of the benefit of organizational integration
occurred recently in San Antonio, Texas. After a training session on incident
management, the operators of the San Antonio Freeway Management System
observed about a 40 percent reduction in the clearance time of a major
incident due to improved organization.
On the other hand, technical integration of TMCs to enhance multi-agency
coordination is relatively new, and little quantifiable data exists regarding
these specific benefits. FHWA Rule 940 (Reference
2) states: "Information technology in general is most effective and
cost beneficial when systems are integrated and interoperable. The greatest
benefits in terms of safety, efficiency, and costs are realized when electronic
systems are systematically integrated to form a whole in which information
is shared with all and systems are interoperable."
16.2.3 Key Considerations During Freeway Management Program Development
Freeway management and regional integration have a symbiotic relationship.
Regional integration (and the concomitant regional architecture) must
be a key consideration in the process to develop a freeway management
and operations program. Likewise, freeway management will play a critical
role in the development and implementation of a regional architecture.
In essence, freeway management solutions should be incorporated into the
regional architecture; and regional integration should be incorporated
into the freeway management and operations program.
The "Regional ITS Architecture Guidance Document" (Reference
3) provides a systems engineering process for developing a regional
ITS architecture in support of regional integration. This process, summarized
in Table 16-1, parallels many of the activities identified in Chapter
3 (i.e., the "funnel diagram" in Figure 3-1) for a successful freeway
management and operations program. Some of the similarities are summarized
Table 16-1: Steps for Developing a Regional ITS
Architecture (Reference 3)
Step #1: Get Started
- Identify Need
- Define Region
- Identify Stakeholders
- Identify Champions
Step #2: Gather Data
- Inventory Systems
- Determine Needs and Services
- Develop Operational Concept
- Define Functional Requirements
Step #3: Define Interfaces
- Identify Interconnects
- Define Information Flows
Step #4: Implementation
- Define Project Sequencing
- Develop List of Agency Agreements
- Identify ITS Standards
Step #5: Use the Architecture
Step #6: Maintain the Architecture
- Get Started: Per Reference
3: "The regional ITS architecture effort begins with a focus on
the institutions and people involved. Based on the scope of the region,
the relevant stakeholders and one or more champions are identified".
A similar start (i.e., institutional environment, stakeholders) is also
required for a freeway management program.
- Identify Need: Reference
3 describes this step as follows: "The development and maintenance
of a regional ITS architecture is established as a shared objective
by the transportation planning and operating agencies in the region.
The decision to proceed then should actually be based on a clear understanding
and commitment by planning agencies, operating agencies, and key decision
makers in the region that a regional ITS architecture is needed and
will be put to good use. This implies that a decision to proceed should
be accompanied by significant outreach and education on the benefits
of system integration and the important role that a regional ITS architecture
can play in developing these integrated systems." By replacing the term
"regional ITS architecture" with "freeway management program", this
description could be used in Chapter 3 to describe the "Needs and Services"
activities of the funnel diagram.
- Identify Stakeholders: The success of the regional
ITS architecture depends on participation by a diverse set of stakeholders.
The stakeholders in the regional surface transportation system are identified
and the process of encouraging their participation in the regional ITS
architecture development process is initiated. Without management support,
it will be difficult or impossible for those with a working knowledge
of ITS in the region to participate effectively in the regional ITS
architecture effort. (3).
The same is true for freeway management and operations. As noted in
Chapter 3, the stakeholders are sources
of the vision, goals and objectives, and requirements, and they are
also ones who validate or verify the requirements. Stakeholders should
include representatives from each and every "tier" (as discussed in
chapter 2), including managers from all the centers that will be connected
together in some manner within the regional ITS architecture; those
individuals that will be responsible for managing and operating the
resulting ITMS, including the development and approval of regional response
plans; the managers within those agencies that will be impacted by the
regional architecture in some fashion, and who have a strong material
interest in success or failure of regional coordination and integration;
individuals who are involved in the statewide / regional planning processes,
thereby establishing closer links between the regional architecture
and the metropolitan transportation planning and decision-making processes
governed by Federal law; and the national tier (e.g., FHWA division)
to help ensure compliance with Rule 940.
- Develop Operational Concept: Just as a freeway management
program (and the freeway management system TMC) requires a Concept of
Operations, so does the regional ITMS. Reference 3 describes this step
as follows: "Each stakeholder's current and future roles and responsibilities
in the implementation and operation of the regional systems are defined
in more detail. The operational concept documents these roles and responsibilities
for selected transportation services in specific operational scenarios.
It provides an "executive summary" view of the way the region's systems
will work together to provide ITS services. The objective is to identify
current and future organizational roles in the regional transportation
system. Some operational concepts will focus on a definition of each
stakeholder's general role in providing the transportation services
in the region. More detailed operational concepts may include a more
detailed discussion of how stakeholders will interact to provide specific
transportation services." In essence, the regional Concept of Operations
lays out the ITMS concept, explains how things are expected to work
once it's in operation, and identifies the responsibilities of the various
stakeholders for making this happen. Moreover, the concept of ITMS operations
should include the performance expectations for the regional network.
(Note – Additional information on developing a Concept of Operations
document is provided in Chapter 14).
- Define Functional Requirements: Reference
3 defines this activity as follows: "The tasks or activities (the
"functions") that are performed by each system in the region are defined,
documenting the share of the work that each system in the region will
do to provide the ITS services. The functional requirements are high-level
descriptions of what the systems will do, not detailed design requirements."
This is essentially identical to the activity described in Chapter
3 as "Decisions Regarding Improvements, Systems, etc."
Rule 940 also states that all ITS projects (funded with highway trust
funds) shall be based on a "systems engineering analysis", and that this
analysis shall include identification of participating agencies, requirements
definition, analysis of alternative system configurations and technology
options, procurement options, identification of applicable standards and
testing procedures, and procedures and resources necessary for operations
and management of the system. Additional information on the systems engineering
process is provided in Chapter 14.
The last step from Reference 3 (i.e., Step #6: Maintain the Architecture)
states: "The regional ITS architecture is not a static set of outputs.
It must change as plans change, ITS projects are implemented, and the
ITS needs and services evolve in the region. A plan should be put in place
during the original development of the regional ITS architecture to keep
it up to date. This process is really one of Configuration Control and
Change Management. Some of the key aspects of the process are:
- Determine who will be responsible for architecture maintenance
- Define the architecture baseline
- Define the change management process
- Document the process in a Maintenance Plan."
Additional information on the configuration management (CM) process – the procedures and techniques that allow the practitioner to consider
and evaluate the impacts of proposed changes, and then to track and document
those changes that are made – is provided in Chapter 14. It is also noted
that the CM issue in a multi-jurisdictional environment is exponentially
more complex (as compared to a single system) with issues related to leadership,
roles and responsibilities, level of authority of the CM team, funding
requirements and funding sources, etc.
22.214.171.124 Performance Monitoring and Evaluation
The process described in Reference 3 (and summarized in previous Table
16-1) for developing a regional ITS architecture does not
include any consideration of performance measures and evaluation (Note:
Performance monitoring and evaluation is discussed in Chapter 4). It
probably should. As noted in Reference 1, regional integration, and the
associated information sharing and storage, is a key attribute for successful
performance monitoring and evaluation. Additionally, given that a major
goal of regional integration is for the entire surface transportation
network to be operated such that users perceive it as being under single
ownership and management, performance measures should be developed to
reflect this, permitting the enhanced operations made possible by regional
integration to be properly evaluated.
Qualitative assessment criteria should also be considered. FHWA's "Self-Assessment Process for Roadway Operations and System Management" (Reference
4) is a tool by which agencies with traffic operations responsibility
can assess the effectiveness of their existing roadway operations processes,
both in terms of its internal processes and the degree to which it serves
its customers. The Self-Assessment tool includes an "Integration" Category
for evaluating how well the agency's operations are coordinated and integrated
with those of other modes and jurisdictions, and with "sister" organizations
within the agency. Specific areas of the self-assessment are summarized
in Table 16-2.
Table 16-2: Self-Assessment Criteria for Regional
Integration (Reference 4)
- Coordination – The quality of your agency's
coordination with other agencies and organizations, including:
- Does your agency meet regularly with other agencies and
- During these meetings, do you discuss operational issues
of common interest?
- Do you discuss sharing of personnel and resource sharing
(communications facilities, equipment required for emergencies,
- Have you executed memoranda of understanding defining responsibilities
during periods for which operational coordination is required?
- Have you practiced the coordinated operations under controlled
- Do you review, discuss, and act upon the results of coordinated
operations following major events or activities?
- Integration of Operations – The quality of
your agency's concept of operations, including:
- Has your agency participated in the development of a regional
concept of operations that defines the operational responsibilities
of all agencies and organizations in the region under various
types of incident and non-incident conditions?
- Does this concept of operations describe the interactions
between the agencies and organizations?
- Is the concept of operations reviewed and updated periodically?
- Have memoranda of understanding been executed by the participants
that ensures management acceptance and support of the concept?
- Is the concept of operations consistent with the regional
- Integration and Coordination of Routine Operations
– The degree to which the agency's routine operations activities
are coordinated with other agencies, including:
- Are equipment failures (e.g. signal failures, etc.) reported
by personnel of other agencies?
- Are signal system operations coordinated across jurisdictional
- Is guide signing consistently installed with consistent
messages across jurisdictional boundaries?
- Are speed limits coordinated across jurisdictional boundaries?
- Data and Information Integration – The degree
to which your agency recognizes the importance of shared information,
and takes steps to facilitate this sharing.
- Does your agency share both periodic and real-time information
with other agencies (including traffic data, incident information,
planning information, deployment of field unites, etc.)?
- Does your agency transfer information between its computer
traffic management, dispatch and other systems, with those
of other agencies?
- Are there direct telephone lines between your agency and
relevant dispatch centers and traffic management centers of
- Does your agency participate in an integrated Internet
display of regional traffic information?
- Are methods for sharing of critical information clearly
defined and well understood by operations personnel?
- Integration of System Planning and Designs
– The degree of integration that occurs during the planning, design,
and implementation of new traffic management and/or dispatch systems,
such as the inclusion of other agencies and organizations in the
planning process; and the plans reflecting the requirements and
services needed by other agencies.
- Do your plans include information sharing with other agencies?
- Do your plans make use of relevant information technology
- Do your plans follow the guidance of the National ITS Architecture
or a regional ITS architecture?
- Do your plans include integration with legacy systems existing
in the region, whenever applicable?
16.2.4 Relationship to National ITS Architecture
Integrated systems operation is a core element of the national Intelligent
Transportation Systems (ITS) architecture. Regional integration may be
shown diagrammatically as the links / interconnects between the 10 "center"
subsystems, defined by the National ITS Architecture (Reference
5, and shown on the high-level diagram in previous Figure 3-4) as
- Commercial Vehicle Administration – Sells credentials
and administers taxes, keeps records of safety and credential check
data, and participates in information exchange with other commercial
vehicle administration subsystems and CVO Information Requesters.
- Fleet and Freight Management – Monitors and coordinates
vehicle fleets including coordination with intermodal freight depots
- Toll Administration – Provides general payment administration
capabilities to support electronic assessment of tolls and other transportation
- Transit Management – Collects operational data from
transit vehicles and performs strategic and tactical planning for drivers
- Emergency Management – Coordinates response to incidents,
including those involving hazardous materials (HAZMAT).
- Emissions Management – Collects and processes pollution
data and provides demand management input to Traffic Management.
- Archived Data Management – Collects, archives, manages,
and distributes data generated from ITS sources for use in transportation
administration, policy evaluation, safety, planning, performance monitoring,
program assessment, operations, and research applications
- Traffic Management – Processes traffic data and
provides basic traffic and incident management services through the
Roadside and other subsystems.
- Information Service Provider – This subsystem may
be deployed alone (to generally serve drivers and/or travelers) or be
combined with Transit Management (to specifically benefit transit travelers),
Traffic Management (to specifically benefit drivers and their passengers),
Emergency Management (for emergency vehicle routing), Parking Management
(for brokering parking reservations), and/or Commercial Vehicle Administration
(for commercial vehicle routing) deployments. ISPs can collect and process
transportation data from the aforementioned centers, and broadcast general
information products (e.g., link times), or deliver personalized information
products (e.g., personalized or optimized routing) in response to individual
- Maintenance and Construction Management – This subsystem
monitors and manages roadway infrastructure construction and maintenance
activities, including managing, dispatching, and routing fleets of maintenance,
construction, or special service vehicles (e.g., snow and ice control
equipment). The subsystem participates in incident response by deploying
maintenance and construction resources to an incident scene, in coordination
with other center subsystems. The subsystem manages the repair and maintenance
of both non-ITS and ITS equipment.
It is emphasized that these Center Subsystems are functionally, not physically
defined. They should not be viewed as "brick and mortar" facilities. Rather,
they represent a cohesive set of functional definitions with required
interfaces to other Subsystems. The implementation of a physical TMC will
often collocate the functions and capabilities from several of the Center
Market Packages relevant to regional integration include "Multi-modal
Coordination" (i.e., establishes two way communications between multiple
transit and traffic agencies to improve service coordination) and "Regional
Traffic Control" (i.e., sharing of traffic information and control among
traffic management centers to support a regional control strategy). Given
the diversity of systems (and their associated TMCs) in use, standards
are being developed to facilitate communications between these centers.
These "C2C" standards are discussed later.
16.2.5 Technologies and Strategies
The appropriate technologies and strategies will depend on the degree
of integration and how the exchange information will be utilized, as determined
by the stakeholders. Various levels of interaction are possible, for example:
- Communicate via phone, fax
- Share system data / video on "view only basis"
- Share system data / video control during special events
- Share system data / video control day-to-day
- Share system control during emergencies, or during periods when a
TMC is not staffed
- Centralize some / all system functions
As one moves down the above list, the level of human involvement in the
actual exchange and processing of information becomes less and less. In
fact, the first bullet – "communicate via phone / fax" – may be deemed
a "manual architecture", in that it relies completely on human involvement
throughout the information exchange process (e.g., an operator at one
center calling up or faxing an individual at another center. An "automated
architecture" refers to processes where human involvement is minimized,
if not completely eliminated, from the center-to-center exchange and processing
of information; although the pre-planning, management, and real time use
of this shared information undoubtedly requires a significant level of
human interaction and decision-making.
The rest of this section focuses on the more automated means of regional
integration, where information is transmitted computer-to-computer
and included (integrated) into one another's databases, processing, and
displays; noting that a wide variety of permutations exist between manual
and fully automated. For example, it may not always be possible or cost-effective
to achieve full integration of the exchanged data, in which case, simpler
alternatives for information exchange, minimizing the interface requirements
(i.e., "semi-automated"), should be considered; such as:
- Existing computer outputs and displays, such as a remote workstation
located at other centers (or a display window on the other centers'
workstations that can act as a remote workstation)
- Email interface, in which an email window is available at each operator's
workstations for the exchange of text messages
- Browser-based interface, for displaying HTML (web-like) pages of
information. These pages can be developed for the display of dynamic
data such as congestion maps, incident information, and other displays
Regardless of the degree of automation and advanced technology used in
a regional architecture, the importance of maintaining a reliable "manual
architecture" cannot be overemphasized. Regional integration and multi-agency
coordination can be significantly enhanced with technology and automation;
but as is discussed at the end of chapter 2,
it is good human relations that enable such "technical" processes in the
first place, and then keep them working effectively to achieve the overall
vision of an ITMS encompassing the entire surface transportation network.
If the managers representing the various agencies and TMCs within a region
have good communications, empathy, honesty, and trust between one another,
then regional coordination is almost assured, regardless of whether the
process involves phone calls, automated center-to-center linkages, or
some combination thereof.
Regional Integration is more than drawing a straight line between two
centers on an architecture diagram. Many technical roadblocks may exist
and many technical issues need to be resolved, including legacy systems,
network topologies and communications, data and message compatibilities,
protocols, and data fusion.
126.96.36.199 Legacy System
Regional integration will often involve a mix of new systems and legacy
systems. A legacy system is, by definition, currently operational; and
may represent the latest technology embodying the principles of open architecture,
or may be a closed system with proprietary interfaces, databases, and
protocols, as well as limited documentation. In the latter case (i.e.,
proprietary), full center-to-center integration may not be possible, in
which case a simpler system interface (e.g., separate workstation, email
/ browser interface as noted above) may be the most appropriate approach.
Even if the legacy system is not completely "closed" (as compared to an
"open" systems architecture), it still may be necessary to add a data
exchange protocol to the legacy system to facilitate information exchange.
A topology is defined as the structure of a system defining the paths
and switches that provides the communications interconnection among the
nodes (computers and TMCs) of a network, and defines the functional responsibilities
of each node. It is an axiom of network design that the relationship between
computers should mimic the organization it serves. Several topologies
exist, but given this axiom, the most likely to be found in a regional
center-to-center network are hierarchical and mesh, as summarized below:
- In a hierarchical organization, the "boss" should
have access to the top computer in the network. This computer will not
"know" all the details of the organization, but should be capable of
accumulating summary / management level information. Such a topology
might be used where a regional organization exists that oversees and/or
coordinates "regional" issues (e.g., a major incident or special event
where the impacts cross multiple jurisdiction boundaries) on an on-going
basis; or for a Statewide system where individual DOT districts maintain
most of the day-to-day operational autonomy, but headquarters staff
may assume management direction and control during major events.
- A mesh organization is one in which all participants
are peers. All computers in the mesh can essentially access the same
types of information. This type of communications is similar to the
Internet, in that any center can request information from, or provide
information to, any number of centers. This is the likely approach for
a multi-agency architecture where no regional operating entity exists
– that is, all centers must interact on an equitable basis. However,
even in a peer-to-peer topology, there may be restrictions on the
types of information that can be accessed by certain participants (e.g.,
control of individual devices).
The decision as to which topology to use requires an engineering analysis
– considering cost, maturity, expandability, reliability, availability,
maintainability, – combined with the objectives and requirements of the
region's entities (e.g., the types of information to be exchanged, and
how often), and the organizational compatibility. In some cases, a mix
of topologies may be appropriate – for example, data flows conforming
to the mesh organization, whereas control may be implemented by a hierarchical
Center-to-center communications requires network connections between
the involved computers. This is typically a local area network, a wide
area network, or a dial-up connection. Local area networks typically use
agency-owned twisted pair cable or fiber optic cable. Wide area networks
typically use commercial telecommunications links such as frame-relay;
partial T1 leased lines, packet radio, or leased "virtual private networks".
Dial-up connections typically use ISDN, V.90 or similar modems over plain-old
telephone lines. Any type of communication link can be used, as long as
it enables use of the Internet transport and routing protocols (e.g.,
TCP/IP) and has sufficient bandwidth for the planned communications load
(frequency and size of messages to be transmitted). Additional information
on communications alternatives is provided in Chapter
188.8.131.52 Data Compatibilities
A key issue in regional integration involves data compatibilities – that is, are all the data elements defined in exactly the same way. It
is essential that there be perfect understanding between the interfaced
systems as to the meaning of the data (both status and control information)
being exchanged. For example, when transmitting real time information
about travel conditions on the links comprising the surface transportation
network, each link must be precisely defined, including the link's location,
direction, start / endpoints, numbering system, type of facility; and
what the associated information means (e.g., average speed, travel time,
delays) and the units of measurement (e.g., seconds or minutes; feet,
miles, or kilometers).
Solutions for achieving compatibility between the databases of different
- Identical database formats in all systems within the regional architecture
(an unlikely solution for multiple agencies)
- A centralized gateway processor that receives all data and translates
the information before transmitting to receiving systems. This requires
that some form of traffic information network data base structure be
defined and maintained in one of the transportation management systems
(typically a freeway management system) within the region, or in a separate
system, and to which all systems contribute and utilize data. Preferably,
this data base structure would utilize the standard data definitions
from ITS data dictionaries.
- Common message sets and formats communicated using protocol converter
/ translator (middleware). With respect to this approach, NTCIP (Note:
National Transportation Communications for ITS Protocol) standards are
being developed for peer-to-peer communications between systems.
In addition to the NTCIP C2C standards, ITE and AASHTO have been jointly
sponsoring the development of the Traffic Management Data Dictionary
(TMDD) and the Message Sets for External Traffic Management Center Communications
(MS/ETMCC). A summary of these standards is provided below.
184.108.40.206 NTCIP Center-to-Center Protocols
A key feature of the NTCIP protocols is their support for continuous,
automated transmissions of information. Any center can request information
from, or provide information to, any number of systems. Each system can
be configured to either accept or reject any request. The "data" sent
can be informational or can constitute a "command" to take some action.
The user can also establish standing subscriptions for data, if it wants
the same data sent repeatedly.
The data exchanges are based on the Internet Protocol (IP), thereby allowing
for the use of a variety of off-the-shelf equipment as well as the use
of virtually any technology without additional work for the ITS Standards
effort. However, the selection of IP does not provide a complete answer
for defining how data are exchanged. NTCIP originally provided two alternative
protocol choices for center-to-center communications – DATEX and CORBA.
These two different protocols were found necessary to meet the variety
of requirements for inter-system data exchanges. More recently, there
has been increased interest in using XML and related technologies for
center-to-center links due to its simplicity and wide accessibility of
tools to provide these services (7).
While an in-depth discussion of these protocols is beyond the scope of
this Handbook, they are briefly described below (Note: Additional information
can be found at the NTCIP website (www.ntcip.org),
including the NTCIP Guide (Reference 6)
and periodic newsletters (Reference 7)):
- Data Exchange Between Systems (DATEX) – DATEX uses
pre-defined messages transmitted by the base Internet protocols (TCP/IP
and UDP/IP) in a peer-to-peer network. The base standard at the application
level is an ISO standard called DATEX-ASN. DATEX-ASN is based on a traditional,
structured messaging model and is an enhancement of the DATEX model
currently in use in Europe for all international and some intranational
exchanges of traffic information. DATEX was designed to provide simple,
cost-effective solutions for basic needs. It is especially well suited
for systems requiring real-time, fast data transfer (e.g. traffic signal
status data); systems with limited communications bandwidth but high
data transfer load; and non-object oriented systems
- Common Object Request Broker Architecture (CORBA)
– CORBA is a general purpose center-to-center communications protocol
based on the information technology (IT) industry standard of the same
name. CORBA provides several features to support computer networks connecting
object-oriented systems – and assuming sufficient processing power and
communications bandwidth are provided – it could be used for all applications
between such systems. Object oriented software can take full advantage
of CORBA and implement it easily; this is much more difficult to achieve
with traditional procedural software.
- eXtensible Markup Language (XML) – Its fundamental
simplicity, the wide availability of XML tools and a large market of
XML knowledgeable personnel, have generated significant interest in
XML. XML is a flexible way to create common information formats and
share both the format and the data on the World Wide Web, intranets,
and elsewhere. It is especially well suited for systems requiring limited,
simple data exchanges over communications links with sufficient bandwidth
and processors with sufficient processing time available. At the time
of finalizing this Handbook, an NTCIP Information Report was published
providing an overview of the issues involved in using XML-based technologies
for ITS, including two C2C recommendations – develop a more complete
SOAP-based XML standard application protocol; and develop a simple file-based
It is feasible to use all of these protocols in the same network, with
some centers acting as a bridge, or translator, between the different
protocols. The key is in determining where to deploy each protocol.
All three of these approaches – DATEX, CORBA, and XML – are recognized
by the ITS standards community. However, at the time of writing this Handbook,
none of the three approaches provide complete solutions to C2C communications.
For DATEX and CORBA, the base protocols have been defined – that is, how
to exchange data; but the standards defining the data to be exchanged
have not reached a state of maturity. The XML approach is even less mature
in that the industry has not agreed on the exact rules on how to exchange
the XML documents. Any near-term deployment should consider the impacts
that this may have on the long-term maintainability of a system. The best
solution is still likely to deploy one of the recognized standards, but
the agency should realize that a future project would likely be required
to upgrade the software to address any included features affected by revisions
in order to achieve the final mature standard (6).
220.127.116.11 Data Dictionaries and Message Sets
In addition to defining the mechanisms by which data are exchanged,
the centers within a regional ITS architecture must also agree on what
the information means. ITE/AASHTO have jointly approved the following
two related standards (Note: Additional information on these
standards, including the TMDD & MS/ETMCC Guide (Reference
8), the TMDD Center-to-Center Concept of Operations, and the standards
themselves (Reference 9) may be found
at http://www.ite.org/tmdd) developed by the
TMDD Steering Committee:
- Functional Level Traffic Management Data Dictionary (TMDD)
Standard, a set of agreed upon definitions and ways of formatting data
for use by ITS systems that have the function of traffic management.
- Message Sets for External Traffic Management Center Communications
(MS/ETMCC), providing consistent ways for electronic communication
messages to be exchanged among Traffic Management Centers, Traffic Management
Systems, and other users and/or suppliers of traffic-related information.
The Functional Level Traffic Management Data Dictionary (TMDD) Standard
contains common data definitions, called data elements, which
are used to transfer data between centers (e.g., roadway speed information
being sent to an Information Service Provider). The Standard provides
specific definition of selected data element currently in use and that
are frequently needed to construct messages used by the ATMS applications
(8). Four sections
have been developed into the following partitions:
- Traffic Links and Nodes – the traffic network,
- Events, Incidents and Notification Alarms – events perturbing the
- Traffic Network, Traffic Signal Control, Traffic Detectors, Vehicle
Probes, Ramp Metering, and Traffic Modeling – the traffic control devices,
- Closed Circuit Television, Dynamic Message Sign, Environmental Sensor
Station, Gate, Highway Advisory Radio, and Parking – advanced information
gathering or display devices
The Message Sets for External Traffic Management Center Communications
(MS/ETMCC) standard contains common groupings of data organized into message
sets for use in exchanging information between centers. It is a parallel
standard to the TMDD Standard and focuses on the "traffic management"
application messages used traditionally by transportation engineers. These
messages are grouped based on the application needs and are organized
to provide uniform information and interpretation throughout ITS deployment,
both within the native system environment and with the external transportation
management centers communications. The MS/ETMCC standard contains six
message groups: Roadway-Network, Network-State, Network-Events, Traffic-Requests,
Traffic-Device-Status, and Traffic-Control. These message sets provide
for a near real-time data exchange between traffic management centers/
subsystems and other types of transportation centers/ subsystems (i.e.,
Information Service Providers (ISPs), Transit Management, Emergency Management,
Toll Administration, and Emissions Management.) (8)
As just one example of a message set, consider "Current Event Information".
As discussed in Reference 9: "Centers
need to share event information about current events including incidents,
obstructions, traffic conditions, weather conditions, evacuations and
natural disasters. Agency responses to these events must also be exchanged
with authorized users. Managing event information is one of the most challenging
problems in ITS due to the fact that events can have inter-relationships
with other events including previous events, weather events or roadway
conditions, traffic regulation such as closures or restrictions, congestion,
and planned events managed by the same or different agency. Operators
and/or automated algorithms at external centers (especially emergency
management, transit management, and other traffic management centers)
may need to access any or all of this information from the TMC in order
to properly manage their resources and/or assist them in coordinating
potential joint responses. Table 16-3 identifies the message sets for
this particular service, indicating the sequence of events that must occur.
Together the standards enable the effective exchange of data and information
that are becoming increasingly necessary for system operations and management
as recurring congestions levels and the pervasiveness of the effects of
major incidents spread over larger areas. The TMDD Standards by themselves
are necessary but not sufficient.
The MS/ETMCC Standards are needed for the communication to occur in an
interoperable fashion. Just using MS/ETMCC Standard may result in some
communication but the content may not be understood at all without the
Table 16-3: Message Sets for Current Event Information
|Message Sequence Number: 1
Message Sequence Name: requestEventCurrentInfo( )
Sequence Documentation: requestEventCurrentInfo
2. informationEC: (EC user, center name)
Message Sequence Number: 2
Message Sequence Name: infoEventCurrent(
Message Sequence Documentation: infoEventCurrent
unique identifier for the event
2. agency name or identifier
3. typeClassEvent: event class (always current)
4. statusEvent: event status (e.g. new, update, clear/close)
5. typeEvent: type of event
6. durationEvent, expected period or expected end date and time of
7. nameLandmark: jurisdiction, facility, or landmark name
9. descriptionEvent: (current event description)
10. codeFIPS: State FIPs code or State and County FIPs code
11. numberUpdate: update number
The following optional information shall also be sent if it exists
for the event:
12. additional Location information including:
– primary point or landmark name
– secondary point or landmark name
– jurisdictions where primary and secondary point or landmark is located
– linear references of points or landmarks
– geographic coordinates of points or landmarks (longitude, latitude)
13. article (e.g. at, approaching, near)
14. alternate route
15. weather condition
16. roadway condition
17. affected lane information
18. agency contact information
19. reference to related events
The following optional action log information shall also be sent if
action log elements are
20. event identifier (required, if action log element is sent)
21. action log element identifier (required, if action log element
22. time stamp (date and time required, if action log element is sent)
23. timeline type (operator text, system update) (required, if action
log element is sent)
24. description of change (required, if action log element is sent)
18.104.22.168 Data Fusion
A number of transportation management applications – such as real time
traveler information (Chapter 13) and data
warehousing for performance monitoring and evaluation (Chapter
4) – require that the information from multiple centers be combined.
This process of combining information from a variety of systems, and then
processing the data to yield better estimates for describing the state
of the system, is often referred to as "data fusion". Reference
10 ("Data Fusion For Delivering Advanced Traveler Information System
(ATIS) Services") discusses various aspects of data fusion, particularly
with respect to providing users with integrated traveler information before
and during travel. As stated in that document's introduction, "ATIS systems
must work with a broad set of source data and information, combine and
qualify the information to yield better traveler information, and disseminate
the information when needed by travelers. One component of this complex
process is data fusion." Those same basic concepts also apply to regional
integration and freeway management and operations.
Data fusion is used primarily at public agencies to perform spatial or
temporal alignment of input data. Major data fusion functions include:
- Raw Data Collection – Transmitting and receiving error-free (Note:
The specification and quantification of "error-free" data collection
is an overall systems requirement and primarily a function of the telecommunication
subsystem design and operation) data from field sensors or other locations
- Data Identification – Matching the sensed data with the source
- Data Alignment – Configuring identified sensor data to a common spatial
and temporal reference/origin, as well as transforming data into compatible
representations and/or languages (e.g., XML)
- Data Combination – Performing various association analyses (e.g.,
statistical correlations, pattern recognition, etc.) to improve detection,
classification, and tracking of entities of interest (e.g., cars, surface
temperature readings, etc.)
- State Estimation – Predicting the kinematic (time and/or spatial)
performance of an entity of interest
- Performance Assessment – Applying techniques to assess fused data
quality and fusion processes (10).
Data fusion architecture involves four fundamental components and their
interrelationships: the data sources, the data fusion algorithms and database
techniques, the communication networks, and the Human-Computer-Interface
16.2.6 Design and Related Considerations
References 3 and 6
discuss several items that need to be considered when designing a regional
ITS architecture and the center-to-center linkages, as summarized
22.214.171.124 Systems and Centers
It is emphasized that center-to-center communications take place between
computer systems, and those computers or systems may be within the same
physical "center" or in separate TMCs. The regional architecture issues
and design questions really apply to each system, including
multiple systems within one center where relevant.
In designing the regional ITS architecture, it is necessary is to identify
the number of systems and where they are located, and then to identify
the connections between these systems, thereby creating a "framework for
integration that will support the exchange of information between ITS
If only two disparate systems are to be integrated, there may be an existing
interface on one of the two systems that meets all the requirements for
center-to-center communications, or could do so with minimal modification;
and if so, the best solution might be to replicate such an existing interface
on the other system to achieve information exchange without the need for
implementing a standard interface in both systems. However, if there are
more than two disparate systems involved in the regional architecture
– either initially or likely in the future – then modifying all the systems
to implement a standard interface is likely to be the most cost-effective
solution, especially in the long term.
126.96.36.199 Architecture Functionality and Information Requirements
For a regional architecture, the requirements need to identify the information
that will be exchanged. The following activities are specifically identified
in the "Regional ITS Architecture Guidance Document" (Reference
3) as "Step 3 – Define Interconnects":
- Identify Interconnects: This is one of the defining
moments in the regional ITS architecture development process. The operational
concept has identified the integration opportunities in the region in
a broad sense. In this step, the connections between ITS systems are
identified, creating a "framework for integration" that will support
the exchange of information between ITS systems.
- Define Information Flows: Now that the stakeholders
have reached consensus on the interconnectivity of the ITS Systems in
the inventory, they must define the information that must be exchanged,
given the services to be supported. Each information flow is fully described
by a source element (where the information originates), a destination
element (where the information is sent) and a descriptive name for the
information itself. It is often helpful to review the operational concept
and services established earlier, and envision the possible scenarios
in which information is exchanged. This exercise often brings to light
any gaps in understanding the operational concept since it reconciles
the information sent by the source ITS System with the information expected
by the destination ITS System.
Another important consideration is the frequency of change in status
or other data at each center, since changes in operating conditions are
what other centers will typically be interested in monitoring – for example,
a center that manages only incidents and related information is not likely
to generate as much message traffic on the network as one that manages
hundreds of traffic signals, each of which changes status every few seconds.
Moreover, it is important to define the manner in which the information
will be used (i.e., operational integration). Information that will not
be used should not be exchanged.
Another step identified in Reference
3 is to "identify ITS standards", during which "ITS standards (or
interim standards) are identified for every information flow in the regional
ITS architecture." It is important to understand that if the agency is
planning to prepare detailed procurement specifications for a NTCIP-compliant
C2C network, there are several issues that must be addressed in order
to satisfy basic specification requirements – specifically, making the
appropriate choice of standards for each level within the NTCIP Framework.
To effectively make these selections, there needs to be a good understanding
of what resources, like existing communications infrastructure and equipment,
might be available from each existing system to be integrated into the
regional architecture. For example:
- Do systems / centers that will likely interact and exchange information
already have a DATEX or CORBA interface? (Note – Although some systems
use DATEX-ASN, CORBA, or XML in their internal system communications
(module-to-module), it is not necessary for a system to use one of these
standards for external communications. Translators are commonly used
to convert from an internal communications interface to an external
- Does the center use object-oriented software (a prerequisite for using
- Can one or more connected centers now or in the near future provide
gateway/translation services between DATEX and CORBA?
- What communications exist / can be made available between systems?
(Note – Center-to-center communications typically involve networks connecting
many computers in a peer-to-peer arrangement. These networks typically
involve both local area networks (e.g., within a building or adjacent
buildings) and wide area networks (e.g., across town or across the nation).
The bandwidth requirements will vary for each link in each network,
depending on the amount of center-to-center messaging traffic using
that link, and whether or not the network is shared with other applications.)
The specifications for the regional architecture and the associated equipment
procurement / installation must not simply include a
sentence such as "All components shall be NTCIP compliant," or
"The system shall use NTCIP as the communications protocol."
These single statements provide no information to manufacturers or systems
integrators on the type, scope, and functionality of the system or hardware
to be implemented (6).
Practitioner should also realize that the flexibility of ITS standards
comes at the price of a more complex system than the transportation systems
industry has traditionally used. Therefore, the system may require more
sophisticated processors or better communication facilities than traditional
systems in order to achieve the same performance level (e.g., response
times, etc.). If these issues are overlooked during the design and procurement
processes, there could be significant implementation problems or setbacks
late in the project in order to provide the necessary performance.
Another factor to consider is whether or not the procurement documents
provide realistic expectations. While the ITS standards provide standardized
interfaces that are flexible enough to meet various needs, they may be
more bandwidth intensive than previous systems and/or they may use a slightly
different database design. It is important to make sure that there are
realistic expectations at the start of the project in order to ensure
that the project will be perceived as a success.
Due to the complexity, number and rate of change of the ITS standards,
it is highly advisable to have one or more standards experts on the project
team so that known problems can be avoided and new problems can be identified
and resolved quickly. This includes making sure that the functional requirements
for a project can be met by the subject standard, and, if not, specifying
how the project will support these non-standardized features (7).
Finally, if the information requirements require only a small subset
of the functionality provided by the NTCIP standards, it may be less expensive
to implement a custom interface, or at least a subset of the full standard.
However, the cost of future modifications should requirements change,
or to add the custom interface to future additional systems, needs to
be considered (8).
188.8.131.52 Testing Requirements
The design and installation documents must address how the procured
devices and software comprising the regional architecture will be tested
and certified as being standards compliant. Just because a system works
in the field and appears to be compliant with the standard through a cursory
inspection does not mean that the system is, in fact, compliant. The ITS
standards are quite complex and problems in the implementation may not
become evident until interconnection with a different network is attempted
in the future.
Testing for standards conformance can take several forms. The simplest
being from the perspective of determining if a system will accept data
elements transmitted using the standards, to the more complex notion of
ensuring that each systems provides the appropriate functional response
for the message that was received. Complex testing also ensures a system
does not transmit or make available any restricted information, and that
it does not produce false errors or unpredictable results for messages
and data it does not understand or that are addressed to another system.
It is important for agencies to plan for, and then rigorously test devices
and systems to ensure conformance to the ITS standards.
To avoid discovering problems years after deployment, it is highly advisable
to conduct a thorough test of the system upon delivery. This certification
of standards compliance may be outsourced as part of the procurement (e.g.,
through hiring an independent testing lab). It should be realized that
the ITS standards are very complex, and it may be impractical to perform
comprehensive testing covering every possible center-to-center scenario.
However, well-designed test plans can be produced to provide a high level
of confidence for a reasonable cost.
The agency should be aware of any time constraints that might be required
for the development of new software that comes as a result of implementing
a new standard. Before any testing begins, there must be a clear statement
and understanding of the requirements that must be met and the minimum
acceptable performance levels. All testing should then be based upon,
and derived only from, these agreed upon requirements. Each requirement
has a test, and each test traces to a requirement. Moreover, all tests
should have quantitative and measurable results.
184.108.40.206 Other Considerations
Some of the functions that a system may need in a center-to-center communications
management software package include the following:
- User interface (e.g., subscription form, data display, status reports,
- Interpretation and appropriate disposition of incoming messages
- Databases for storing subscriptions and other administrative data
- Interfaces with existing transportation databases and programs
- Network performance monitoring and management
- Event logging and reporting, etc.
None of these functions are specified or provided by the center-to-center
protocols or message sets (since they do not have to be standardized).
But at least some will need to be provided for a system to manage and
make use of center-to-center communications, and should therefore be included
in the regional architecture designs. A system may choose to obtain a
very elaborate and sophisticated center-to-center communications management
package, or a basic one. The former will provide more functions and be
easier to use, but will cost more.
Agencies should also be aware of the fact that design documents and procurement
requirements may need to address maintenance and subsequent device and/or
software upgrades. ITS standards are still relatively new, and changes
/ updates to the standards can be expected. Moreover, as there are relatively
few implementations available, ambiguities may still be discovered in
the standard and the standards may be modified in order to correct these
problems. Any such change may require a modification to deployed equipment
if the equipment is to maintain compatibility with the new version of
16.2.7 Emerging Trends
In many respects, regional integration – especially from the perspective
of "technical" integration and an automated ITMS – is itself an emerging
trend. As previously noted in this chapter, the ITS standards for center-to-center
continue to be refined and (as of the date of this Handbook) have not
yet reached a state of maturity. As noted in the NTCIP Guide (Reference
6), "current (C2C) deployments are split fairly evenly between DATEX
and CORBA, with very few XML implementations. It is difficult to suggest
how this market will develop."
The 4th ITMS Conference (Note: The goal of the Fourth ITMS Conference
was to identify potential initiatives and opportunities to advance the
state-of-the-art related to planning, designing, deploying, operating,
and evaluating ITMS), held in Newark, NJ in July 2001, (Reference
11) identified the following major themes and research needs related
to technical issues:
- The need for technical guidance and best practice examples on a number
of topics was identified as a priority. For example, the need for technical
guidance on issues relating to planning, designing, maintaining, and
sharing information via different interfaces among different systems
- Performance measures and evaluations are needed to document the benefits
of ITMS. Common definitions, performance measures, and monitoring and
evaluation techniques should be developed for ITMS. Ongoing monitoring
and evaluation programs should be conducted.