Freeway Management and Operations Handbook

Chapter 16 – Regional Integration
Page 1 of 2

16.1 Introduction

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 for operations":

"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 Research Board).

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 boundaries.
• 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 subject).

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 scenarios.

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).

16.1.2.1 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

16.2.1 Overview

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 other centers.

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 interoperability; and
• The sequence of projects required for implementation.

16.2.1.1 Definitions

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 individual words.
• 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 say").
• 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.

16.2.2 Benefits

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 below:

• 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.

16.2.3.1 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.

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 follows:

• 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 or shippers.
• Toll Administration – Provides general payment administration capabilities to support electronic assessment of tolls and other transportation usage fees.
• Transit Management – Collects operational data from transit vehicles and performs strategic and tactical planning for drivers and vehicles.
• 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 information requests.
• 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 Subsystems.

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.

16.2.5.1 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.

16.2.5.2 Topology

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 organization.

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 17.

16.2.5.3 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 systems include:

• 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.

16.2.5.4 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 approach.

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).

16.2.5.5 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 network,
• Traffic Network, Traffic Signal Control, Traffic Detectors, Vehicle Probes, Ramp Metering, and Traffic Modeling – the traffic control devices, and
• 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 TMDD Standard.

16.2.5.6 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 (10).

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 below.

16.2.6.1 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 systems" (3). 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.

16.2.6.2 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.

16.2.6.3 Standards

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 one.)
• Does the center use object-oriented software (a prerequisite for using CORBA)?
• 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).

16.2.6.4 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.

16.2.6.5 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, etc.)
• 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 the standard.

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 was cited.
• 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.