final draft of the tmdd ms/etmcc concept of operations

TMDD MS/ETMCC V3.0Draft Concept of Operations

TMDD MS/ETMCC V3.0 Draft Concept of Operations

Task 2.1.2 – Develop Draft Concept of Operations

For

Traffic Management Data Dictionary and Message Sets for External Traffic Management Center

Communications(TMDD MS/ETMCC)

An Informational Level Standard ofITE and AASHTO

January 25, 2007Version 3.0

i


Table of Contents

1.0 DOCUMENT INTRODUCTION.........................................................11.1 Purpose...................................................................................................11.2 Background.............................................................................................21.3 Center-to-Center and ETMCC Terms........................................................21.4 References..............................................................................................3

1.4.1 Normative References......................................................................31.4.2 Informative References.....................................................................3

1.5 Conformance Statement.........................................................................41.6 Backward Compatibility...........................................................................41.7 Document Organization...........................................................................5

2.0 CONCEPT OF OPERATIONS FOR TRAFFIC MANAGEMENT CENTER-TO-CENTER COMMUNICATIONS....................................................6

2.1 Scope......................................................................................................62.2 User Classes...........................................................................................8

2.2.1 Data User.........................................................................................82.2.2 Operations User................................................................................9

2.3 Needs.....................................................................................................92.3.1 Need for Connection Management....................................................9

2.3.1.1 Connection Startup....................................................................92.3.1.2 Running Connection...................................................................92.3.1.3 Degraded Connection.................................................................92.3.1.4 Disconnected Connection...........................................................92.3.1.5 Need to Support Data for One-time Exchange..........................102.3.1.6 Need to Support Data for Continuous Updates..........................10

2.3.2 Need for Center Entity Naming and Identification............................102.3.2.1 Need for Center Entity Naming.................................................102.3.2.2 Need to Uniquely Identify Center Entities.................................10

2.3.3 Need to Support Agreements..........................................................102.3.3.1 Need to Specify Geographic Scope of Administrative Agreements102.3.3.2 Need to Specify Delegation of Responsibility to Other Centers..102.3.3.3 Need to Specify Restrictions on Relaying Information to Third

Parties......................................................................................112.3.3.4 Need to Specify Information Availability of the Sending Center.112.3.3.5 Need to Specify Access Limits of the Receiving Center.............11

2.3.4 Need to Support Data Security........................................................112.3.4.1 Need to Authenticate the Source of Data..................................112.3.4.2 Need to Support Permission Class............................................11

2.3.5 Need to Manage Entities.................................................................112.3.5.1 Need to Exchange Inventory of Center Entities.........................112.3.5.2 Need for Location of Center Entities.........................................12

2.3.6 Need to Provide Information on Agencies, Centers, and Operators. .122.3.7 Need to Provide Event Information..................................................12

2.3.7.1 Need to Correlate an Event with Another Event........................122.3.7.2 Need to Provide Free Form Event Descriptions.........................12

ii


2.3.7.3 Need to Provide Free Form Event Names..................................132.3.7.4 Need to Provide Multi-lingual Event Descriptions......................132.3.7.5 Need for Current Event Information..........................................132.3.7.6 Need for Planned Event Information.........................................132.3.7.7 Need for Forecast Event Information........................................132.3.7.8 Need to Track Event History.....................................................132.3.7.9 Need to Filter Event Information...............................................13

2.3.8 Need to Provide Roadway Network Data.........................................142.3.8.1 Need for Roadway Network Inventory.......................................142.3.8.2 Need to Share Node, Link and Route Status..............................142.3.8.3 Need to Share Link Data...........................................................142.3.8.4 Need to Share Route Data........................................................14

2.3.9 Need to Provide Control of Traffic Devices.......................................142.3.9.1 Common Device Needs............................................................15

2.3.9.1.1 Need to Share Device Inventory.........................................152.3.9.1.2 Need to Share Device Status..............................................162.3.9.1.3 Need to Share Device Command Types..............................162.3.9.1.4 Need to Command a Device...............................................162.3.9.1.5 Need to Verify Command Status........................................162.3.9.1.6 Need to View Command Queue..........................................172.3.9.1.7 Need to Release Commands..............................................17

2.3.9.2 Need to Share Traffic Detector Data and Control......................172.3.9.2.1 Need to Share Detector Inventory......................................172.3.9.2.2 Need to Share Detector Status...........................................172.3.9.2.3 Need for Detector Metadata...............................................182.3.9.2.4 Need for Detector Data Correlation....................................182.3.9.2.5 Need for Detector Data Sharing.........................................182.3.9.2.6 Need for Detector History..................................................18

2.3.9.3 Need to Share CCTV Camera Status and Control......................182.3.9.3.1 Need to Share CCTV Device Inventory................................182.3.9.3.2 Need to Share CCTV Device Status....................................192.3.9.3.3 Need to Share CCTV Device Command Types....................192.3.9.3.4 Need to Command a CCTV Device.....................................192.3.9.3.5 Need to Verify CCTV Command Status...............................192.3.9.3.6 Need to View CCTV Command Queue................................192.3.9.3.7 Need to Release CCTV Commands.....................................19

2.3.9.4 Need to Share Video Switch Status and Control........................202.3.9.4.1 Need to Share Video Switch Inventory...............................202.3.9.4.2 Need to Share Video Switch Status....................................202.3.9.4.3 Need to Share Video Switch Command Types....................202.3.9.4.4 Need to Command a Video Switch.....................................212.3.9.4.5 Need for Verify Video Switch Command Status..................212.3.9.4.6 Need to View Video Switch Command Queue.....................212.3.9.4.7 Need to Release Video Switch Commands..........................21

2.3.9.5 Need to Share DMS Status and Control.....................................212.3.9.5.1 Need to Share DMS Inventory............................................222.3.9.5.2 Need to Share DMS Status.................................................222.3.9.5.3 Need to Share DMS Command Types.................................222.3.9.5.4 Need to Command a DMS..................................................22

iii


2.3.9.5.5 Need to Verify DMS Command Status................................222.3.9.5.6 Need to View DMS Command Queue..................................232.3.9.5.7 Need to Release DMS Commands......................................232.3.9.5.8 Need to Share DMS Message Appearance..........................23

2.3.9.6 Need to Share Environment Sensor Data..................................232.3.9.6.1 Need to Share ESS Inventory.............................................232.3.9.6.2 Need to Share ESS Device Status.......................................242.3.9.6.3 Need to Share ESS Meteorological Metadata......................242.3.9.6.4 Need to Receive a Qualified ESS Report.............................242.3.9.6.5 Need to Share ESS Collector Information............................24

2.3.9.7 Need to Share Lane Closure Gate Control.................................242.3.9.7.1 Need to Share Gate Inventory............................................242.3.9.7.2 Need to Share Gate Status.................................................252.3.9.7.3 Need for Gate Control Command Types.............................252.3.9.7.4 Need to Command a Gate Control Device..........................252.3.9.7.5 Need to Verify Gate Control Command Status....................252.3.9.7.6 Need to View Gate Control Command Queue.....................252.3.9.7.7 Need to Release Gate Commands......................................252.3.9.7.8 Need to Share Gate Control Schedule................................26

2.3.9.8 Need to Share Highway Advisory Radio (HAR) Status and Control262.3.9.8.1 Need to Share HAR Inventory.............................................262.3.9.8.2 Need to Share HAR Device Status......................................262.3.9.8.3 Need to Share HAR Device Command Types......................262.3.9.8.4 Need to Command a HAR Device.......................................272.3.9.8.5 Need to Verify HAR Command Status.................................272.3.9.8.6 Need to View HAR Command Queue..................................272.3.9.8.7 Need to Release HAR Commands.......................................272.3.9.8.8 Need to Share HAR Schedule.............................................27

2.3.9.9 Need to Share Lane Control and Status....................................272.3.9.9.1 Need to Share Controllable Lanes Inventory.......................272.3.9.9.2 Need to Share Controllable Lanes Status............................282.3.9.9.3 Need to Share Lane Control Device Command Types.........282.3.9.9.4 Need to Command a Lane Control Device..........................282.3.9.9.5 Need to Verify Lane Control Command Status....................282.3.9.9.6 Need to View Lane Control Command Queue.....................282.3.9.9.7 Need to Release Lane Control Commands..........................282.3.9.9.8 Need to Share Controllable Lanes Schedule.......................29

2.3.9.10 Need to Share Ramp Meter Status and Control..................292.3.9.10.1 Need to Share Ramp Meter Inventory...............................292.3.9.10.2 Need to Share Ramp Meter Status....................................292.3.9.10.3 Need to Share Ramp Meter Device Command Types........292.3.9.10.4 Need to Command a Ramp Meter Device.........................302.3.9.10.5 Need to Verify Ramp Meter Command Status...................302.3.9.10.6 Need to View Ramp Meter Command Queue....................302.3.9.10.7 Need to Share Ramp Metering Schedule...........................30

2.3.9.11 Need to Share Traffic Signal Control and Status.................302.3.9.11.1 Need to Share Signal System Inventory............................302.3.9.11.2 Need to Share Intersection Status....................................312.3.9.11.3 Need to Share Traffic Signal Controller Command Types. .31

iv


2.3.9.11.4 Need to Command a Traffic Signal Controller...................312.3.9.11.5 Need to Verify Traffic Signal Controller Command Status. 312.3.9.11.6 Need to View Traffic Signal Controller Command Queue...312.3.9.11.7 Need to Release Traffic Signal Controller Commands.......322.3.9.11.8 Need to Share Controller Timing Plan and Schedule.........322.3.9.11.9 Need to Share Turning Movement and Intersection Data. .322.3.9.11.10 Need to Share Time Synchronization Information...........322.3.9.11.11 Need to Share Real-Time Information Data.....................322.3.9.11.12 Need to Share Section Inventory....................................322.3.9.11.13 Need to Share Section Status.........................................332.3.9.11.14 Need to Share Section Command Types.........................332.3.9.11.15 Need to Command a Section..........................................332.3.9.11.16 Need to Verify Section Command Status.........................332.3.9.11.17 Need to View Section Command Queue..........................332.3.9.11.18 Need to Release Traffic Signal Section Commands..........342.3.9.11.19 Need to Share Section Timing Plan and Schedule...........34

2.3.10Need to Share Data for Archiving....................................................342.3.10.1 Need for Traffic Monitoring Data........................................34

2.3.10.1.1 Need for Direct Measurements of Traffic Flow and Conditions34

2.3.10.1.2 Need for Original Source Data for Traffic Monitoring Measurements...................................................................34

2.3.10.1.3 Need for Processed Traffic Monitoring Data......................342.3.10.2 Need for Data Collection System Metadata........................342.3.10.3 Need for Processing Documentation Metadata...................352.3.10.4 Need for Roadway Characteristics Data.............................352.3.10.5 Need for Event Data...........................................................35

2.3.11Need to Accept Null Values.............................................................353.0 REQUIREMENTS.........................................................................36

4.0 TRACEABILITY TO THE NATIONAL ITS ARCHITECTURE..................374.1 TMDD MS/ETMCC Trace to Market Packages..........................................37

4.1.1 Network Surveillance (ATMS01)......................................................374.1.2 Traffic Information Dissemination (ATMS06)....................................384.1.3 Regional Traffic Operations (ATMS07).............................................394.1.4 Traffic Incident Management (ATMS08)...........................................394.1.5 Road Weather Data Collection (MC03)............................................404.1.6 Roadway Maintenance and Construction (MC07).............................414.1.7 ITS Data Mart (AD1)........................................................................424.1.8 Emergency Call-Taking and Dispatch (EM01)..................................434.1.9 Emergency Routing (EM02).............................................................434.1.10Disaster Response and Recovery (EM08)........................................44

4.2 TMDD Trace to Architecture Flows.........................................................455.0 NEEDS AND REQUIREMENTS TRACEABILITY MATRIX....................48

List of Figures

v


Figure 1. Relationship between Volume I and Volume II..........................................1Figure 2. Relationship among Various ETMCC Standards.........................................2Figure 3. Traffic Management Center Interconnect Diagram...................................7Figure 4. ETMCC Environment.................................................................................7Figure 5. Typical Arrangement of Agency, Center and Devices................................8Figure 6. Network Surveillance Market Package....................................................37Figure 7. Traffic Information Dissemination Market Package.................................38Figure 8. Regional Traffic Operations Market Package...........................................39Figure 9. Traffic Incident Management Market Package........................................40Figure 10. Road Weather Data Collection Market Package....................................41Figure 11. Roadway Maintenance and Construction Market Package.....................42Figure 12. ITS Data Mart Market Package..............................................................43Figure 13. Emergency Call-Taking and Dispatch Market Package..........................43Figure 14. Emergency Routing..............................................................................44Figure 15. Disaster Response and Recovery Market Package................................45

List of Tables

Table 1. Traceability to National ITS Architecture..................................................46

vi


1.0 Document Introduction1.1 Purpose

The purpose of this Volume I document is to identify and describe the needs for a traffic management center (TMC) to provide services to external centers (EC) via a communications interface. This subject area is frequently called external traffic management center communications (ETMCC).

This document serves as a guide to the development of and a bounding scope for: ETMCC functional requirements; ETMCC ISO 14817 generic reference data model; DATEX-ASN specific reference model for the ETMCC; XML-specific ETMCC reference model.

The design content, which includes dialogs, message sets and data elements, for ETMCC are provided in the companion volume of this document, Volume II: TMDD MS/ETMCC Design Content. The two volumes together make up the Traffic Management Data Dictionary and Message Sets for External Traffic Management Center Communications (TMDD MS/ETMCC). Figure 1 depicts the relationship between the volumes in the document.

Figure 1. Relationship between Volume I and Volume II

Page 1 of 58


1.2 BackgroundThe TMDD MS/ETMCC is an informational level standard. Using an ISO 14817 based data concept model, the TMDD MS/ETMCC standard provides a protocol-independent, high-level definition of how the services will be provided via a communications interface. There are a variety of protocol-specific interface standards that define the details of how to implement the interface.

Figure 2 describes the relationship between TMDD MS/ETMCC and the protocol specific standards used to implement ETMCC.

Figure 2. Relationship among Various ETMCC StandardsThis layered approach to the ETMCC Standards was developed due to the variety of existing TMC implementations and support for more than one C2C protocol in NTCIP. This approach facilitates the exchange of messages through gateways connecting disparate systems. In addition, this layered approach will facilitate the migration to other protocols in the future as the telecommunications industry continues to advance its technology.

1.3 Center-to-Center and ETMCC TermsThe following terms are used throughout this document and need to be defined in the context of NTCIP C2C and the ETMCC.

Agency: Agency is the administrative organization that owns centers and center entities in a center-to-center environment.

Center: The operations of each organization are broken up into centers. This does not denote a physical location, as different organizations may have their centers co-located and a single center could be physically distributed across multiple physical locations.

Center-to-Center (C2C): Communications between two or more central management systems. This includes peer-to-peer communications between any number of system computers in a many-to-many network.

Page 2 of 58

DATEX


Contact: A contact is a concept that fits either an individual person or a specific named role at an organization or center. Examples of named roles would be the key operator at a traffic management center or a police dispatcher for a city.

Entity: The abstract objects managed by a system are called entities. The center-to-center entities include event reports, devices, agencies and response plans.

External Center (EC): An external center is a unique combination of an organization name and center name that uses the center-to-center services provided by another center.

Event: A situation that may impede movement across the transportation network. Current events represent on-going impediments, a planned event implies a scheduled activity in the future, and a forecast event implies a probabilistic event for a certain time period.

Interoperability: The ability of two or more systems or components to exchange information and use the information that has been exchanged.

Organization: An organization is the part of an agency at one site or center. An organization is a critical concept in center-to-center as most identifiers are created and allocated at the organization level. Examples of an organization include a state DOT district or a city transportation department.

Owner Center: The traffic management center that has direct control of the devices

Traffic Management Center (TMC): The traffic management center (TMC) is the combination of the hardware and software located in the center, including operators and maintenance personnel, policies and procedures and other entities.

Other terms and definitions not listed above may be found in other existing standards including the following:

SAE J2354, Message Sets for Advanced Traveler Information System (ATIS); IEEE 1512, Standard for Traffic Incident Management Message Sets for Use by

Emergency Management Centers; and NTCIP 1203, National Transportation Communications for ITS Protocol, Object

Definitions for Dynamic Message Signs (DMS) — Version 02.

1.4 References

1.4.1Normative References{Placeholder for Normative References. This section will be completed at a later stage in the development. Version will also be noted.}

ISO 14817

NTCIP 1104

SAE-JXXYY – ITIS Codes

SAE-JXXYY – LRMS

IEEE 1512 ?

SAE-J2354 ?

Page 3 of 58


1.4.2 Informative References{Placeholder for Informative References. This section will be completed at a later stage in the development.}

TMDD Guide

NTCIP Guide

NTCIP 2306 – XML Message Encoding and Transport

NTCIP 2304 – DATEX-ASN

1.5 Conformance StatementThe TMDD MS/ETMCC defines dialogs, and data concepts. The following define TMDD MS/ETMCC conformance:

1. To claim conformance to this standard (called a conformant implementation), the implementation must satisfy the mandatory dialogs and data concepts (messages, data frames, and data elements) defined by the TMDD MS/ETMCC.

2. If a requirement is defined in the standard and being used in a conformant implementation, then the dialogs and data concepts must be implemented as per the traceability of the standard.

3. An implementation will conform with either a) OR b) OR both:

a. XML-based implementations: A conformant implementation will validate dialogs and data concepts against the TMDD MS/ETMCC WSDL and XML Schema and specify the NTCIP 2306 standard as an application level standard;

b. DATEX-ASN implementations: A conformant implementation will validate dialogs and data concepts against the TMDD MS/ETMCC ASN.1 definitions and specify the NTCIP 2304 standards as an application level standard.

NOTE: The reader and user of this standard is advised that 'conformance' to this standard should not be confused with 'compliance' to a specification. This standard is as broad as possible to allow a very simple implementation to be 'conformant' to this standard. A specification will need to identify the requirements of a particular project and needs to require the support of those requirements. A specification writer is advised to match the requirements of a project with the corresponding standardized requirements defined in this standard to achieve interoperability. This means that functions and requirements defined as 'optional' in this standard might need to be selected in a specification (in effect made 'mandatory').

Off-the-shelf interoperability and interchangeability can only be obtained through well documented features broadly supported by the industry as a whole. Designing a system that uses features not defined in a standard or not typically deployed in combination with one another will inhibit the goals of interoperability and interchangeability, especially if the documentation of these features is not available for distribution to system integrators.

Page 4 of 58


1.6 Backward CompatibilityTMDD MS/ETMCC V3.0 maintains backward compatibility with V2.1.

TMDD MS/ETMCC 2.1 defines only data concepts (messages, data frames, and data elements). Version 3.0 will maintain backward compatibility with version 2.1 as follows:

XML-based implementations: Messages shown to validate against the TMDD MS/ETMCC V2.1 XML Schema will also validate against the V3.0 XML Schema.

DATEX-ASN implementations: Messages shown to validate against the TMDD MS/ETMCC V2.1 ASN.1 Definitions will also validate against the V3.0 ASN.1 Definitions.

NOTE: It is expected that the backward compatibility statement will allow V2.1 systems to exchange information with V3.0 systems without requiring software changes to the V2.1 system.

1.7 Document Organization Section 2 of this document (Concept of Operations) identifies and describes the operational environment and each operation needed from a traffic management subsystem.

Section 3 of this document (Functional Requirements) enhances the description of each service by defining the precise requirements related to each service.

Section 4 of this document provides a mapping of the TMDD MS/ETMCC to the National ITS Architecture.

Page 5 of 58


2.0 Concept of Operations for Traffic Management Center-to-Center

Communications2.1 Scope

The TMDD MS/ETMCC standard as developed is consistent with the National ITS Architecture Version 5.1. This section summarizes the scope of the TMDD MS/ETMCC standard relative to the National ITS Architecture. Section 4 of this document provides a more detailed assessment of those aspects of the National ITS Architecture covered by the standard. From a National ITS Architecture viewpoint, this standard identifies and describes the standard services that may be provided by a traffic management subsystem to other (external) center subsystems or system terminators of the National ITS Architecture. The external center subsystems may be traffic management subsystems or virtually any of the other center subsystems identified in the national ITS architecture. The external center subsystems may be located physically in the same building or at a remote location.

Figure 3 presents a view of the interfaces covered by the TMDD MS/ETMCC standard in the form of an interconnect diagram. The National ITS Architecture defines a set of information flows (called architecture flows in the National ITS Architecture description) for each interface shown in the diagram. Where the TMDD MS/ETMCC standard addresses all of these information flows, the interconnect is shown as a solid line on the diagram. Where the TMDD MS/ETMCC standard addresses only some of the information flows defined for the interface, an “*” is shown on the interconnect. The complete details of the information flows covered by the standard are given in Section 4. As shown on Figure 3 by the shaded boxes, the TMDD MS/ETMCC standard is meant to address the interface from a Traffic Management Center to another Traffic Management Center (External Traffic Management Center), but in fact a number of other interfaces are completely or partially covered. Each type of center is shown only once on the figure, but multiples of each center type will exist in many cases and each of their interfaces would be addressed by the standard.

Page 6 of 58


Figure 3. Traffic Management Center Interconnect Diagram

Page 7 of 58

Traffic ManagementCenter

External TrafficManagement Center

Information ServiceProvider

Event Promoter

Maintenance andConstruction Operations

Weather Service Surface TransportationWeather Service

EmergencyManagement

Archive DataManagement

Transit Management

Media

Toll Administration

Planned

*

*

*

*

*

*

*- Only a Portion of interface Is covered by Standard


The TMDD MS/ETMCC standard defines the interface communications from one center to an external center. Figure 4 shows a conceptual picture for the operational environment being defined.

Figure 4. ETMCC Environment

Based on Figure 4, this standard is concerned with identifying the communication needs between an external center and a TMC.

The TMDD MS/ETMCC limits the scope of communications about center information to the center, center agency, and center entities (e.g., operators, devices). This arrangement of entities is shown in Figure 5.

Figure 5. Typical Arrangement of Agency, Center and Devices

Page 8 of 58


2.2 User ClassesClasses of operators are important to C2C operations only to the extent that they expose the need to have levels of access to information. The user classes typically found in the ATMS environment are Data Users and Operations Users.

2.2.1Data UserData Users receive data from the Traffic Management Center. They may use the data for specific purposes typically determined by an agreement with the data provider. There are many types of centers that might use data created by a Traffic Management Center. As shown in Figure 4, these include:

External Traffic Management Emergency Management Transit Management Maintenance and Construction Operations Archived Data Management Information Service Providers Media Weather Service Surface Transportation Weather Service In addition, the Traffic Management Center may itself be a user of data obtained

from the following centers: Media Event Promoters External Traffic Management Center

2.2.2Operations UserOperations Users may use the information from a device or service and may also contribute to it (changing timing plans of a signal controller or posting a message to a DMS). This class of user may also share device control as provided by other centers and may use sensitive information by agreement with the information provider. This type of user is primarily the External Traffic Management Center, but in some cases centers such as Emergency Management may share operations of devices, including operational control.

2.3 NeedsThe following subsections describe the user needs to support the operational environment shown in Figure 4. In addition to the need (which is shown in italics), many of the subsections provide the context or rationale for the need.

2.3.1Need for Connection ManagementThere are four modes of operation when it comes to C2C communications. They are the startup of a C2C connection, a running C2C connection, a degraded C2C connection and a disconnected C2C connection.

Page 9 of 58

pchan, 01/23/07,

RGR: I would suggest that a simplified definition of Data User is simply those operators or subsystems which receive information via the center-to-center infrastructure for the purpose of decision making, internal control (i.e. control strictly within the Traffic Management Center), analysis, and/or dissemination.

pchan, 01/23/07,

RGR: Operations users are then defined as those operators or subsystems which exert control over external devices or systems through the center-to-center infrastructure.


2.3.1.1 Connection Startup

Centers need to support a connection startup mode. This operating mode begins when systems are trying to connect or regain an interrupted connection. This always precedes information flowing from system-to-system and is followed by the running connection mode.

2.3.1.2 Running Connection

Centers need to support a running connection mode. This operating mode would be considered the normal state of most C2C connections. In this mode, the information between centers is flowing and C2C functionality is working. This state follows a successfully completed startup state.

2.3.1.3 Degraded Connection

Centers need to support a degraded connection mode. This operating mode is when some or all of the information is being lost in the C2C connection. The connection may or may not fall back into startup depending on the specific protocol and detection mechanism for information breaks.

2.3.1.4 Disconnected Connection

Centers need to support a disconnected connection mode. This operating mode is when the connection between centers is down and the systems are not trying to connect with one another. All of the available C2C information is being lost. An example of this would be if an operations center is closed for an extended period of time and the C2C connection is disabled.

2.3.1.5Need to Support Data for One-time ExchangeCenters need to exchange information for one-time exchange. Bandwidth constraints may limit the exchange of data in some cases, thus centers allow operators in external centers to have the ability to receive data upon request.

2.3.1.6Need to Support Data for Continuous UpdatesCenters need to support continuous updates of information. External centers need information as it is updated or revised, but do not have the ability to determine when those updates have occurred. Therefore, it is necessary for a center to update other centers of information changes when they happen.

2.3.2Need for Center Entity Naming and Identification

2.3.2.1Need for Center Entity NamingWithin a region, centers need to adhere to a common structure for center and entity naming. This is important because centers must exchange information about which entities are associated with centers. This will facilitate the correct interpretation of entity information exchanged.

Page 10 of 58


2.3.2.2Need to Uniquely Identify Center EntitiesWithin the center-to-center network, there is a need for a mechanism to uniquely identify each entity. This is important since centers exchanging information may inadvertently create the same identifier for an entity leading to confusion about which entity and center the information is about.

2.3.3Need to Support AgreementsAdministrative agreements define which center is responsible for issuing and updating event reports for specified networks and areas. Administrative agreements may be formal or informal.

An exchange agreement defines the information to be shared between centers and the allowable uses of that information. The exchange agreement may define operating procedures, responsibilities of the various parties, legal aspects, etc. Other issues may also be agreed at the discretion of the information exchange partners. Exchange agreements may be formal or informal.

2.3.3.1Need to Specify Geographic Scope of Administrative AgreementsA center needs to specify the geographic scope of administrative agreements. A center’s area of responsibility may be an entire geographic region (such as a state) or selected facilities within a region (for example, all state-designated highways or a specified turnpike facility).

2.3.3.2Need to Specify Delegation of Responsibility to Other CentersA center needs to be able to specify delegation of responsibility to other centers. Centers may delegate some or all of their responsibilities to other centers for specified locations and periods.

2.3.3.3Need to Specify Restrictions on Relaying Information to Third Parties

A center needs to be able to specify restrictions on relaying information to third parties. The exchange agreement should specify any restrictions on relaying the information to third parties, including whether:

Information can be passed on to travel information systems by the external center; Information can be passed on to other third party centers; and Whether all or parts of some reports shall not be passed on to certain users.

2.3.3.4Need to Specify Information Availability of the Sending CenterA center needs to specify what information is available to be shared. The sending center controls what information is sent. Some information or report content may be intended only for certain users.

Page 11 of 58


2.3.3.5Need to Specify Access Limits of the Receiving CenterA center receiving information from other centers needs to limit access to that information to specific groups. Receiving centers should be able to limit access to specify information or report content to selected groups, such as during events that involve homeland security implications.

2.3.4Need to Support Data SecurityMost agencies have well-defined security policies and procedures covering a variety of system security issues. Some of the data and operations available via the ETMCC interface are quite sensitive and need to be protected against improper use.

2.3.4.1Need to Authenticate the Source of Data

Centers need to authenticate the source of each communication transmission. The authentication interrogation and reply includes information that is passed to identify a requesting center and the sending center.

2.3.4.2Need to Support Permission Class

Centers need to support permission classes. Permission classes identify which users have permission to: a) control devices and b) request information only, OR both.

2.3.5Need to Manage Entities

2.3.5.1Need to Exchange Inventory of Center EntitiesSharing inventory information is a prerequisite for providing other functions such as sharing device status, device data and device control.

Centers need to share entity information. This information includes system information, agency information, center information and operator information.

2.3.5.2Need for Location of Center EntitiesEntity location changes over time, for example in the instance of a response to an event. The location of resources available to manage the response as well as knowledge about the location of other center resources responding is necessary.

As a result, centers need to be able to determine the location of all entities at any time.

The location of a center entity may be referenced to a spatial coordinate, node, link, route, and landmark.

2.3.6Need to Provide Information on Agencies, Centers, and Operators

To support the exchange of other types of data it is important to share information about the agencies, centers, and operators that are connected. Additionally, this information can be used to help operations personnel contact the other centers with which they do not often

Page 12 of 58


coordinate. Also, the operator information for each center is important as a prerequisite for shared control.

Centers need to exchange agency, organization, and operator information. This includes:

Agency name and identification

Center site-level information

Operators who contribute to or use C2C data

Operator contact information to allow contact of operators associated with the data or control of entities at a center.

2.3.7Need to Provide Event InformationCenters share event information: current, planned and forecast events including incidents, obstructions, traffic conditions, weather conditions, evacuations, homeland security events and natural and man-made disasters to facilitate coordination of activities and resources.

Event information includes data entered manually by the operations staff as well as data automatically collected. Based on the center’s use of the data and the type of data, a center may desire constant updates on virtually all entities (for example, a traveler information system), or may only desire status information for selected entities upon request (for example, a geographically remote center may only be interested in major status changes or major events, or the center may only be able to handle a certain amount of data).

2.3.7.1Need to Correlate an Event with Another EventEvents are often related. For example, an incident may cause a secondary incident to occur. Moreover, the events of one center may relate to the events of another center.

Centers need to associate an event with an external center’s events.

2.3.7.2Need to Provide Free Form Event DescriptionsMany centers have established pre-determined codes for the description of events and category of events. Often, however, the codes are insufficient to fully explain the details of the event or operational activities of the center.

Events need to be described using free form event descriptions.

2.3.7.3Need to Provide Free Form Event NamesRegions may have established names for special events.

Centers need to exchange free form event names.

Page 13 of 58


2.3.7.4Need to Provide Multi-lingual Event DescriptionsRegions may border a country or part of same country that speak and manage centers in different languages. Also specific communities may have different language needs.

Centers need to share information in multiple languages.

2.3.7.5Need for Current Event InformationCurrent event information is exchanged between centers so that events can be known to other centers, which may need to react operationally with internal response plans. Centers need to share current event information including: a description, location, category, and status.

2.3.7.6Need for Planned Event InformationPlanned event information is exchanged between centers so that events can be known to other centers, which may need to react operationally with internal coordination plans. Centers need to share planning information about events including: projected start and end and optionally, timeline schedule elements.

2.3.7.7Need for Forecast Event InformationCenters need to exchange forecast event information (e.g., weather and roadway conditions) so that forecasts can be known to other centers, which may need to react operationally.

Centers need to share forecast information about events including: forecast start and end time, forecast period, and optionally, timeline schedule elements.

2.3.7.8Need to Track Event HistoryAgencies may respond to queries from other agencies about how a event was managed, the timeline of activities related to the event, and what information was communicated when and with what centers. Event status can be shared between centers (e.g., detected, confirmed, reported, cleared, closed, updates to ITS devices, planned, and forecast).

Centers need to track and share an event’s change in status and associated times.

2.3.7.9Need to Filter Event InformationEvent Information and histories can be lengthy and may provide redundant information already available to operators. Upon request, a recap of current events that had been updated since a specified date and time is exchanged between centers.

Centers need to share event information based on category, status, and specified date and time between centers.

Centers need to share event updates issued since a specified date and time between centers.

Page 14 of 58


2.3.8Need to Provide Roadway Network DataA traffic network represents a collection of roadway nodes, links, and routes. A node is the smallest data element that is unique within a network. Nodes provide a geographic location that can represent the beginning and end points of a link, location of a device, intersection, or location of an incident. A route is a collection of links.

When a center elects to participate in a C2C environment, it may make available to other centers its traffic network information, which it uses to reference location of its center entities.

2.3.8.1Need for Roadway Network InventoryThe traffic network inventory sharing provides operation centers within the C2C network a list of nodes, links, and routes that compose the roadway network.

Centers need to share node inventory including a description, unique identification and spatial information for all nodes in the traffic network.

Centers need to share link inventory including a description, unique identification and spatial information for all links in the traffic network.

Centers need to share route inventory including a description, type, unique identification and spatial information for all routes in the traffic network. Example route types include: travel time, transit routes, alternate, and detour routes.

2.3.8.2Need to Share Node, Link and Route StatusCenters share information about the traffic network they operate, which may help other centers perform route planning.

Centers need to share the status of a node, link, or route as: open, closed, or restricted. An example of a restricted status are high-occupancy vehicle lanes.

2.3.8.3Need to Share Link DataLink data sharing provides operations centers within the network a general status of links in the traffic network. Link data can be derived from multiple sources and is defined by the field detection that is supporting operations for the operations center. Link data can be fused from many sources and applied to the appropriate links or roadways on the traffic network to provide information to operations centers to assist in reporting incidents or slowdowns.

Centers need to share link data including: volume, occupancy, speed, and travel time.

2.3.8.4Need to Share Route DataCenters exchange route travel time with other centers, which in turn may be provided to travelers and other public agencies to help them plan routes.

Centers need to share route data. Route data when combined with other information allows calculation of route travel time.

Page 15 of 58


2.3.9Need to Provide Control of Traffic DevicesThis section describes the generic issue of control of traffic devices by an external center. The specific needs associated with each type of device are identified in the following sections. An external center may desire to control traffic through the use of traffic control devices connected to the TMC. Among the many reasons an external center may wish to do this (and a TMC may wish to allow it), two stand out as undisputed. The first reason is that many traffic control centers do not stay open 24 hours a day, 7 days a week. The second reason is that emergency conditions sometimes require the evacuation of an operations center. The following is a more detailed description of these reasons:

Scheduled closing of operations centers - Most traffic operations centers are scheduled to be open when the value of the operations are high compared to the cost of keeping them closed. For some centers, this means that they are closed during the night and/or during weekends. Nonetheless, conditions may arise during these periods that require active traffic management. In these cases, the center may wish to allow another, perhaps regional, center to have limited control of its equipment.

Evacuation of operations centers - One of the most important uses of ITS devices is to manage traffic during natural disasters and other emergency situations that require the evacuation of the civilian population. For example, during a hurricane evacuation where the operations center could be closed down, the traffic along the evacuation routes may be controlled via remote terminals.

Due to the various liability concerns involved with controlling traffic control devices, each agency will need to establish its own institutional policies defining under what conditions an external centers may exert control upon a device. These policies may include:

An operator to manually process the request; A computer to automatically approve/deny the request; and Some combination of operator and computer to process the request.

Thus, the messaging standards should allow a mechanism by which an external center may make a request for controlling a traffic control device and receive a response for this request; however, the standards are neutral as to the institutional policies that a specific agency may wish to put in place in order to approve or deny the request.

2.3.9.1Common Device NeedsFor each traffic device, the needs are outlined as follows:

Need to Share Device Inventory Need to Share Device Status Need to Share Device Command Types Need to Command a Device Need to Verify Command Status Need to View Command Queue Need to Release Commands

Page 16 of 58


2.3.9.1.1 Need to Share Device InventoryCenters need to exchange traffic device inventory information so that traffic devices that are operated by a center can become known to other centers. Inventory information includes data such as location of the device (including lane information) and static device attributes.

Centers need to exchange static traffic device attributes so that the capabilities of the traffic devices that are operated by a center can become known to other centers. Static device attributes may include:

Location; Configuration data (including installation, maintenance history); Type of device (technology); and Control capabilities.

Configuration data is needed to understand the “context” of how the traffic device is operating, particularly for archived data. Static traffic device-specific attributes are addressed in the appropriate section.

Centers need to exchange updated inventory information as traffic devices are added, removed or changed. As centers add, remove, or change traffic devices from their systems, the updated inventory should be provided to other centers, without requiring operator intervention. Changes may include the traffic device location or technology.

2.3.9.1.2 Need to Share Device StatusCenters need to exchange status information for each traffic device. Status information includes:

Communications status (connected, disconnected, failed); Operational status (working, not-available); and Current operational state information (mode of operation).

2.3.9.1.3 Need to Share Device Command TypesCenters need to exchange what commands are supported by each traffic device. Types of commands may include:

Device status; Command status; and Diagnostics.

Other traffic device-specific types of commands are addressed in the appropriate section.2.3.9.1.4 Need to Command a DeviceCenters need to be able to command a traffic device operated by another center.

When a control request is received the center that controls the traffic device needs to make a determination if the command will be implemented, queued, or rejected. Then, the center that controls the traffic device needs to send a response to the center that originated the request describing the status (action taken) on the control request.

Page 17 of 58


2.3.9.1.5 Need to Verify Command StatusThe center that sends a command to control a traffic device operated by another center needs to verify the status of such a command. The status may be that the command was implemented, was queued, or was rejected.

2.3.9.1.6 Need to View Command QueueThe center that originates a command to control a traffic device operated by another center needs to view the command queue for that traffic device if the command has been queued.

This device control model assumes that there my be competing priorities for the use of a traffic device, and that a center may implement a queue or priority list of the commands received, whether from the host center itself or external centers, and their priority. External centers thus need to be able to read this queue for multiple devices to determine where their specific command currently “sits”.

2.3.9.1.7 Need to Release CommandsCenters need to be able to “remove” a command so the host center knows that the control command is no longer required and can be released.

2.3.9.2Need to Share Traffic Detector Data and ControlTraffic detectors measure traffic volume, occupancy, and speeds. Traffic detector data are used by centers to:

monitor the surface transportation system; support toll collection; determine system performance; and quantitatively measure how well an ITS system helps to improve incident

response.

Centers may include traveler information systems.

2.3.9.2.1 Need to Share Detector InventoryCenters need to exchange traffic detector inventory information so that detection devices that are operated by a center can become known to other centers. Inventory information includes data items such as location and device attributes. Device attributes may include:

location (including lane information); configuration data (including installation, maintenance history); type of detector (technology); purpose of the detector (traffic signal, ramp metering, traffic data collection,

etc.); physical device detector is connected to; and logical entity that the detector data is intended for (traffic signal, ramp meter,

etc.)

Page 18 of 58


Centers need to exchange updated inventory information as detection devices are added, removed, or changed. As centers add, remove, or change traffic detection devices, the updated inventory should be provided to other centers, without requiring operator intervention. Changes may include the traffic detector device location or technology.

2.3.9.2.2 Need to Share Detector StatusCenters need to exchange status information for each detector device. Status information includes:

Communications status (connected, disconnected, failed); Operational status (working, not-available); and Current operational state information (presence/pulse, etc.).

2.3.9.2.3 Need for Detector MetadataCenters need to exchange detector metadata. Metadata about traffic detectors and sensors needs to be captured to aid in determining the quality of the traffic detector and sensor information and to describe how the data was collected.

2.3.9.2.4 Need for Detector Data CorrelationDetector information needs to be correlated with roadway geography (routes, links and nodes), and specific lane. This allows a receiving center to relate detector data to specific routes, links and nodes of the traffic network.

2.3.9.2.5 Need for Detector Data SharingCenters need to exchange current traffic data from the detectors. This traffic data includes volume, occupancy and speed of the vehicles associated with the detector. Depending on the availability and needs, the subject data could be provided as raw or averaged data.

2.3.9.2.6 Need for Detector HistoryCenters need to exchange the maintenance history of traffic detectors to check the quality of the metadata collected. The maintenance history may include when a detection device was installed, its historical operational status, and when a detector device was under repair.

Need to Share CCTV Camera Status and ControlClosed circuit television (CCTV) cameras are used by centers to help view the surface transportation system. CCTV devices can be used by centers to:

Verify the existence of traffic congestion reports; Determine what assistance may be needed by the incident; Monitor the progress of incidents, construction and special events; Determine when the residual congestion from an incident is cleared; Provide visual images to the public as to the state of the roadway; and Determine what type of emergency services need to be dispatched

Page 19 of 58


2.3.9.2.7 Need to Share CCTV Device InventoryCenters need to exchange CCTV inventory information so that CCTV devices that are operated by a center can become known to other centers. Inventory information includes data items such as location and CCTV device attributes. CCTV device attributes may include:

location; configuration data (including installation, maintenance history); type (technology); capabilities (pan, tilt, zoom, focus, BW/Color); and

limits (tilt);

Centers need to exchange updated inventory information as CCTV devices are added, removed or changed. As centers add, remove, or change CCTV devices, the updated inventory should be provided to other centers, without requiring operator intervention. Changes may include the CCTV device location or technology.

2.3.9.2.8 Need to Share CCTV Device StatusCenters need to exchange status information for each CCTV device. Status information includes:

Communications status (connected, disconnected, failed); Operational status (working, not-available); and Current operational state information (orientation of the CCTV camera

(direction), if current view is available for public dissemination, etc.).

2.3.9.2.9 Need to Share CCTV Device Command TypesCenters need to exchange what commands are supported by each CCTV device. Types of commands include:

Device status; Command status; Movement (pan, tilt, zoom); Lens Control; and Diagnostics.

2.3.9.2.10Need to Command a CCTV DeviceCenters need to be able to command a CCTV device operated by another center.

When a control request is received the center that controls the CCTV device needs to make a determination if the command will be implemented, queued, or rejected.

Then, the center that controls the CCTV device needs to send a response to the center that originated the request describing the status (action taken) on the control request.

Page 20 of 58


2.3.9.2.11Need to Verify CCTV Command StatusThe center that sends a command to control a CCTV device operated by another center needs to verify the status of such a command. The status may be that the command was implemented, was queued, or was rejected.

for CCTV Control ReceiptNeed to View CCTV Command Queue

The center that originates a command to control a CCTV device operated by another center needs to view the command queue for that CCTV device if the command has been queued.

This control model assumes that there may be competing priorities for the use of a CCTV device, and that a center may implement a queue or priority list of the commands received, whether from the host center itself or external centers, and their priority. External centers thus need to be able to read this queue for multiple devices to determine where their specific command currently “sits”.

2.3.9.2.12Need to Release CCTV CommandsCenters need to be able to “remove” a CCTV command so the host center knows that the control command is no longer required and can be released.

2.3.9.3 Need to Share Video Switch Status and Control

Video switches (VS) are used to route the video from a source device to an end device. Video switch devices can be used by centers to:

Display the output of a video device on an output device (local monitor, video wall, etc.);

Provide visual images to other centers; Provide visual images to the public as to the state of the roadway; Receive visual images from external centers that may be closed; Record the video onto a storage device; and Alter the attributes of a video steam in order to effectively utilize available

communications bandwidth.

2.3.9.3.1 Need to Share Video Switch InventoryCenters need to exchange inventory information so that video switches that are operated by a center can become known to other centers. Inventory information includes location of the video switch, and static device attributes.

Centers need to exchange video switch device attributes so that the capabilities of the video switch operated by a center can become known to other centers. Static video switch device attributes may include:

Configuration data (including installation, maintenance history); Type of video switch (technology); Number of video inputs and outputs supported; The video source assigned to each video input; The end device assigned to each video output;

Page 21 of 58


Video stream formats and capabilities (bandwidth, frames per second); and Control capabilities.

Centers need to exchange updated inventory information as video switch devices are added, removed or changed. As centers add, remove, change, or reassign end devices from their systems, the updated inventory should be provided to other centers, without requiring operator intervention.

2.3.9.3.2 Need to Share Video Switch StatusCenters need to exchange status information for any connections (a mapping between an input and an output) that are currently implemented by the video switch. Status information includes:

Communications status (connected, disconnected, failed); Operational status (working, not-available); and Current operational state information (what inputs and outputs are available,

video signal levels for each input, etc.).

2.3.9.3.3 Need to Share Video Switch Command TypesCenters need to exchange what commands are supported by each video switch. Types of commands include:

Switch status; Command status; Video routing; Controlling video attributes (bandwidth, frames per second); Recording (for recording devices); and Diagnostics.

2.3.9.3.4 Need to Command a Video Switch Centers need to be able to command a video switch operated by another center.

When a control request is received the center that controls the video switch needs to make a determination if the command will be implemented, queued, or rejected. Then, the center that controls the video switch needs to send a response to the center that originated the request describing the status (action taken) on the control request.

2.3.9.3.5 Need for Verify Video Switch Command StatusThe center that sends a command to control a video switch operated by another center needs to verify the status of such a command. The status may be that the command was implemented, was queued, or was rejected.

2.3.9.3.6 Need to View Video Switch Command QueueThe center that originates a command to control a video switch operated by another center needs to view the command queue for that video switch if the command has been queued.

Page 22 of 58


This control model assumes that there my be competing priorities for the use of a video switch, and that a center may implement a queue or priority list of the commands received, whether from the host center itself or external centers, and their priority. External centers thus need to be able to read this queue for multiple devices to determine where their specific command currently “sits”.

2.3.9.3.7 Need to Release Video Switch CommandsCenters need to be able to “remove” a video switch command so the host center knows that the control command is no longer required and can be released.

2.3.9.4 Need to Share DMS Status and Control

Dynamic message signs (DMS) are used by centers to help manage the surface transportation system. Dynamic message signs can be used to:

Provide travelers information that help the travelers select routes; Inform travelers about traffic congestion; Inform travelers about travel times; Inform travelers about roadway or traffic conditions; Inform travelers about planned activities that may affect traffic conditions; Provide information about transportation alternatives; and Provide other public service announcements.

2.3.9.4.1 Need to Share DMS InventoryCenters need to exchange DMS inventory information so that DMSs operated by a center can become known to other centers. Inventory information includes data items such as location and DMS device attributes. DMS device attributes may include:

Location (including direction of traffic the DMS is facing);

Configuration data (including installation, maintenance history); Size (physical dimensions, characters per line, number of lines);

Type (technology, permanent versus portable); and

Capabilities.

Centers need to exchange updated inventory information as DMSs are added, removed, or changed. As centers add, remove, or change DMSs, the updated inventory should be provided to other centers, without requiring operator intervention. Changes may include the DMS location or technology.

2.3.9.4.2 Need to Share DMS StatusCenters need to exchange status information for each DMS. Status information includes:

Communications status (connected, disconnected, failed); Operational status (working, not-available); and Current operational state information (contents of the display on the sign, etc.).

Page 23 of 58


2.3.9.4.3 Need to Share DMS Command TypesCenters need to exchange what commands are supported by each DMS. Types of commands include:

Device status; Command status; Activate a message; Upload/Download messages; Read tables (e.g., font tables, message tables); MULTI-Strings; and Diagnostics.

2.3.9.4.4 Need to Command a DMSCenters need to be able to command a DMS operated by another center. Message display requests can be either freeform text messages, in MULTI-string format, or from a library associated with the DMS. When a control request is received the center that controls the DMS needs to make a determination if the message will be implemented, queued, or rejected. Then, the center that controls the DMS needs to send a response to the center that originated the request describing the status (action taken) on the control request.

2.3.9.4.5 Need to Verify DMS Command Status

The center that sends a command to control a DMS operated by another center needs to verify the status of such a command. The status may be that the command was implemented, was queued, or was rejected.

2.3.9.4.6 Need to View DMS Command QueueThe center that originates a command to control a DMS operated by another center needs to view the command queue for that DMS device if the command has been queued.

This control model assumes that there may be competing priorities for the use of a DMS, and that a center may implement a queue or priority list of the commands received, whether from the host center itself or external centers, and their priority. External centers thus need to be able to read this queue for multiple DMSs to determine where their specific command currently “sits”.

2.3.9.4.7 Need to Release DMS CommandsCenters need to be able to “remove” a DMS command so the host center knows that the control command is no longer required and can be released.

2.3.9.4.8 Need to Share DMS Message AppearanceCenters need to exchange information on how a message actually appears on the face of a DMS. To properly confirm how a message will look on a DMS, the multi-string has to be sent to properly format it, and the capabilities of the DMS (color, number of lines, number of characters per line, etc.) must be known.

Page 24 of 58


2.3.9.5Need to Share Environment Sensor DataEnvironmental Sensor Stations (ESS) data are used by centers to determine the environmental conditions, such as weather (such as wind, temperature, precipitation), pavement conditions, visibility and air/water quality, near a roadway. ESSs are used to determine current conditions and the data are also combined with modeling algorithms for predicting future conditions such as fog or roadway icing.

ESS data can be used by centers to: Direct roadway maintenance; Provide weather information to travelers and third-party weather service

providers; Provide pavement conditions, such as icing and flooding that may reduce

roadway capacity; Direct traffic operations; and Predict future weather conditions.

2.3.9.5.1 Need to Share ESS InventoryCenters need to exchange inventory information so that ESSs operated by a center can become known to other centers. Inventory information includes data items such as location and static device attributes.

Centers need to exchange ESS device attributes so that the capabilities of the ESS sensors operated by a center can become known to other centers. Static ESS device attributes may include:

Location (including lane information); Configuration data (including installation, maintenance history); Type of sensor (technology); Capabilities; and Control capabilities.

Centers need to exchange updated inventory information as ESS devices are added, removed or changed. As centers add, remove, or change ESS devices, the updated inventory should be provided to other centers, without requiring operator intervention. Changes may include the ESS device location or technology.

2.3.9.5.2 Need to Share ESS Device StatusCenters need to exchange status information for each ESS device. Status information includes:

Communications status (connected, disconnected, failed); and Operational status (working, not-available)

Page 25 of 58


2.3.9.5.3 Need to Share ESS Meteorological MetadataCenters need to exchange meteorological data collected by ESS. Centers may include weather service providers. Meteorological data may include environmental observation data.

Metadata about ESS needs to be captured to aid in determining the quality of the ESS sensor information, and how it was collected (timestamp of when the data was recorded, if it’s an average or peak, etc.)

2.3.9.5.4 Need to Receive a Qualified ESS ReportCenters need to receive a Qualified ESS Report. Weather service providers process ESS meteorological metadata and information, assess the quality of the information, and disseminates the aggregated data with quality flags indicating qualified observations.

2.3.9.5.5 Need to Share ESS Collector InformationCenters need to share data describing the RWIS collectors, the ESS system, and the ESS sensors. Centers may include weather service providers. This should include agency contact data.

2.3.9.6Need to Share Lane Closure Gate ControlLane closure gate controls are used by centers to help manage the surface transportation system. Lane closure gates can be used by centers to:

Allow or deny access to facilities that may periodically close due to road/weather conditions, conflicting operations (such as reversible flow or draw-bridge), or other reasons; and

Allow or limit traffic flow on specific links based on congestion and/or accidents on the roadways or on adjoining roads.

2.3.9.6.1 Need to Share Gate InventoryCenters need to exchange inventory information so that traffic gates operated by a center can become known to other centers. Inventory information includes data items such as location and gate attributes. Gate device attributes may include:

Location; Configuration data (including installation, maintenance history); Type (technology); and Capabilities.

Centers need to exchange updated inventory information as gates are added, removed or changed. As centers add, remove, or change gate devices, the updated inventory should be provided to other centers, without requiring operator intervention. Changes may include the gate device location or technology.

2.3.9.6.2 Need to Share Gate StatusCenters need to exchange status information for each gate. Status information includes:

Page 26 of 58


Communications status (connected, disconnected, failed); Operational status (working, not-available); and Current operational state information (open or closed, direction of traffic, etc.).

2.3.9.6.3 Need for Gate Control Command TypesCenters need to exchange what commands are supported by each gate control device. Types of commands include:

Device status; Command status; and Diagnostics.

2.3.9.6.4 Need to Command a Gate Control DeviceCenters need to be able to command a gate control device operated by another center.

When a control request is received the center that controls the gates need to make a determination if the request will be implemented, queued, or rejected. Then, the center that controls the gate control device needs to send a response to the center that originated the request describing the status (action taken) on the control request.

2.3.9.6.5 Need to Verify Gate Control Command StatusThe center that sends a command to control a gate device operated by another center needs to verify the status of such a command. The status may be that the command was implemented, was queued, or was rejected.

2.3.9.6.6 Need to View Gate Control Command QueueThe center that originates a command to control a gate control device operated by another center needs to view the command queue for that gate if the command has been queued.

This control model assumes that there may be competing priorities for the use of a gate control device, and that a center may implement a queue or priority list of the commands received, whether from the host center itself or external centers, and their priority. External centers thus need to be able to read this queue for multiple devices to determine where their specific command currently “sits”.

2.3.9.6.7 Need to Release Gate CommandsCenters need to be able to “remove” a gate control command so the host center knows that the control command is no longer required and can be released.

2.3.9.6.8 Need to Share Gate Control ScheduleCenters need to exchange information about the operational schedule of control of traffic gates. This allows centers to exchange gate control time-of-day schedules.

Page 27 of 58


2.3.9.7Need to Share Highway Advisory Radio (HAR) Status and ControlHighway Advisory Radio (HAR) are used by centers as an information dissemination device to help manage the surface transportation system. Its use is often coupled with the use of messages on dynamic message signs to provide a consistent message to travelers.

HARs may be used by centers to:

Reach travelers at the major decision points in their trips before they add to the backup; and

Give notice of future construction and upcoming special events.

2.3.9.7.1 Need to Share HAR InventoryCenters need to exchange inventory information so that HARs that are being operated by a center can become known to other centers. Inventory information includes data items such as location and attributes of the HAR device. HAR device attributes may include:

Location; Configuration data (including installation, maintenance history); Type (technology); and Capabilities (recording times).

Centers need to exchange updated inventory information as HAR devices are added, removed or changed. As centers add, remove, or change HAR devices, the updated inventory should be provided to other centers, without requiring operator intervention. Changes may include the HAR device location or technology.

2.3.9.7.2 Need to Share HAR Device StatusCenters need to exchange status information for each HAR device. Status information includes:

Communications status (connected, disconnected, failed); Operational status (working, not-available); and Current operational state information (current message, etc.).

2.3.9.7.3 Need to Share HAR Device Command TypesCenters need to exchange what commands are supported by each HAR device. Types of commands include:

Device status; Command status;

Activate a message; Read tables (e.g., message tables);

Upload/download messages; and Diagnostics.

Page 28 of 58


2.3.9.7.4 Need to Command a HAR DeviceCenters need to be able to command a HAR device operated by another center.

When a control request is received the center that controls the HAR need to make a determination if the request will be implemented, queued, or rejected. Then, the center that controls the HAR device needs to send a response to the center that originated the request describing the status (action taken) on the control request. Message playback requests can be either freeform voice or text messages or messages from a library associated with the HAR.

2.3.9.7.5 Need to Verify HAR Command StatusThe center that sends a command to control a HAR device operated by another center needs to verify the status of such a command. The status may be that the command was implemented, was queued, or was rejected.

2.3.9.7.6 Need to View HAR Command QueueThe center that originates a command to control a HAR device operated by another center needs to view the command queue for that HAR device if the command has been queued.

This control model assumes that there may be competing priorities for the use of a HAR device, and that a center may implement a queue or priority list of the commands received, whether from the host center itself or external centers, and their priority. External centers thus need to be able to read this queue for multiple devices to determine where their specific command currently “sits”.

2.3.9.7.7 Need to Release HAR CommandsCenters need to be able to “remove” a HAR control command so the host center knows that the control command is no longer required and can be released.

2.3.9.7.8 Need to Share HAR ScheduleCenters need to exchange HAR schedule information. This allows centers to exchange time-of-day schedules of messages for the HAR device.

2.3.9.8Need to Share Lane Control and StatusLane control devices are used by centers to close, change the direction, or open a lane in order to properly manage traffic conditions.

Some uses of this type of control would be to enhance egress from a special event, handle additional congestion from a nearby accident, or close traffic to protect construction crews. These controls can change the direction of a lane.

2.3.9.8.1 Need to Share Controllable Lanes Inventory Centers need to exchange inventory information so that controllable lanes that are being operated by a center can become known to other centers. Inventory information includes data items such as location and device attributes. Lane control device attributes may include:

Location of the controllable lanes and orientation (direction);

Page 29 of 58


Location of the lane control devices and orientation;

Configuration data (including installation, maintenance history); Type of lane control devices (technology); and

Capabilities.

Centers need to exchange updated inventory information as lane control devices are added or removed. As centers add, remove, or change lane control devices, the updated inventory should be provided to other centers, without requiring operator intervention. Changes may include the lane control device location or technology.

2.3.9.8.2 Need to Share Controllable Lanes StatusCenters need to exchange status information for each controllable lane and lane control devices. Status information includes:

Communications status (connected, disconnected, failed); Operational status (working, not-available); and Current operational state information (direction of traffic, lane closed, etc.).

2.3.9.8.3 Need to Share Lane Control Device Command TypesCenters need to exchange what commands are supported by each lane control device. Types of commands include:

Device status; Command status; Diagnostics.

2.3.9.8.4 Need to Command a Lane Control DeviceCenters need to be able to command a lane control device operated by another center.

When a control request is received the center that controls the lane control devices need to make a determination if the request will be implemented, queued, or rejected. Then, the center that controls the lane control device needs to send a response to the center that originated the request describing the status (action taken) on the control request.

2.3.9.8.5 Need to Verify Lane Control Command StatusThe center that sends a command to control a lane control device operated by another center needs to verify the status of such a command. The status may be that the command was implemented, was queued, or was rejected.

2.3.9.8.6 Need to View Lane Control Command QueueThe center that originates a command to control a lane control device operated by another center needs to view the command queue for that lane control device if the command has been queued.

Page 30 of 58


This control model assumes that there may be competing priorities for the use of a lane control device, and that a center may implement a queue or priority list of the commands received, whether from the host center itself or external centers, and their priority. External centers thus need to be able to read this queue for multiple devices to determine where their specific command currently “sits”.

2.3.9.8.7 Need to Release Lane Control CommandsCenters need to be able to “remove” a lane control command so the host center knows that the control command is no longer required and can be released.

2.3.9.8.8 Need to Share Controllable Lanes Schedule

Centers need to share exchange schedule information related to controllable lanes. This allows centers to exchange lane control time-of-day schedules.

2.3.9.9Need to Share Ramp Meter Status and ControlRamp meters are used by centers to help manage highway traffic flow Ramp meters can be used by centers to:

Move traffic efficiently; and Manage traffic during an incident or event to alleviate congestion.

2.3.9.9.1 Need to Share Ramp Meter InventoryCenters need to exchange inventory information so that ramp controllers being operated by a center can become known to other centers. Inventory information includes data items such as location, ramp configuration, and ramp controller device attributes. Ramp controller device attributes may include:

Location (including which lane);

Lane configuration;

Configuration data (including installation, maintenance history); Type (technology).

Centers need to exchange updated inventory information as ramp meter devices are added, removed, or changed. As centers add, remove, or change ramp meter devices, the updated inventory should be provided to other centers, without requiring operator intervention. Changes may include the ramp meter device location or technology.

2.3.9.9.2 Need to Share Ramp Meter StatusCenters need to exchange status information for each lane-by-lane ramp metering. Status information includes:

Communications status (connected, disconnected, failed); Operational status (working, not-available); and Current operational state information (metering rate, etc.).

Page 31 of 58


Centers need to be able to verify in real-time the ramp metering synchronization, and for maintenance purposes, diagnostic information.

2.3.9.9.3 Need to Share Ramp Meter Device Command TypesCenters need to exchange what commands are supported by each ramp meter device. Types of commands include:

Device status; Command status; Change metering rate; Read tables (e.g., metering tables); Upload/download metering tables; and Diagnostics.

2.3.9.9.4 Need to Command a Ramp Meter DeviceCenters need to be able to command a ramp meter device operated by another center.

When a control request is received the center that controls the ramp meter need to make a determination if the request will be implemented, queued, or rejected. Then, the center that controls the ramp meter device needs to send a response to the center that originated the request describing the status (action taken) on the request.

2.3.9.9.5 Need to Verify Ramp Meter Command StatusThe center that sends a command to control a ramp meter device operated by another center needs to verify the status of such a command. The status may be that the command was implemented, was queued, or was rejected.

2.3.9.9.6 Need to View Ramp Meter Command QueueThe center that originates a command to control a ramp meter device operated by another center needs to view the command queue for that ramp meter device if the command has been queued.

This control model assumes that there may be competing priorities for the use of a ramp meter device, and that a center may implement a queue or priority list of the commands received, whether from the host center itself or external centers, and their priority. External centers thus need to be able to read this queue for multiple devices to determine where their specific command currently “sits”.

2.3.9.9.7 Need to Share Ramp Metering ScheduleCenters need to exchange ramp metering schedule information, including the schedule of when a metering plan will be in effect, and current real-time metering plan activation.

2.3.9.10 Need to Share Traffic Signal Control and StatusTraffic signals are used by centers to help manage the street and arterial transportation system. Traffic signals can be used by centers to:

Monitor signal system operations within an area; Improve traffic signal coordination to move traffic more efficiently;

Page 32 of 58


Manage traffic at specific areas or intersections based on congestion and/or accidents on the roadways; and

Execute mitigation plans for construction and special event congestion and reacting to traffic incidents

2.3.9.10.1Need to Share Signal System InventoryCenters need to exchange inventory information so that traffic signals that are being operated by a center can become known to other centers. Inventory information includes data items such as locations, traffic signal section assignments and traffic signal controller attributes. Traffic signal device attributes may include:

Location; Configuration data (including installation, maintenance history); Type (technology); and

Traffic signal section assignment;

Centers need to exchange updated inventory information as traffic signals are added, removed, or changed. As centers add, remove, or change traffic signal devices, the updated inventory should be provided to other centers, without requiring operator intervention. Changes may include the traffic signal controller location, technology or section assignments.

2.3.9.10.2 Need to Share Intersection StatusCenters need to exchange status information for each traffic signal. Status information includes:

Communications status (connected, disconnected, failed); Operational status (working, not-available); and Current operational state information (control mode, signal timing parameters,

timing plan number, etc.).

2.3.9.10.3Need to Share Traffic Signal Controller Command TypesCenters need to exchange what commands are supported by each traffic signal controller. Types of commands include:

Device status; Command status; Activate a signal timing plan; Change the mode of operation; Read tables (e.g., signal timing tables); Upload/download signal timing plans; and Diagnostics.

Page 33 of 58


2.3.9.10.4Need to Command a Traffic Signal ControllerCenters need to be able to command a traffic signal controller operated by another center.

When a control request is received the center that controls the traffic signal controller need to make a determination if the request will be implemented, queued, or rejected. Then, the center that controls the traffic signal controller needs to send a response to the center that originated the request describing the status (action taken) on the control request.

2.3.9.10.5Need to Verify Traffic Signal Controller Command StatusThe center that sends a command to control a traffic signal controller device operated by another center needs to verify the status of such a command. The status may be that the command was implemented, was queued, or was rejected.

2.3.9.10.6Need to View Traffic Signal Controller Command QueueThe center that originates a command to control a traffic signal controller operated by another center needs to view the command queue for that traffic signal controller if the command has been queued.

This control model assumes that there may be competing priorities for the use of a traffic signal controller, and that a center may implement a queue or priority list of the commands received, whether from the host center itself or external centers, and their priority. External centers thus need to be able to read this queue for multiple devices to determine where their specific command currently “sits”.

2.3.9.10.7Need to Release Traffic Signal Controller CommandsCenters need to be able to “remove” a traffic signal controller control command so the host center knows that the control command is no longer required and can be released.

2.3.9.10.8Need to Share Controller Timing Plan and ScheduleCenters need to exchange signal timing plans available for a traffic signal. This includes signal timing parameters such as offsets, splits, and phases.

Centers need to exchange timing plan schedule information to provide coordination across a region (outside a TMC boundary). This includes the schedule of when a signal timing plan will be in effect, and current real-time timing plan activation (phase/movement).

2.3.9.10.9Need to Share Turning Movement and Intersection DataCenters need to exchange turning movement data and intersection layout information. Centers exchanging intersection details need to have a standardized naming convention for turning movement numbering and intersection layout information (phase/movement assignment conventions).

2.3.9.10.10 Need to Share Time Synchronization InformationCenters use a time reference point to establish the time to synchronize the signal timing plans in use. Centers need to exchange time reference information to properly establish traffic signal coordination across a region and between TMC boundaries.

Page 34 of 58


2.3.9.10.11 Need to Share Real-Time Information DataCenters need to exchange real-time information on the current signal timing parameters of a traffic signal. By real-time information, it is meant viewing the signal timing operations, parameters and settings as they occur. Current signal timing parameters include the cycle length, offset, splits, phase and movements. This is a differentiation from what currently exists at a traffic signal (actual) versus the signal timing parameters of a scheduled or ordered signal timing plan (planned).

This real-time information may be used by centers to verify in real-time, current traffic signal coordination within a region (between TMC boundaries) and for maintenance purposes, diagnostic information.

2.3.9.10.12 Need to Share Section InventoryCenters need to exchange inventory information so that sections being operated by a center can become known to other centers. A section is any user-defined group of any number of intersections in any physical arrangement working in a coordinated fashion. Inventory information includes data items such as locations, traffic signals assigned to the section and traffic signal controller attributes.

Centers need to exchange updated inventory information as sections are added to or removed. As centers add, remove, or change traffic signal sections, the updated inventory should be provided to other centers, without requiring operator intervention.

2.3.9.10.13 Need to Share Section StatusCenters need to exchange status information for each coordinated section. A section is any user-defined group of any number of intersections in any physical arrangement working in a coordinated fashion. Status information includes:

Communications status of each traffic signal within the section (connected, disconnected, failed);

Operational status of each traffic signal within the section (working, not-available); and

Current operational state information of each traffic signal within the section, including the section timing plan information (control mode, signal timing parameters, timing plan number, etc.).

2.3.9.10.14 Need to Share Section Command TypesCenters need to exchange what commands are supported by each traffic signal section. Types of commands include:

Device status; Command status; Activate a signal timing plan; Change the mode of operation; Read tables (e.g., signal timing tables); Upload/download signal timing plans; and Diagnostics.

Page 35 of 58


2.3.9.10.15 Need to Command a SectionCenters need to be able to command a traffic signal section operated by another center.

When a control request is received the center that controls the section of traffic signals needs to make a determination if the request will be implemented, queued, or rejected. Then, the center that controls the traffic signal controller needs to send a response to the center that originated the request describing the status (action taken) on the control request. It should be noted that an intersection can only be associated with a single section at any given time.

2.3.9.10.16 Need to Verify Section Command StatusThe center that sends a command to control a traffic signal section device operated by another center needs to verify the status of such a command. The status may be that the command was implemented, was queued, or was rejected.

2.3.9.10.17 Need to View Section Command QueueThe center that originates a command to control a traffic signal section operated by another center needs to view the command queue for that traffic signal section if the command has been queued.

This control model assumes that there may be competing priorities for the use of a traffic signal section, and that a center may implement a queue or priority list of the commands received, whether from the host center itself or external centers, and their priority. External centers thus need to be able to read this queue for multiple devices to determine where their specific command currently “sits”.

2.3.9.10.18 Need to Release Traffic Signal Section CommandsCenters need to be able to “remove” a traffic signal section control command so the host center knows that the control command is no longer required and can be released.

2.3.9.10.19 Need to Share Section Timing Plan and ScheduleCenters need to exchange signal timing plans available for a traffic signal section. This includes signal timing parameters such as offsets, splits, and phases.

Centers need to exchange timing plan schedule information to provide coordination across a region (outside a TMC boundary). This includes the schedule of when a signal timing plan will be in effect, and current real-time timing plan activation (phase/movement).

2.3.10 Need to Share Data for ArchivingArchiving data is generally applied to the areas of traffic monitoring, roadway characteristics, and event data. The archiving of data is also concerned with how that data is collected. The archived data, once collected, can also be exchanged between centers. These centers may be data archives or operational centers.

2.3.10.1 Need for Traffic Monitoring DataCenters need to exchange traffic monitoring data for archival purposes.

Page 36 of 58


2.3.10.1.1Need for Direct Measurements of Traffic Flow and Conditions

Centers seeking archival data need direct measurements of traffic flow and conditions on roadways. The following data types for direct traffic measurements are needed by ADUS: volume, speed, occupancy, travel time, intersection turning movements, queue length, and vehicle classification.

2.3.10.1.2Need for Original Source Data for Traffic Monitoring Measurements

Centers seeking archival data need to preserve original source data as received by the first Center (in this case, the traffic management center) from the field or other external sources. This is the finest resolution of data in terms of temporal and spatial characteristics available. Examples include data on individual vehicles and per lane summaries for short time intervals. Original source data has not had the traffic measurements altered or transformed in any way by a Center.

2.3.10.1.3Need for Processed Traffic Monitoring DataCenters seeking archival data need traffic monitoring data that has been processed (edited, imputed, transformed, or aggregated) by traffic management center (or other Center) functions. Processed traffic monitoring data includes computed or transformed statistics regarding traffic flow and conditions, if these data are created by normal Center functions. (ADUS does not require that processed traffic monitoring data be created, but if it is, it should be passed to the Archive.) Examples include travel time (when derived from device-measured “spot speeds”), “smoothed” traffic measurements, density (when computed from occupancy), capacity, headway, and delay.

2.3.10.2 Need for Data Collection System MetadataCenters seeking archival data need data collection system metadata on field devices used to provide traffic monitoring data. These are data about the conditions and procedures under which original source data were observed, surveyed, measured, gathered, or collected, as well as about the equipment that was used. This includes information about the calibration and maintenance history of field devices; the “health” of detectors; and the situational or contextual characteristics of field devices (e.g., location, lanes monitored, relation to roadway).

2.3.10.3 Need for Processing Documentation MetadataCenters seeking archival data need processing documentation metadata for any traffic monitoring data that has been altered or extended by applying quality control, editing, imputation, transformation, and aggregation functions.

2.3.10.4 Need for Roadway Characteristics DataCenters seeking archival data need attribute data associated with roadway links and intersections. These data include information on roadway alignment, cross-section, restrictions, lane configuration, and lane use.

Page 37 of 58


2.3.10.5 Need for Event DataCenters seeking archival data need data associated with planned and unplanned events including: location, extent, type, severity, lane and shoulder closures, and lifecycle.

2.3.11 Need to Accept Null ValuesCenters need to accept null values for data elements. For specific projects or applications, some data elements cannot be readily shared, are not available or are not applicable.

Page 38 of 58

pchan, 01/23/07,

Where would this belong?


3.0 Requirements

{Place holder for Requirements Section}

Page 39 of 58


4.0 Traceability to the National ITS Architecture

This section provides a detailed mapping of the TMDD MS/ETMCC standard to the National ITS Architecture. Section 2.1 identifies the scope of the TMDD MS/ETMCC standard with regards to interconnects of the National ITS Architecture. This section will expand upon that scope discussion to consider the ITS Services (called Market Packages in the National ITS Architecture) and the specific information flows (called architecture flows in the National ITS Architecture) that will be addressed.

4.1 TMDD MS/ETMCC Trace to Market PackagesMarket Packages represent slices of an architecture that provide a transportation service. In the National ITS architecture, these market packages are combinations of subsystems and architecture flows that are used to provide the service. For example, the Regional Traffic Operations1 market package (ATMS07) identifies the interfaces from one traffic management subsystem to another for the exchange of traffic information and traffic control messages. The following subsections identify the market packages supported by the TMDD MS/ETMCC standard. In all cases the standard supports not the entire market package, but a subset of interfaces. The specific interfaces/ architecture flows covered by the standard are identified in the market package diagrams (taken from the National ITS Architecture Version 5.1) by the ovals.

4.1.1Network Surveillance (ATMS01)The Network Surveillance market package, shown in Figure 6, primarily covers the Traffic Management Subsystem to Roadway Subsystem interface for the collection of traffic flow and

Figure 6. Network Surveillance Market Package

1 Note the name of the ATMS07 market package is being changed to from the current Regional Traffic Control to Regional Traffic Operations as part of update of the National ITS Architecture that is currently underway.

Page 40 of 58

ATMS01 – Network Surveillance

Traffic Management

traffic operator data

traffic operator inputs

Collected TrafficSurveillance

traffic flow +traffic images

traffic sensor control +video surveillance control

Other Roadway

roadwayequipment

coordination

trafficcharacteristics

InformationService Provider

road network conditions

Roadway

Traffic Maintenance

Roadway BasicSurveillance

Traffic

Map UpdateProvider map updates

map update requests

Traffic OperationsPersonnel

Roadway EquipmentCoordination


traffic images data.

The market package also includes the transmission of road network conditions from the Traffic Management Subsystem to the Information Service Provider Subsystem. This center to center interface is described by the TMDD MS/ETMCC standard.

4.1.2Traffic Information Dissemination (ATMS06)The Traffic Information Dissemination market package, shown in Figure 7, covers the roadway interface that provides driver information using roadway equipment such as dynamic message signs or highway advisory radio. The market package also provides the interfaces that distribute traffic information from a traffic management center to the media (for instance via a direct tie-in between a traffic management center and radio or television station computer systems), Transit Management, Emergency Management, and Information Service Providers. These center to center interfaces are covered by the TMDD MS/ETMCC standard.

Figure 7. Traffic Information Dissemination Market Package

Page 41 of 58

ATMS06 – Traffic Information Dissemination

broadcastadvisories

Maintenance andConstructionManagement

Traffic OperationsPersonnel

InformationService

Provider

EmergencyManagement

TransitManagement

TrafficManagement

Roadway

driverinformationroad network conditions

roadway informationsystem data

roadway informationsystem status

Media



media informationrequest



current asset restrictions

road network conditions TMC TrafficInformation

Dissemination

Roadway TrafficInformation

Dissemination


DriverBasic Vehicle

OtherRoadway

roadway equipmentcoordination


4.1.3Regional Traffic Operations (ATMS07)The Regional Traffic Operations market package, shown in Figure 8, provides for the sharing of traffic information and control among traffic management centers to support a regional traffic operations. The key interface from Traffic Management to Other Traffic Management is covered by the TMDD MS/ETMCC standard.

F

igure 8. Regional Traffic Operations Market Package

4.1.4Traffic Incident Management (ATMS08)The Traffic Incident Management market package, shown in Figure 9, describes the subsystems and interfaces to manage both unexpected incidents and planned events so that the impact to the transportation network and traveler safety is minimized. The market package includes incident detection capabilities through roadside surveillance devices (e.g. CCTV) and through regional coordination with other traffic management, maintenance and construction management and emergency management centers as well as rail operations and event promoters. The TMDD MS/ETMCC Standard covers a number of interfaces from Traffic Management to other subsystems (and terminators) as shown in the figure. In a couple of cases (e.g. the Traffic Management to Emergency Management interface) covers a portion of the defined interface rather than the whole interface.

Page 42 of 58

ATMS07 – Regional Traffic Control

freeway control status

RoadwayTraffic Management

TrafficOperationsPersonnel

signal control data



TMC FreewayManagement

signal control status

traffic flow

freeway control data

Other TrafficManagement

trafficcontrol

coordination

trafficinformationcoordination

traffic sensor controlTMC RegionalTraffic Control

TMC Signal Control


Figure 9. Traffic Incident Management Market Package

4.1.5Road Weather Data Collection (MC03)The Road Weather Data Collection market package, shown in Figure 10, collects current road and weather conditions using data collected from environmental sensors deployed on and about the roadway. The interfaces that are covered by the TMDD MS/ETMCC standard are the ones between the Traffic Management and Maintenance and Construction Management subsystems and the Weather Service and the Surface Transportation Weather Service (environmental conditions data).

Page 43 of 58

ATMS08 – Traffic Incident Management System

road networkconditions

Roadway

Traffic Management

traffic flow +traffic images

video surveillancecontrol +

traffic sensor control

incident information+ maint and constrresource response


Emergency Management

incidentstatus

Other EmergencyManagement

Other TrafficManagement

loggedvehicle route

incidentinformation

traffic informationcoordination

incident information + resource request + remote surveillance control

road network conditions +incident information + traffic images +

resource deployment status

Roadway IncidentDetection

MCM IncidentManagement

Emergency ResponseManagement

InformationService

Provider

incident information+ maint and constr

resource request

TMC Incident DispatchCoordination/

Communication

incident information + maint and constr resource request + incident response status


incident information + maint and constr resource response

EventPromoter

event plans event plans

OtherMCM

maint and constrresource

coordination

OtherRoadway

TMC IncidentDetection

roadwayequipment

coordination

incident response coordination +incident command information coordination

EmergencyPersonnel

incident commandinformation presentation

RailOperations

TransitManagement

incident response status +incident information

incident information +incident response statusincident information + rail

incident response status

IntermodalFreight Depot

intermodal freighttraffic confirmation

Incident Command

Emergency Vehicle

On-board EV IncidentManagement

Communication

incident command inputs

decision supportinformation

-------------------------------------


Figure 10. Road Weather Data Collection Market Package

4.1.6Roadway Maintenance and Construction (MC07)The Roadway Maintenance and Construction market package, shown in Figure 11, supports numerous services for scheduled and unscheduled maintenance and construction on a roadway system. The one interface of this market package covered by the TMDD MS/ETMCC standard is the sending of field equipment status from Traffic Management to Maintenance and Construction Management.

Page 44 of 58

MC03 – Road Weather Data Collection

environmentalprobe data

environmental conditions data

environmentalconditions data

environmental conditions environmental conditions

environmentalconditions

environmentalprobe

data

environmentalsensors control

environmental sensors control

environmental conditions data





environmental probe data

**

road network probe information

Maintenance and Construction

Vehicle

MCV Environmental

Monitoring

Maintenance and Construction Management

MCM EnvironmentalInformation Collection

SurfaceTransportation

Weather Service

RoadwayEnvironment Vehicle

Smart Probe

Information Service

Provider

ISP Probe InformationCollection

Roadway

Roadway EnvironmentalMonitoring

Roadway Probe Beacons

Traffic Management

TMC ProbeInformation Collection

TMC EnvironmentalMonitoring

WeatherService



environmental sensors control


road data

environmentalprobe data


WeatherService


Figure 11. Roadway Maintenance and Construction Market Package

4.1.7 ITS Data Mart (AD1)The ITS Data Mart market package, shown in Figure 12, provides a focused archive that houses data collected and owned by a single agency, district, private sector provider, research institution, or other organization. The interface from Traffic Management to Archive Data Management is one of the areas that have been explicitly added to the TMDD MS/ETMCC standard.

Figure 12. ITS Data Mart Market Package

Page 45 of 58

MC07 – Roadway Maintenance and Construction

Weather ServiceSurface

TransportationWeather Service

Maintenance and

ConstructionManagement

Maintenance and

ConstructionVehicle

asset inventory +asset restrictions +

maintenance and repair needs

TrafficManagement

equipment maintenance status

infrastructure monitoringsensor control

Maintenance andConstruction

Administrative Systems maint and constradministrative information

maint and constrwork performance

maint and constrvehicle system control

maint and constr vehicleoperational data +

infrastructure conditions data

asset status update

MCM RoadwayMaintenance

And Construction

TrafficMaintenance

MCV RoadwayMaintenance

and Construction

field device status +infrastructure monitoring

sensor data

field equipment status

MCM MaintenanceDecision Support

Basic Maintenanceand Construction

Vehicle

AssetManagement

StorageFacility

EmergencyManagement

Roadway

RoadwayField DeviceMonitoring

weather information transportation weatherinformation

equipment availability +maintenance materials

storage status

maint andconstrvehicle control

maint and constrmaterial information

MCV InfrastructureMonitoring

infrastructure monitoring sensor data

infrastructure monitoring sensor control

security field equipment status

AD1 - ITS Data Mart

Archived Data Management

Government Reporting Systems Support

Archived Data Administrator

Archived Data User Systems

archive requests +archive status

archived data products archive management data

traffic archive data

archived data product requests

archive management requests

Traffic Management

Traffic Data CollectionITS Data Repository

* This market package uses a single ITS data source. Any of the following ITS data sources can be the source for an ITS Data Mart. The Traffic Management Subsystem is shown as an example.

Data Sources:•Commercial Vehicle Administration•Emergency Management•Emissions Management •Information Service Provider•Maintenance and Construction Management•Parking Management•Toll Administration•Traffic Management•Transit Management

•Asset Management•Intermodal Freight Depot•Multimodal Transportation Service Provider•Other Data Sources•Surface Transportation Weather Service•Weather Service

government reporting system data Government

ReportingSystemsgovernment reporting

data receipt

map update requestMap Update

Provider map updates

Roadway

Roadway DataCollection

data collection and monitoring control

roadside archive data

Traffic and RoadsideData Archival*


4.1.8 Emergency Call-Taking and Dispatch (EM01)The Emergency Call-Taking and Dispatch market package, shown in Figure 13, provides basic public safety call-taking and dispatch services. The interface from Emergency Management to Traffic Management for remote surveillance control is covered by the TMDD MS/ETMCC standard.

Figure 13. Emergency Call-Taking and Dispatch Market Package

4.1.9Emergency Routing (EM02)The Emergency Routing Market Package, shown in Figure 14, supports automated vehicle location and dynamic routing of emergency vehicles. The providing of road network conditions from Traffic Management to Emergency Management is covered by the TMDD MS/ETMCC standard

Page 46 of 58

EM01 – Emergency Call-Taking and Dispatch

remote surveillance control

traffic images

emergency operations status

EmergencyManagement

map updates

TrafficManagement

EmergencySystem Operator

Map UpdateProvider

map update requests EmergencyCall-Taking

incident notification response

TransitManagement

Other EmergencyManagement

EmergencyTelecommunications

System

incident notification

transit emergency data

incident report +incident response coordination

emergency operations inputs

emergency vehicle tracking data

emergency dispatch requests

EmergencyVehicle

On-board EV En Route Support

emergency dispatch response

Fleet and Freight

Management

alarm

EmergencyDispatch

EmergencyPersonnel

emergencypersonnelinputs

emergency personal information presentation


Figure 14. Emergency Routing

4.1.10 Disaster Response and Recovery (EM08)The Disaster Response and Recovery market package, shown in Figure 15, supports the emergency management and transportation management response to major disasters. The market package identifies the key points of integration between transportation systems and the public safety, emergency management, and other allied organizations that form the overall disaster response. In this market package, the Emergency Management subsystem represents the federal, regional, state, and local Emergency Operations Centers and the Incident Commands that are established to respond to the disaster. The interface between the Emergency Management Subsystem and the other center subsystems provides situation awareness and resource coordination among transportation and other allied response agencies. In its role, traffic management implements special traffic control strategies and detours and restrictions to effectively manage traffic in and around the disaster. As immediate public safety concerns are addressed and disaster response transitions into recovery, this market package supports transition back to normal transportation system operation, recovering resources, managing on-going transportation facility repair, supporting data collection and revised plan coordination, and other recovery activities. The interface from Traffic Management to Other Traffic Management, as well as portions of the Traffic Management to Emergency Management and Traffic Management to Maintenance and Construction Management interfaces are covered by the TMDD MS/ETMCC standar.

Figure 15. Disaster Response and Recovery Market Package

Page 47 of 58

EM02 – Emergency Routing

TrafficManagement

road networkconditions + emergency routes +emergency traffic control information

emergency vehicle tracking data suggested route

signal control dataRoadway

credentials information

EmergencyManagement

care facility status request

current asset restrictions +roadway maintenance status +

workzone information

care facility status request +patient status

vehicle location


EmergencyPersonnel

EmergencySystem Operator

Map UpdateProvider

emergency operations inputs

CareFacility

emergency personnel inputs

RoadwaySignal Priority

request for right-of-way + signal control status

emergency trafficcontrol request +emergency route

request

EmergencyVehicle

local signalpreemption request

Vehicle

Vehicle LocationDetermination

emergency personal information presentation

care facility status

care facility status

emergency operations status

map update request

map updates

On-board EVEn Route Support

Emergency Routing

TMC Incident DispatchCoordination/

Communication

TMC Signal Control


4.2 TMDD Trace to Architecture FlowsThe “Traceability to National ITS Architecture Matrix” provides the linkage between TMDD MS/ETMCC requirements and the architecture flows between traffic management subsystem (TMS), other subsystems and system terminators. The architecture flows in the National Architecture Matrix are based on version 5.1 of the National ITS architecture. The matrix shows all of the architecture flows covered by the TMDD MS/ETMCC standard. In this first draft of the matrix, the mapping to Con Ops section has not yet been filled in, and some of the rows have the comment that they are TBD (to be determined), indicating that coverage of these architecture flows is still a subject of discussion in the development.

The following terms and definitions have been employed in the subject matrix:

Source Name: The full name of the source subsystem or terminator.

Destination Name: The full name of the destination subsystem or terminator.

Architecture Flow: The name of the information flowing directionally from the source to the destination.

Specific ConOps Reference: The lower level TMDD MS/ETMCC ConOps paragraph numbers that relate to the architecture flow.

Requirements: The TMDD MS/ETMCC Requirements paragraph numbers that relate to the architecture flow.

Page 48 of 58


Table 1. Traceability to National ITS Architecture Source Name Destination Name Architecture Flow ConOps

ReferenceRequirements Comments


Traffic Management archive requests


Traffic Management archive status

Emergency Management Traffic Management incident information Coordination with IEEE 1512 needed

Emergency Management Traffic Management incident response status Coordination with IEEE 1512 needed

Emergency Management Traffic Management remote surveillance controlEmergency Management Traffic Management road network probe information Coverage is TBDEvent Promoters Traffic Management event plansInformation Service Provider

Traffic Management road network probe information Coverage is TBD


Traffic Management incident information Coordination with IEEE 1512 needed


Traffic Management road network status assessment Coverage is TBD


Traffic Management road weather information

Media Traffic Management external reportsMedia Traffic Management media information requestOther Traffic Management

Traffic Management traffic control coordination

Other Traffic Management

Traffic Management traffic information coordination

Surface Transportation Weather Service

Traffic Management environmental conditions data

Surface Transportation Weather Service

Traffic Management transportation weather information

Page 1 of 58


Source Name Destination Name Architecture Flow ConOps Reference

Requirements Comments

Toll Administration Traffic Management probe data Coverage is TBDTraffic Management Archived Data

Managementtraffic archive data

Traffic Management Emergency Management incident information Coordination with IEEE 1512 needed

Traffic Management Emergency Management road network conditionsTraffic Management Emergency Management road network status assessment Coverage is TBDTraffic Management Information Service

Providerroad network conditions

Traffic Management Maintenance and Construction Management

field equipment status




road network status assessment Coverage is TBD

Traffic Management Media road network conditionsTraffic Management Other Traffic Management traffic control coordinationTraffic Management Other Traffic Management traffic information coordinationTraffic Management Surface Transportation

Weather Serviceenvironmental conditions data

Traffic Management Transit Management road network conditionsTraffic Management Weather Service environmental conditions dataTransit Management Traffic Management road network probe information Coverage is TBDWeather Service Traffic Management environmental conditions data

Page 2 of 58


5.0 Needs and Requirements Traceability Matrix

{Place holder for Needs to Requirements Traceability Matrix Section}

Page 1 of 58


User Need

IDUser Need FR ID Functional Requirement

Project Requirement

?Additional Project

Requirements

Page 2 of 58

final draft of the tmdd ms/etmcc concept of operations

Technology