910.4 ITS Architecture

MoDOT is developing a statewide approach to Intelligent Transportation Systems (ITS) implementation. This article, an ITS Architecture Package, documents a framework that will assist in coordinating future ITS planning, deployment and operations activities for Missouri. Currently, freeway management, arterial management, commercial vehicle, and other systems are being deployed in the state. As part of the statewide plan, market packages were prioritized and presented in the Market Package Report. The ITS Architecture Package captures the status of ITS development in Missouri at a given time (2002) and should be viewed as a dynamic tool. It is recommended that MoDOT revisit the architecture on an annual basis updating and tracking the development of ITS in Missouri through an active architecture revision process.

Additional Information

Kansas City Regional ITS Architecture

Springfield/Branson Regional ITS Architecture

Bi-State St. Louis Regional ITS Architecture

Systems Engineering Analysis standard format

System Interface Diagrams

Regional ITS Architecture Report

What is a Market Package?

A Market Package represents slices of the Physical Architecture addressing specific services such as surface street control. Market packages collect several different subsystems, equipment packages, terminators and architecture flows providing the desired service.

The term ITS Architecture has different meanings to a wide array of stakeholders, especially when discussed within a statewide context. USDOT has significant guidance on what is required to adequately document regional and project level architectures but little on a statewide or multi-state basis. Therefore, by way of clarification, this article serves as a:

Guide for planning and deployment of ITS on statewide basis. The previously developed ITS Market Package Report has prioritized program areas and will serve to guide MoDOT’s statewide ITS Program as it continues to evolve and mature.

Recommendation of essential, or core, High Priority ITS Program Areas. Core ITS program areas have been developed through a series of prioritization exercises that incorporate the needs of numerous Missouri stakeholders. The core ITS program areas also assist in cutting through a wide array of terminology related to ITS architecture and provides clear, strategic direction to support future technology related investment. The six core ITS Program areas described in this architecture package are based on prioritization tools developed as part of the statewide plan. The prioritized areas are:

commercial vehicle operations

incident management

traffic control and monitoring

traveler and weather information

transit management

maintenance and construction operations

Framework for fostering Interagency Relationships for core ITS Program Areas. A baseline of roles and responsibilities for the core ITS Program areas have been developed to support future inter- and intra-agency coordination and are presented in EPG 910.4.4 Operational Concept.

Initial Screening of Critical ITS Standards to support core ITS Program Areas. For each core ITS Program Area, Applicable Standards and a current status of NTCIP standards development is provided.

Recommended timeframe for deploying core ITS Program Areas.

This article is not intended to serve as a:

Regional or Project Level ITS Architecture. Regional and Project Architectures have or are in the process of being developed for the Kansas City, St. Louis and Springfield metropolitan areas.

Preliminary or Final Design Document. This article does not evaluate potential technology alternatives are determine appropriate levels of deployment to support the recommended core ITS Program Areas

Capital Investment, Staffing or Operations Resource Plan. This article does not examine the capital, staffing, or maintenance costs associated with the core ITS Program Areas.

Electronic Integration of previously developed Regional and Project Architectures. Comprehensive Regional Architecture electronic databases have been developed, or are currently under development, in the Kansas City, St. Louis and Springfield metropolitan areas. Project resources do not allow for the development an electronic database at the state level since it would include sorting of thousands of architecture data flows. Alternatively, each Regional ITS Architecture has been reviewed and several common trends that support the core ITS Program areas have been integrated into the report.

910.4.1 ITS Architecture Overview

910.4.1.1 General Description

The National ITS Architecture provides a common framework for planning, defining and integrating intelligent transportation systems. A system or regional architecture serves the same function as the National ITS Architecture. Using the National Architecture as a model, the regional architecture can be described as a tool that “…provides a common structure for the design of intelligent transportation systems. It is not a system design nor is it a design concept. What it does is define the framework around which multiple design approaches can be developed, each one specifically tailored to meet the individual needs of the user, while maintaining the benefits of a common architecture…”

Using the National ITS Architecture to generate a regional model requires an understanding of the national architecture’s basic elements. General awareness of these elements further assists in the presentation of the information and a greater chance that information is applied.

The National ITS Architecture is comprised of two architectures referred to as the physical and logical. The physical architecture piece of the National Architecture deals with the interaction of real-world elements such as an agency center, a traveler, roadside equipment or a vehicle. Conversely, the logical architecture defines the processes that carry out different ITS functions by establishing the data being exchanged and the form that data will take. Both the logical and physical architectures serve as mechanisms to describe the interaction of various elements in the architecture and are beneficial in different ways. A physical architecture is easier to comprehend since it deals with tangible and more widely understood transportation elements such as a vehicle, equipment, a roadway or dispatch center and establishes how those elements can be connected to form a system. The logical architecture deals with processes and functions typically hidden from view, but required to perform some action such as a database query.

The Missouri Statewide ITS Architecture is essentially a high-level physical architecture. The statewide architecture shown will illustrate the interconnection between different regional centers, vehicles, and roadside equipment. Although a logical architecture is not presented as part of the statewide architecture, elements of the logical architecture are present in the physical architecture’s “architecture flows” that have been developed (or are in the process of being developed) for the St. Louis, Kansas City and Springfield Regional Architectures.

910.4.1.2 Federal Rules

On January 8, 2001 a Notice of Final Rule Making was issued implementing the requirements of section 5206(e) of the Transportation Equity Act for the 21st Century (TEA-21). The section required federally funded ITS projects to conform to the National ITS Architecture. However, it recognized that not all elements of the National Architecture may be applicable for every state, region or major metropolitan area, thus “Conformance with the National ITS Architecture is interpreted to mean the use of the National Architecture to develop a regional architecture, and the subsequent adherence of all ITS projects to that regional ITS architecture. This rule requires that the National ITS Architecture be used as a reference in developing a regional ITS architecture.” Thus development of multiple “regional architectures” shows compliance with section 5206(e) and allows federal funding for future ITS projects in Missouri. The USDOT has published additional clarification indicating regional and project level architecture requirements. The requirements are described as follows:

Regional ITS Architecture Documentation Requirements

Components of the Regional ITS Architecture shall include:

A description of the region
Identification of participating agencies and other stakeholders
An operational concept that identifies the roles and responsibilities of participating agencies and stakeholders in the operations an implementation of the system included in the regional ITS architecture
Any agreements (existing or new) required for operations, including at a minimum those affecting ITS project interoperability, utilization of ITS related standards and the operation of the projects identified in the regional ITS architecture
System functional requirements
Interface requirements and information exchanges with planned and existing systems and subsystems (i.e., architecture flow diagrams)
Identification of ITS standards supporting regional and national interoperability
The sequence of project required for implementation

The Regional ITS architecture requires 4 years to develop, starting on the date of the region’s first ITS project or from the date of the final rule where there are existing systems. The Regional ITS architecture develops and implements procedures and responsibilities for maintaining architecture databases, as needs evolve within the region.

Project ITS Architecture Documentations Requirements

If an ITS project uses federal funds or “highway trust funds” then a systems engineering analysis (SEA) must be completed. The SEA must include the following information:

Identify portions of the regional ITS architecture being implemented
Identify participating agencies’ roles and responsibilities
Analyze alternative system configuration and technology options to meet requirements of the project and the system
Procurement Options
Identify applicable ITS standards and test procedures (Table 910.4.5.3 for applicable standards)
Procedures and resources necessary for Operations and Maintenance of the system.

A standard format has been provided for use when creating a SEA. The SEA should be stored in the project files and kept according to MoDOT document retention policy.

The project shall also work with the regional ITS architecture. Specifically, it shall “accommodate the interface requirements and information exchanges” that are within the regional architecture. If the regional ITS architecture is not completed and an ITS project enters final design then it will have project level architecture. The project level architecture is based off the SEA and will include the following information:

Description of project scope
Roles and responsibilities of participating agencies/stakeholders in operation/implementation of the project
Functional requirements of the project
Interface/information exchange requirements between other planned/existing systems/subsystems
Applicable ITS standards.

910.4.1.3 Impact of Rules on Missouri

Apart from being required for federal funding, a regional ITS architecture provides a useful planning reference as it gives insight into stakeholders needs during development and design phases of ITS projects. The USDOT recommends and lends guidance for projects using federal funds to have appropriate references to previously developed regional and/or project level architectures. Therefore, it is always in good practice for a project implementation plan to have proper architecture documentation to avoid deployment delays due to architecture compliance.

910.4.1.4 Common ITS Architecture Terminology and Descriptions

ITS architecture terms can be difficult to understand without formal training or routine exposure. The following sections describe common terminology often referenced with respect to the development of regional or project level architectures.

910.4.1.4.1 Overview of Physical Architecture

The Physical Architecture, as mentioned, is part of the National ITS Architecture and is used to portray real-world transportation facilities and infrastructure elements. The Physical Architecture uses a set of 21 subsystems representing and describing different transportation elements. The physical architecture also details the interaction between those elements.

The Physical Architecture is referenced as a “high-level view” of the National Architecture, since it deals with “physical” elements and not the function or data exchanges behind the operation of those elements, which is performed under the Logical Architecture. The Physical Architecture serves as a way to define how agencies, roadside equipment, travelers and vehicles are connected and how basic information is shared between them. There are three components that make up the Physical Architecture: subsystems, terminators and architecture flows.

There are also three diagrams typically used to illustrate how information is shared between components in the physical architecture: sausage, interconnect and architecture flow.

Figure 910.4.1.4.1, Physical Architecture Development Process, further describes the ITS Physical Architecture development process, the relationship between diagrams and the key questions answered during each development phase. The process includes a series of “drilling down” exercises requiring input from stakeholders.

Each physical architecture element and diagram is further explained below to generate an understanding of how they portray actual transportation infrastructure elements and the interaction between those elements.

910.4.1.4.1.1 Subsystems

Under the National ITS Architecture the physical architecture contains facilities and infrastructure elements that are grouped into four classes of “subsystems”. The four classes of subsystems are identified as center, roadside, vehicle and traveler. Each class is described below using the definition adopted from the National ITS Architecture.

Center Subsystems provide management, administrative and support functions for the transportation system. The center subsystems each communicate with other centers to enable coordination between modes and across jurisdictions. The ten center subsystems are Traffic Management, Transit Management, Commercial Vehicle Administration, Archived Data Management, Emissions Management, Toll Administration, Emergency Management, Information Service Provider, Fleet and Freight Management and recently added Maintenance and Construction Management¹. An example of a center subsystem could be the KC Scout Traffic Operations Center or the Gateway Guide Transportation Information Center.

Roadside Subsystems. Intelligent infrastructure distributed along the transportation network which perform surveillance, information provision and plan execution control functions and whose operation is governed by center subsystems. Direct interface to vehicle subsystems exist.² An example of a roadside subsystem could be a variable message sign on the interstate.

Vehicle Subsystems cover ITS related elements on vehicle platforms. Vehicle subsystems include general driver information and safety systems applicable to all vehicle types. Four fleet vehicle subsystems (Transit, Emergency, Commercial Vehicles and the newly added Maintenance and Construction) add ITS capabilities unique to these special vehicle types.³ Examples of vehicle subsystems include automatic vehicle location systems on transit vehicles or the Emergency Response vehicles.

Traveler Subsystems are equipment used by travelers to access ITS services pre-trip and en route. This includes elements that are owned and operated by the traveler as well as elements that are owned by transportation and information providers.⁴ An example of a traveler subsystem could be an information kiosk at an airport.

**Figure 910.4.1.4.1.1, Physical Architecture Subsystems Classes**

Twenty-one different subsystems are organized under each of the four classes and defined under the National ITS Architecture. Each of the 21 subsystems corresponds to real-world elements such as a transit management facility, traffic controller, vehicle, or motorist.

¹ USDOT, National ITS Architecture, Version 4.0, Physical Architecture, Center Subsystem

² USDOT, National ITS Architecture, Version 4.0, Physical Architecture, Roadside Subsystem

³ USDOT, National ITS Architecture, Version 4.0, Physical Architecture, Vehicle Subsystem

⁴ USDOT, National ITS Architecture, Version 4.0, Physical Architecture, Traveler Subsystem

910.4.1.4.1.2 Terminators

Terminators represent the outer limits of the National ITS Architecture. In the physical architecture terminators function as boundaries for information exchanged. Typically terminators only interact with a single subsystem and to not link together multiple system elements similar to subsystems. There are four categories of terminators. These categories are environment, human, other system and system. An example of a terminator in the human category would be a traveler, or individual who uses transportation services. Or an example of a system terminator would be a specific state agency responsible for registering vehicles such a Department of Motor Vehicles (DMV).

910.4.1.4.1.3 Architecture Flows

Architecture Flows are the information exchanged between subsystems and terminators in the physical architecture. Architecture flows are the primary tool that is used to define regional architecture interfaces. These architecture flows and their communication requirements define the interfaces that form the basis for much of the ongoing standards work. An example of an information flow would be a statewide traffic information center requesting traffic information from a regional center such as KC Scout or Gateway Guide.

910.4.1.4.1.4 High Level Physical Architecture / Sausage Diagram

The “sausage diagram” is considered the high level interconnect diagram for the National ITS Architecture. It illustrates how different subsystems connect and the communication methods that facilitate the data exchanges between them. As a high level diagram it only shows the interconnection between different subsystems and does not provide specific details on the exact information and data exchanged.

**Figure 910.4.1.4.1.4, Physical Architecture Sausage Diagram**

910.4.1.4.1.5 Interconnect Diagram

The interconnect diagram highlights the communication interaction between multiple subsystems or between a subsystem and terminators. The diagram details communication paths between the architecture elements showing how information is routed. The type of communications system reflected by the interconnect flow can be one of four types that include wireline, wide area wireless, dedicated short range or vehicle-to-vehicle. Additional communications types such as human and physical/environmental interfaces can also be represented by interconnect flows.

**Figure 910.4.1.4.1.5, Physical Architecture Interconnect Diagram**

910.4.1.4.1.6 Architecture Flow Diagram

The architecture flow diagram further elaborates on the information provided by the interconnect flow diagram. Whereas, the interconnect diagram indicates the communication path between elements the architecture flow diagram details the information exchanged on that path. Typically a single interconnect flow represent one or more architecture flows which detail the type and direction information exchanges on the interconnect take between subsystems or terminators in the system.

**Figure 910.4.1.4.1.6, Physical Architecture “Architecture Flow” Diagram**

910.4.1.4.1.7 Market Packages

A market package provides an accessible, service-oriented perspective to the National ITS Architecture. They are tailored to fit, separately or in combination, real world transportation problems and needs. Examples of market packages include: network surveillance, emergency response, and maintenance and construction vehicle tracking. Market packages are a collection of one or more groupings of implementable processes. These processes must work together to deliver a given transportation service and the architecture flows that connect them and other important external systems. In other words, they identify the pieces of the physical architecture that are required to implement a particular transportation service. There are currently 75 Market Packages included in the most recent version of the National ITS Architecture (Version 4.0) that was planned for mass public release in April 2002. The most significant impact to Missouri is the additional 10 market packages oriented to support Rural ITS services. Since Kansas City and St. Louis have existing Emergency Response Programs, the addition of the Roadway Service Patrol Market Package will have an impact on existing regional architectures. Additional discussion on Market Packages and their use in prioritizing core ITS Program Areas in Missouri is provided in EPG 910.4.3 Missouri ITS Program Areas.

910.4.1.4.2 Overview of Logical Architecture

Another architecture contained within the National ITS Architecture is referred to as the logical architecture. The logical architecture describes the functionality of an ITS system and details how user services are supported. It establishes the processes that execute the functionality and the information distributed between those processes. The logical architecture, like the physical architecture, does not mandate a particular technology for implementation, rather it allows for flexibility in system deployment.

The Logical Architecture uses the following elements to define and illustrate system functionality: processes, process specifications, data flows, data dictionary entries and data flow diagrams.

The Missouri Statewide ITS Architecture drills down to the physical, interconnect level. However, the previously mentioned physical architecture elements can be further decomposed to develop a logical architecture. Thus, brief overviews of the elements comprising a logical architecture are presented for reference.

910.4.1.4.2.1 Processes

A process is a function or activity that is needed to support an ITS User Service. It is utilized in the logical architecture to represent high-level general actions and also more detailed functions. An example of how processes are used to represent general and specific functions can be demonstrated by looking at the general process “Manage Traffic” in the National ITS Architecture. The “Manage Traffic” process identified can be further broken down into the following more detailed processes specifying components of traffic to be managed:

“Provide Traffic Surveillance”

"Manage Incidents”

“Provide Device Control”

“Manage Emissions”

“Manage Travel Demand”

“Manage Highway Rail Intersections”

Each additional process can be further broken down until you reach “primitive processes” representing not only the lowest level process but also the most specific or detail function.

910.4.1.4.2.2 Process Specification

Process specifications are the most detailed processes defined by the logical architecture. Process specifications contain a description, list of functional requirements and a set of inputs and outputs, generally referenced as Pspec.

910.4.1.4.2.3 Data Flow

Data flows represent information exchanged between processes in the logical architecture. Data flows indicate the type and direction information travels between processes. Combinations of data flows are also used to define architecture flows deployed in the physical architecture. Individual data flows are generally defined in a data dictionary entry.

910.4.1.4.2.4 Data Dictionary Entries

A data dictionary is used in the logical architecture to describe a data flow’s characteristics. A data dictionary entry (DDE) contains a description of the data flow and highlights additional lower level data elements that are part of that flow. Lower level data elements are also define by separate DDEs.

910.4.1.4.2.5 Data Flow Diagram

The data flow diagram illustrates the processes and data exchanges in a logical architecture. The diagram consists of four elements each with a unique symbol. The functions or processes in the diagram are represented by circles and perform different architecture tasks. Lines with arrows indicate the movement of information or data between diagram elements and represent data flows. “Data at rest” in the system is represented by parallel lines and are referred to as data stores. The last diagram element is a terminator, which is represented by a rectangle and depicts an endpoint or boundary for the architecture.

**Figure 910.4.1.4.2.5, Typical Logical Architecture Data Flow Diagram**

910.4.1.5 Status of ITS Architecture Initiatives

Several ITS Architecture initiatives are being developed or have been completed in Missouri. Below is a brief description of various ITS Architecture related projects.

910.4.1.5.1 Kansas City Area

The Kansas City Metropolitan Region is developing a regional ITS architecture through the use of a Tier 2 Workshop lead by the National ITS Architecture Team in Kansas City. The Mid America Regional Council (MARC), the regional metropolitan planning organization, maintains the current database.

910.4.1.5.2 St. Louis Area

The St. Louis Metropolitan Region is developing a regional ITS architecture through the use of a Tier 2 Workshop lead by the National ITS Architecture Team in St. Louis. MoDOT District 6 personnel maintain the current database.

A project architecture to support the I-270/255 Corridor Project was also developed. The scope of the deployment project includes installation of five systems: Traffic Management System, Local Traffic Operations System, Local Emergency Response System, Transit Management System and Information Service Providers. The five systems are interrelated and contain subsystems that can also be interconnected within each system.

910.4.1.5.3 Springfield Area

The City of Springfield, in close cooperation with MoDOT, leads the development of the Regional ITS Architecture.

910.4.1.5.4 State Business Plan for CVISN

The State Business Plan for Commercial Vehicle Information Systems and Networks (CVISN) was completed in late 2000. The report includes the definition of several projects associated with Level 1 CVISN deployment in Missouri including a high level physical architecture. However, the physical architecture does not directly map to the National ITS Architecture and did not use the USDOT endorsed database-mapping tool (i.e., TurboArchitecture). CVISN activities are lead by Traffic.

910.4.1.6 Emerging National ITS Architecture Developments

A new version (Version 4.0) of the National ITS Architecture was ready for mass distribution in April 2002. While most regional and project ITS architecture have been developed using Version 3.0 as a base, the statewide architecture has captured some of the key enhancements provided in Version 4.0. Some of the major enhancements to Version 4.0 that impact the statewide architecture include:

Addition of the Maintenance and Construction Service Area. New market packages directly related to providing maintenance and construction services have been added. The 10 new Market Packages include:

maintenance and construction vehicle tracking

maintenance and construction vehicle maintenance

road weather data collection

weather information processing and distribution

roadway automated treatment

winter maintenance

roadway maintenance and construction

work zone management

work zone safety monitoring

maintenance and construction activity coordination

Enhanced Weather Coverage. An overarching view of weather information in the National ITS Architecture was created through defining two market packages (Road Weather Data Collection and Weather Information Processing and Dissemination) that encompass all aspects of weather information in the architecture. In addition, the architecture flows relating to weather were expanded to provide a more complete view of this important area.

Improved Rural User Needs Coverage. Changes and additions have been made to the architecture to satisfy the "Rural User Needs" requirements in the industry. Areas of the architecture affected include the creation of a new terminator called the "Care Facility" and enhancing remote area surveillance to include rest areas, park and ride lots, emergency pull-off areas, etc.

Roadway Service Patrols Coverage. Additions have been made to the architecture to accommodate an increased use of roadway service patrols throughout the country. The new market package accurately encompasses the existing functions of the Emergency Response Patrol in Kansas City and St. Louis.

910.4.2 Missouri High Level Physical Architecture

910.4.2.1 Geographical Limits of ITS Architecture

The geographical limits of the Missouri Statewide ITS Architecture include the entire state and the metropolitan areas of Kansas City and St. Louis extending into Kansas and Illinois, respectively. Missouri’s highway system is more than 32,000 miles long, the nation’s seventh-largest state highway system.⁵ Missouri is also coordinates with eight neighboring states.

⁵ Missouri Department of Transportation 2000 Annual Report, pg. 14.

910.4.2.2 Participating Agencies and Other Stakeholders

The regional architectures developed for Kansas City and St. Louis metropolitan areas generated databases with hundreds of participating agencies and stakeholders. The purpose of the Statewide ITS Architecture is to document relationship between agencies that provide services that are statewide in nature or have regional significance. Therefore, instead of recreating every municipality in the regional architectures, the statewide architecture has generalized the county and municipal services. The stakeholders reflected in the Statewide ITS Architecture are:


MoDOT Central Office	MoDOT district offices
Kansas City Scout	St. Louis Gateway Guide
Statewide Traffic Operations Center	Springfield Traffic Management System
Branson TMC and TRIP	KDOT Metro Operations Area
IDOT St. Louis Area Traveler Information Center	MoDOT Emergency Response
Missouri State Highway Patrol	Metro Traffic Networks
County Public Works	Municipal Public Works
County Public Safety	Municipal Public Safety
Bi-State Development Agency (St. Louis)	Kansas City Area Transit Authority
OATS, Inc.	Federal Motor Carrier Safety Administration
Southern Missouri Trans. Systems (STMS), Inc.	Missouri Dept. of Revenue – Highway Reciprocity Commission
MoDOT Motor Carrier Services Unit	Missouri State Highway Patrol Commercial Vehicle Inspection Unit
Commercial Trucking Companies	Missouri Dept. of Economic Development Division of Motor Carrier and Rail Safety
International Registration Plan, Inc.	International Fuel Tax Association
Missouri Dept. of Natural Resources	Mid-America Regional Council (Kansas City)
Kansas City Police Dept.	St. Louis Police Dept.

910.4.2.3 High Level Physical Architecture Diagram (i.e., Sausage Diagram)

Systems have been categorized into four deployment status categories: existing, proposed/in progress, short-term and medium/long term. The short and medium/long term subsystem were developed to support the core ITS Program Areas further discussed in Section 4 of the report.

**Figure 910.4.2.3, Missouri Statewide High Level Physical Architecture Diagram, ie. Sausage Diagram, as of 2002**

910.4.3 Missouri ITS Program Areas

910.4.3.1 Background and Development of CORE ITS Program Areas

To clarify on which ITS-related businesses MoDOT should focus, several core ITS Programs have been developed. The core ITS Program areas were developed based on results from the Market Package Prioritization Tool. Each Market Package was prioritized based on five different deployment settings: urban, semi-urban, rural, corridor and statewide. The core ITS Program development process, which is an extension of the physical ITS architecture development process shown previously in Figure 910.4.1.4.1, is further illustrated in Figure 910.4.3.1.

**Figure 910.4.3.1, Core ITS Program Area Development Process**

Results of the prioritization were screened and market packages scoring in the top 30% of the assessment were grouped in the following logical program areas:

Commercial Vehicle Operations

Incident Management

Traffic Control and Monitoring

Traveler and Weather Information

Transit Management

Emergency Management and MCO

For additional information in the results if the market package prioritization, see the Market Package Report. The market prioritization presented here in the development of this statewide architecture is for a time captured in August 2001. The statewide plan and architecture are dynamic documents as advancements in deployment occur in Missouri. The architecture presented here will require routine maintenance by MoDOT as revisions occur using the prioritization tool and deployments advance.

910.4.3.2 Description and Market Package Composition of Each Program Area

The following sections provide a summary of the proposed market packages for deployment consideration throughout Missouri (i.e., deployment setting) and definitions of each market package composing the core ITS Program Areas.

910.4.3.2.1 Commercial Vehicle Operations (CVO)

The Commercial Vehicle Operations ITS Program is composed of the following three market packages and associated deployment areas/settings:

Electronic Clearance, Statewide
Weigh In Motion, Statewide
Commercial Vehicle Administrative Process, Statewide

For reference purposes, definitions of each market package are provided below: Electronic Clearance Market Package Definition. This market package provides for automated clearance at roadside check facilities. The roadside check facility communicates with the Commercial Vehicle Administration subsystem over wireline to retrieve infrastructure snapshots of critical carrier, vehicle, and driver data to be used to sort passing vehicles. This package allows a good driver/vehicle/carrier to pass roadside facilities at highway speeds using transponders and dedicated short-range communications to the roadside. The roadside check facility may be equipped with AVI, weighing sensors, transponder read/write devices, computer workstation processing hardware, software and databases.

**Figure 910.4.3.2.1, Electronic Clearance Market Package Architecture Flow Diagram**

Weigh In Motion Market Package Definition. This market package provides for high speed weigh-in-motion with or without AVI attachment. Primarily this market package provides the roadside with additional equipment, either fixed or removable. If the equipment is fixed, then it is thought to be an addition to the electronic clearance and would work in conjunction with the AVI and AVC equipment in place.

**Figure 910.4.3.2.1, Weigh-In Motion Market Package Architecture Flow Diagram**

Commercial Vehicle Administrative Process Definition. This market package provides for electronic application, processing, fee collection, issuance, and distribution of CVO credential and tax filing. Through this process, carriers, drivers, and vehicles may be enrolled in the electronic clearance program provided by a separate market package which allows commercial vehicles to be screened at mainline speeds at commercial vehicle check points. Through this enrollment process, current profile databases are maintained in the Commercial Vehicle Administration Subsystem and snapshots of this database are made available to the commercial vehicle check facilities at the roadside to support the electronic clearance process.

**Figure 910.4.3.2.1, Commercial Vehicle Administration Market Package Architecture Flow Diagram**

910.4.3.2.2 Incident Management

I-64 Project

Evaluation of Arterial Service Patrol Programs

}

The Incident Management ITS Program is composed of the following four market packages and associated deployment areas/settings:

Incident Management, Urban, Semi-Urban, Corridor, Statewide
Emergency Response, Urban
Emergency Routing, Urban
Roadway Service Patrols, Urban

The Roadway Service Patrol Market Package was not part of the initial Market Package Assessment since it has only recently been released as part of Version 4.0 of the National ITS Architecture. However, since existing, and very successful, Emergency Response Patrols operate in the Kansas City and St. Louis areas, the new market package has been added to the Incident Management Program Area. During the next iteration of using the Prioritization Tool, it is extremely likely the Roadway Service Patrol market package will score very high. For reference purposes, definitions of each market package are provided below:

Incident Management Market Package Definition. This market package manages both predicted and unexpected incidents so that the impact to the transportation network and traveler safety is minimized. Requisite incident detection capabilities are included in the freeway control market package and through the regional coordination with other traffic management and emergency management centers, weather service entities, and event promoters supported by this market package. Information from these diverse sources are collected and correlated by this market package to detect and verify incidents and implement an appropriate response. This market package provides Traffic Management Subsystem equipment that supports traffic operations personnel in developing an appropriate response in coordination with emergency management and other incident response personnel to confirmed incidents. The response may include traffic control strategy modifications and presentation of information to affected travelers using the Traffic Information Dissemination market package. The same equipment assists the operator by monitoring incident status as the response unfolds. The coordination with emergency management might be through a CAD system or through other communication with emergency field personnel. The coordination can also extend to tow trucks and other field service personnel.

**Incident Management Market Package Architecture Flow Diagram**

Emergency Response Market Package Definition. This market package provides the computer-aided dispatch systems, emergency vehicle equipment, and wireless communications that enable safe and rapid deployment of appropriate resources to an emergency. Coordination between Emergency Management Subsystems supports emergency notification and coordinated response between agencies. Existing wide area wireless communications would be utilized between the Emergency Management Subsystem and an Emergency Vehicle to enable an incident command system to be established and supported at the emergency location. The Emergency Management Subsystem would include hardware and software for tracking the emergency vehicles. Public safety, traffic management and many other allied agencies may each participate in the coordinated response managed by this package.

**Emergency Response Market Package Architecture Flow Diagram**

Emergency Routing Market Package Definition. This market package supports dynamic routing of emergency vehicles and coordination with the Traffic Management Subsystem for special priority on the selected route(s). The Information Service Provider Subsystem supports routing for the emergency fleet based on real-time traffic conditions and the emergency routes assigned to other responding vehicles. In this market package, the Information Service Provider Subsystem would typically be integrated with the Emergency Management Subsystem in a public safety communications center. The Emergency Vehicle would also optionally be equipped with dedicated short-range communications for local signal preemption.

**Emergency Routing Market Package Architecture Flow Diagram**

Roadway Service Patrol Market Package Definition. This market package supports roadway service patrol vehicles that monitor roads that typically have incidents, offering rapid response to minor incidents (flat tire, accidents, out of gas) and support for major incidents to minimize disruption to the traffic stream. If problems are detected, the roadway service patrol vehicles will provide assistance to the motorist (e.g., push a vehicle to the shoulder or median).

**Roadway Service Patrol Market Package Architecture Flow Diagram**

910.4.3.2.3 Traffic Control and Monitoring

The Traffic Control and Monitoring ITS Program is composed of the following three market packages and associated deployment areas/settings:

Freeway Control, Urban
Surface Street Control, Urban, Semi-Urban
Network Surveillance, Urban, Semi-Urban

For reference purposes, definitions of each market package are provided below:

Freeway Control Market Package Definition. This market package provides the communications and roadside equipment to support ramp control, lane controls, and interchange control for freeways. Coordination and integration of ramp meters are included as part of this market package. This package is consistent with typical urban traffic freeway control systems. This package incorporates the instrumentation included in the Network Surveillance Market Package to support freeway monitoring and adaptive strategies as an option. This market package also includes the capability to utilize surveillance information for detection of incidents. Typically, the processing would be performed at a traffic management center; however, developments might allow for point detection with roadway equipment. For example, a CCTV might include the capability to detect an incident based upon image changes. Additionally, this market package allows general advisory and traffic control information to be provided to the driver while en route.

**Freeway Control Market Package Architecture Flow Diagram**

Surface Street Control Market Package Definition. This market package provides the central control and monitoring equipment, communication links, and the signal control equipment that support local surface street control and/or arterial traffic management. A range of traffic signal control systems are represented by this market package ranging from static pre-timed control systems to fully traffic responsive systems that dynamically adjust control plans and strategies based on current traffic conditions and priority requests. Additionally, general advisory and traffic control information can be provided to the driver while en route. This market package is generally an intrajurisdictional package that typically does not rely on real-time communications between separate control systems to achieve area-wide traffic signal coordination. Systems that achieve coordination across jurisdictions by using a common time base or other strategies that do not require real time coordination would be represented by this package. This market package is consistent with typical urban traffic signal control systems.

**Surface Street Control Market Package Architecture Flow Diagram**

Network Surveillance Market Package Definition. This Market Package includes traffic detectors, environmental sensors, other surveillance equipment, the supporting field equipment, and wireline communications to transmit the collected data back to the Traffic Management Subsystem. The derived data can be used locally such as when traffic detectors are connected directly to a signal control system or remotely (e.g., when a CCTV system sends data back to the Traffic Management Subsystem). The data generated by this Market Package enables traffic managers to monitor traffic and road conditions, identify and verify incidents, detect faults in indicator operations, and collect census data for traffic strategy development and long range planning. The collected data can also be analyzed and made available to users and the Information Service Provider Subsystem.

**Network Surveillance Market Package Architecture Flow Diagram**

910.4.3.2.4 Traveler and Weather Information

The Traffic Control and Monitoring ITS Program is composed of the following three market packages and associated deployment areas/settings:

Broadcast Traveler Information, Urban, Semi-Urban

Traffic Information Dissemination, Semi-Urban

Road Weather Information Systems, Urban, Semi-Urban, Corridor, Statewide

For reference purposes, definitions of each market package are provided below:

Broadcast Traveler Information Market Package Definition. This market package provides the user with a basic set of ATIS services; its objective is early acceptance. It involves the collection of traffic conditions, advisories, general public transportation, toll and parking information, incident information, air quality and weather information, and the near real time dissemination of this information over a wide area through existing infrastructures and low cost user equipment (e.g., FM subcarrier, cellular data broadcast). Different from the market package ATMS6, Traffic Information Dissemination, that provides the more basic HAR and DMS information capabilities, ATIS1 provides the more sophisticated digital broadcast service. Successful deployment of this market package relies on availability of real-time traveler information from roadway instrumentation, probe vehicles or other sources.

**Broadcast Traveler Information Market Package Architecture Flow Diagram**

Traffic Information Dissemination Market Package Definition. This market package allows traffic information to be disseminated to drivers and vehicles using roadway equipment such as dynamic message signs or highway advisory radio. This package provides a tool that can be used to notify drivers of incidents; careful placement of the roadway equipment provides the information at points in the network where the drivers have recourse and can tailor their routes to account for the new information. This package also covers the equipment and interfaces that provide traffic information from a traffic management center to the media (for instance via a direct tie-in between a traffic management center and radio or television station computer systems), 511 systems, transit management center, emergency management center and information service provider.

**Traffic Information Dissemination Market Package Architecture Flow Diagram**

Road Weather Information System, Market Package Definition. This market package monitors current and forecast road and weather conditions using a combination of weather service information and data collected from environmental sensors deployed on and about the roadway. The collected road weather information is monitored and analyzed to detect and forecast environmental hazards such as icy road conditions, dense fog, and approaching severe weather fronts. This information can be used to more effectively deploy road maintenance resources, issue general traveler advisories, and support location specific warnings to drivers using the Traffic Information Dissemination Market Package.

**Road Weather Information System Market Package Architecture Flow Diagram**

910.4.3.2.5 Transit Management

The Traffic Control and Monitoring ITS Program is composed of the following two market packages and associated deployment areas/settings:

Transit Vehicle Tracking, Urban, Semi-Urban and Rural
Transit Fixed Route Operations, Urban

For reference purposes, definitions of each market package are provided below:

Transit Vehicle Tracking Market Package Definition. This market package provides for an Automated Vehicle Location System to track the transit vehicle’s real time schedule adherence and updates the transit system’s schedule in real-time. Vehicle position may be determined either by the vehicle (e.g., through GPS) and relayed to the infrastructure or may be determined directly by the communications infrastructure. A two-way wireless communication link with the Transit Management Subsystem is used for relaying vehicle position and control measures. Fixed route transit systems may also employ beacons along the route to enable position determination and facilitate communications with each vehicle at fixed intervals. The Transit Management Subsystem processes this information, updates the transit schedule and makes real-time schedule information available to the Information Service Provider Subsystem via a wireline link.

**Transit Vehicle Tracking Market Package Architecture Flow Diagram**

Transit Fixed Route Operations Market Package Definition. This market package performs automatic driver assignment and monitoring, as well as vehicle routing and scheduling for fixed-route services. This service uses the existing AVL database as a source for current schedule performance data, and is implemented through data processing and information display at the transit management subsystem. This data is exchanged using the existing wireline link to the information service provider where it is integrated with that from other transportation modes (e.g. rail, ferry, air) to provide the public with integrated and personalized dynamic schedules.

**Transit Fixed Route Operations Market Package Architecture Flow Diagram**

910.4.4 Operational Concept

The Missouri Statewide ITS concept of operations provides a general outline of roles and responsibilities for agencies that will be significantly impacted by the core ITS Program Areas. The information provided in this section should be used to refine existing and future agreements between stakeholder agencies. For each core ITS Program area, a roles and responsibilities matrix and physical architecture interconnect diagrams have been developed.

910.4.4.1 Program Area Roles and Responsibilities

A clear understanding of roles and responsibilities is critical to any transportation related program or project particularly when technology is involved. The following matrices attempt to clarify agency roles and responsibilities associated with the core ITS Program Areas. Roles and responsibilities have generally been categorized into three areas: costs, operations and maintenance.

910.4.4.1.1 Commercial Vehicle Operations (CVO) Roles and Responsibilities

The chart below shows the recommended Commercial Vehicle Operations Roles and Responsibilities Matrix. The matrix was developed based on the Missouri CVISN Business and Program Plan.

910.4.4.1.2 Incident Management Roles and Responsibilities

The chart below shows the recommended Incident Management Roles and Responsibilities Matrix. The matrix was developed based on the Baseline Assessment Report.

910.4.4.1.3 Traffic Control and Monitoring Roles and Responsibilities

The chart below shows the Traffic Control and Monitoring Roles and Responsibilities Matrix. The matrix was developed based on the Baseline Assessment Report.

910.4.4.1.4 Traveler and Weather Information Roles and Responsibilities

The chart below shows the recommended Traveler and Weather Information Roles and Responsibilities Matrix. The matrix was developed based on the Baseline Assessment Report and regional architectures for Kansas City and St. Louis.

910.4.4.1.5 Transit Management Roles and Responsibilities

The chart below shows the recommended Transit Management Roles and Responsibilities Matrix. The matrix was developed based on the Baseline Assessment Report and regional architectures of Kansas City and St. Louis.

910.4.4.2 Physical Architecture Subsystem Interconnect Diagrams

Understanding the “real world” relationship between agencies can be depicted using physical architecture interconnect diagrams. The interconnect diagram serves as a good screening tool by providing a block drawing with undefined connectors. Planners and engineers can easily determine what agencies are, or should be, connected to one another without drilling into too much architecture flow level detail. The following sections provide subsystem interconnect diagrams associated with each core ITS Program Areas.

**Fig. 910.4.4.2.1, Commercial Vehicle Operations (CVO) Interconnect**

**Fig. 910.4.4.2.2, Incident Management Interconnect**

**Fig. 910.4.4.2.3, Traffic Control and Monitoring Interconnect**

**Fig. 910.4.4.2.4, Traveler and Weather Information Interconnect**

**Fig. 910.4.4.2.5, Transit Management Interconnect**

910.4.5 ITS Standards

This article introduces the National Transportation Communications ITS Protocol (NTCIP) standards and addresses the benefits of implementing NTCIP and other standards. Each core ITS Program Area has been mapped to appropriate NTCIP standards to provide a guide to standards that must be considered when planning for and deploying future projects.

NTCIP is a family of standards that provides both the rules for communicating (called protocols) and the vocabulary (called objects) necessary to allow electronic traffic control equipment from different manufacturers to operate with each other as a system. NTCIP is the first set of standards for the transportation industry that allows traffic control systems to be built using a "mix and match" approach with equipment from different manufacturers. Therefore, NTCIP standards reduce the need for reliance on specific equipment vendors and customized one-of-a-kind software. To assure both manufacturer and user community support, NTCIP is jointly developed by NEMA, AASHTO and ITE.

An ITS standard undergoes several steps prior to formal adoption. The process typically can take one to five years. Figure 910.4.5 illustrates the Life Cycle of ITS Standards which are generally broken into four categories including Standard Development, Standard Testing, ITS Product Development and Standard Adoption.

Fig. 910.4.5, Life Cycle of ITS Standard Development⁶

SDO develops, approves and publishes standard		Standard is tested		Standard matures and ITS products are developed		Adoption of standard through U.S. DOT rulemaking
Standards development organizations (SDOs) coordinate the development of standards. 1) During development, an SDO committee writes and documents the technical aspects of standards. 2) Standards then go through a balloting process where committee or working group members review the technical merits of the standards. A standard may or may not pass balloting. 3) Standards that have passed all necessary ballots are approved. At this stage, the standard can be used but is not yet published. 4) Approved standards are published by the SDO and are available for purchase.		Testing measures the operation, correctness and completeness of a standard under realistic transportation operating conditions. It also measures the degree of interoperability (the capacity of a device to communicate with different types of ITS devices) among standards as well as provides information about the performance of a standard to the ITS community.		As standards mature, competition develops among vendors to provide a range of equipment with differing levels of functionality. This gives transportation managers greater flexibility in choosing products that best suit their particular project requirements. Standardized components lead to interoperability and interchangeability (the capacity to substitute one manufacturer's device for another). ITS devices, based on open standards, lead to cost savings, as well as to easier and more efficient systems maintenance and operations.		Not all ITS standards reach this stage. The U.S. DOT will only consider adopting an ITS standard through rulemaking if the standard meets, at a minimum, certain established criteria. These criteria are defined in the Final Rule/Policy on the National ITS Architecture and ITS Standards and are intended to produce technically and commercially viable ITS standards and equipment.

⁶ “Life Cycle of ITS Standards”, Publication No. FHWA-OP-01-047, May 2001

910.4.5.1 USDOT Position on Implementing ITS Standards

The Transportation Equity Act for the 21st Century (TEA-21) required the United States Department of Transportation (USDOT) to identify a set of “Critical ITS Standards” to focus USDOT’s ITS efforts. USDOT developed a list of thirteen critical standards, which includes NTCIP. The Federal Highway Administration (FHWA) Rule on ITS Architecture and Standards requires that agencies receiving federal funds for ITS use USDOT-adopted standards. As of 2002, USDOT had not adopted any standards and agencies were not explicitly required to use ITS standards. A formal rule-making process will be conducted when USDOT intends to implement ITS Standards. It is likely that USDOT will adopt ITS standards from time to time over the next decade.

910.4.5.2 Benefits of ITS Standards

The benefits of any ITS standards-based implementation are very difficult to quantify, particularly for a single ITS standard. However, the adoption of ITS standards is an essential part of implementing statewide and/or regional ITS architectures. Standards are the glue that bonds the various parts of the identified architecture together to enable automated data exchanges. Many of the benefits will be found in the long-term operational and maintenance aspects of system deployments. These benefits are still being quantified, as the standards are still very new or still being developed. ITS standards help to achieve the overall goals of an ITS program.

One of the greatest benefits of acquiring and installing NTCIP-based systems is that they enable systems to “talk” to each other. This possibility of communications is achieved on both levels: center-to-field as well as center-to-center links. Without common ITS standards, proprietary protocols need to be developed and used by vendors and system integrators. These proprietary protocols are mostly application-specific and are developed to be very efficient. However commonality and/or flexibility to address other vendor’s equipment needs were neither considered nor desired. NTCIP standards are an enabling building block for helping to solve the historical challenges involved with implementation, operations, and maintenance. The benefits of these standards include:

Reduction or even elimination of dependency on single vendor’s system components – This does not mean that an agency cannot retain a preferred vendor, but opens the door to competition and reduces price.

Simplified system integration – Common functionalities among device types allow one central software to control and monitor devices from different vendors, using the same communications and graphical user interface (GUI) software package.

Capability to seamlessly transition multi-jurisdictional systems – Common functionalities allow neighboring agencies to monitor and even control (assuming appropriate authorization) each other’s field equipment.

Reduction in infrastructure investments – The ITS standards were designed to allow compatibility of different device types. The commonality of the supporting communications protocol standards allows several end-applications, such as signal controllers, DMS, and Highway Advisory Radio (HAR), to use the same communications infrastructure. In the past, each proprietary protocol required a separate communications line.

Support ease of expandability – The Standards were also designed to be flexible, allowing easy additions to the standards in terms of adding functionalities. Both the standards development organizations, and vendors can add these functionalities.

Reduction in system engineering cost – Due to the ease of expandability and common interfaces to common functionalities, integration and system engineering costs will be reduced.

Expansion of knowledge base – The promotion and growing number of ITS standards-based implementations increase the number of people in public agencies and private companies that have gained the knowledge to guide and support ITS standards-based systems.

Reduced maintenance training costs – Staff does not need continual training in various communications standards that are supported by a variety of devices.

Less obsolescence – Once an interface to a particular device type (e.g., DMS) has been developed which addresses all of the user’s functional requirements, this interface software can be used for any DMS from any vendor (assuming all DMSs implement the same functional requirements using the same data elements as defined by the procuring agency).

910.4.5.3 Program Area Standards

Looking at the ITS Standards as a foundation for building the systems identified in the Missouri Statewide Architecture, Table 910.4.5.3 highlights applicable standards associated with the core ITS Program Areas and indicates status as of 2002.

Status is defined in Table 910.4.5.3 as:

Published (P) - Standards available for purchase

Approved (A) - Standards passing all necessary ballots and approved by a standards development organization but not yet published.

In Balloting (IB) - Standards being voted upon by a committee or working group or are undergoing other SDO procedures

Under Development (UD) - Standards being written but not yet ready for a formal ballot

Table 910.4.5.3 Program Area Standards


SDO	Standard Number	Standard Name	Core ITS Program Area					Status as of 2002
SDO	Standard Number	Standard Name	Commercial Vehicle Operations	Incident Management	Traffic Control and Monitoring	Traveler and Weather Information Standards	Transit Management	Status as of 2002
ANSI	TS285	Commercial Vehicle Safety and Credentials Information Exchange	Y	-	-	-	-	P
ANSI	TS286	Commercial Vehicle Credential	Y	-	-	-	-	P
ASTM	-	DSRC at 5.9 GHz	Y	-	-	-	-	P
SAE	J1764	ISP – Vehicle Location Referencing Standard	-	-	-	Y	-	P
SAE	J2353	Advanced Traveler Information System (ATIS) Data Dictionary	Y	Y	Y	Y	Y	P
SAE	J2354	Advanced Traveler Information System (ATIS) Message Set	Y	Y	Y	Y	Y	P
SAE	J2369	Standards for ATIS Message Sets Delivered Over Bandwidth Restricted Media	-	-	-	Y	-	P
SAE	J2529	Rules for Standardizing Street Names and Route IDs	Y	Y	Y	Y	Y	P
SAE	J2540	Messages for Handling Strings and Look-up Tables in ATIS Standards	Y	Y	Y	Y	Y	P
ITE	ITE-9603-3	Advanced Transportation Controller (ATC)	-	Y	Y	Y	-	UD
ITE	ITE-9603-2	ATC Cabinet	-	Y	Y	Y	-	UD
ITE	ITE-9603-1	ATC Application Program Interface (API)	-	Y	Y	Y	-	UD
EIA/CEA	EIA-795	Subcarrier Traffic Information (STIC) System	-	-	-	Y	-	P
EIA/CEA	EIA-794	Data Radio Channel (DARC) System	-	-	-	Y	-	P
ASTM	PS105-99	Standard Specification for DSRC – Data Link Layer	Y	Y	-	-	-	P
ASTM	PS111-98	Standard Specification for DSRC – Physical Layer 902-928 MHz	Y	Y	-	-	-	P
ITE	TM 1.03	Standard for Functional Level Traffic Management Data Dictionary (TMDD)	Y	Y	Y	-	Y	IB
ITE	TM 2.01	Message Set for External TMC Communication (MS/ETMCC)	Y	Y	Y	-	Y	IB
AASHTO	TS 3.HAR	NTCIP – Object Definitions for Highway Advisory Radio (HAR)	-	Y	-	Y	-	UD
AASHTO	1101	NTCIP – Simple Transportation Management Framework (STMF)	-	Y	Y	Y	-	P
AASHTO	1102	NTCIP – Octet Encoding Rules	Y	Y	-	Y	Y	IB
AASHTO	1103	NTCIP – Simple Transportation Management (STMP)	-	Y	Y	Y	-	UD
AASHTO	1104	NTCIP – CORBA Naming Convention	Y	Y	Y	Y	Y	P
AASHTO	1105	NTCIP – CORBA Security Service	Y	Y	Y	Y	Y	P
AASHTO	1106	NTCIP – Near-Real Time Data Service	Y	Y	Y	Y	Y	P
AASHTO	1201	NTCIP – Global Object Definitions	Y	Y	Y	Y	Y	P
AASHTO	1202	NTCIP – Object Definitions for Actuated Traffic Signal Controller Units	-	Y	-	-	-	P
AASHTO	1203	NTCIP – Object Definitions for Dynamic Message Signs	-	-	-	Y	-	P
AASHTO	1204	NTCIP – Object Definitions for Environmental Sensor Stations	-	-	-	Y	-	P
AASHTO	1205	NTCIP – Object Definitions for Closed Circuit Television Camera Control	-	Y	Y	-	-	IB
AASHTO	1206	NTCIP – Data Collection and Monitoring Devices	-	-	Y	-	-	UD
AASHTO	1207	NTCIP – Object Definitions for Ramp Meter Control	-	-	Y	-	-	A
AASHTO	1208	NTCIP – Object Definitions for Video Switches	-	Y	Y	-	-	UD
AASHTO	1209	NTCIP – Object Definitions for Transportation Sensor Systems	-	Y	Y	-	-	UD
AASHTO	1210	NTCIP – Objects for Signal System Master	-	Y	Y	-	-	IB
AASHTO	1211	NTCIP – Objects for Signal Control Priority	-	Y	-	-	-	UD
AASHTO	1301	NTCIP – Message Sets for Weather Reports	-	Y	-	-	Y	UD
ITE	1401	TCIP – Common Public Transportation (CPT) Objects	-	-	-	-	Y	P
ITE	1402	TCIP – Incident Management (IM) Objects	-	Y	-	-	Y	P
ITE	1403	TCIP – Passenger Information (PI) Objects	-	-	-	-	Y	P
ITE	1404	TCIP – Scheduling/Runcutting (SCH) Objects	-	-	-	-	Y	P
ITE	1405	TCIP – Spatial Representation (SP) Objects	-	-	-	-	Y	P
ITE	1406	TCIP – Onboard (OB) Objects	-	-	-	-	Y	A
ITE	1407	TCIP – Control Center (CC) Objects	-	-	-	-	Y	A
IEEE	1455	Message Sets for DSRC ETTM and CVO	Y	-	-	-	-	P
IEEE	1521.1	Standard for Traffic Incident Management Message Sets for use by EMCs	-	Y	-	-	-	UD
IEEE	1521.2	Standard for Public Safety IMMS for use by EMCs	-	Y	-	-	-	UD
IEEE	1521.3	Standard for Hazardous Material IMMS for use by EMCs	-	Y	-	-	-	UD
IEEE	1512.a	Standard for Emergency Management Data Dictionary	-	Y	-	Y	-	UD
IEEE	1512-2000	Standard for Common Incident Management Message Sets (IMMS) for use by EMCs	-	Y	-	Y	-	P
IEEE	1556	Security/Privacy of Vehicle/RS Communications including Smart Card Communications	Y	Y	-	-	-	UD
AASHTO	2001	NTCIP – Class B Profile	-	-	Y	-	-	P
AASHTO	2101	NTCIP – Point-to-Multipoint Protocol/RS232 Subnetwork Profile	-	Y	Y	Y	-	A
AASHTO	2102	NTCIP – Subnet Profile for PMPP over FSK modems	-	-	Y	Y	Y	A
AASHTO	2103	NTCIP – Subnetwork Profile for Point-to-Point using RS232	-	Y	Y	Y	-	UD
AASHTO	2104	NTCIP – Subnetwork Profile for Ethernet	Y	Y	Y	Y	Y	IB
AASHTO	2201	NTCIP – Transportation Transport Profile	-	Y	Y	Y	-	A
AASHTO	2202	NTCIP – Internet (TCP/IP and UDP/IP) Transport Profiles	Y	Y	Y	Y	Y	A
AASHTO	2301	NTCIP – STMF Application Profile	-	Y	Y	Y	-	A
AASHTO	2302	NTCIP – Trivial File Transfer Protocol - Application Profile	-	Y	Y	Y	-	A
AASHTO	2303	NTCIP – File Transfer Protocol - Application Profile	Y	Y	Y	Y	Y	A
AASHTO	2304	NTCIP – Application Profile – Data Exchange (DATEX)	Y	Y	Y	Y	Y	IB
AASHTO	2305	NTCIP – Application Profile - CORBA	Y	Y	Y	Y	Y	UD
AASHTO	2501	NTCIP – Information Profile for DATEX	Y	Y	Y	Y	Y	A
AASHTO	2502	NTCIP – Information Profile for DATEX	Y	Y	Y	Y	Y	A

910.4.6 Sequence of Statewide ITS Program Areas

Figure 910.4.6 shows a proposed schedule of how the ITS Program Areas should be implemented over a 15-year horizon. The Incident Management Program and Traffic Control and Monitoring Areas have the longest implementation period to take into considerations anticipated advancements in communications and information technology, the complexity of inter-agency coordination, and the extensive size of the Missouri highway system.

**Fig. 910.4.6, Proposed Sequence of Statewide ITS Program Areas**

910.4.7 Acronym List and Websites


AASHTO	American Association of State Highway Transportation Agencies
ANSI	American National Standards Institute
ATC	Advanced Transportation Controller
ATIS	Advanced Traveler Information System
AVI	Automatic Vehicle Identification
C2C	Task C2C
CAD	Computer-Aided Dispatch
CEA	Consumer Electronics Association
CC	Control Center
CCTV	Closed Circuit Television Cameras
CDPD	Cellular Digital Packet Data
CORBA	Common Object Request Broker Architecture
CPT	Common Public Transportation
CVISN	Commercial Vehicle Information Systems and Networks
DATEX	Data Exchange
DATEX ASN	Data Exchange ASN 1
DDE	Data Dictionary Entry
DMS	Dynamic Message Sign
DSRC	Dedicated Short Range Communications
DTI	Digital Teleport, Incorporated
ESS	Environmental Sensor Stations
EIA	Electronic Industries Alliance
FC	Fare Collection
FCC	Federal Communications Commission
FHWA	Federal Highway Administration
FSK	Frequency Shift Keying
FTP	File Transfer Protocol
HAR	Highway Advisory Radio
IEEE	Institute of Electrical and Electronics Engineers
IM	Incident Management
ISO	International Standards Organization
ITE	Institute of Transportation Engineers
ITS	Intelligent Transportation Systems
MOU	Memorandum of Understanding
MSHP	Missouri State Highway Patrol
NAN	Assigned Numbers
NEMA	National Electrical Manufacturers Association
NTCIP	National Transportation Communications for ITS Protocol
OB	On-Board
PI	Passenger Information
PMPP	Point-to-Multipoint Protocol
PPP	Point-to-Point Protocol
Pspec	Process Specification
RF	Radio Frequency
RS232	Recommended Standard 232
RWIS	Road Weather Information System
SAE	Society of Automotive Engineers
SCH	Scheduling / Runcutting
SDO	Standards Development Organization
SP	Spatial Representation
STMF	Simple Transportation Management Framework
TCIP	Transit Communication Interface Profiles
TFTP	Trivial File Transfer Protocol
TMC	Transportation Management Center
TMDD	Traffic Management Data Dictionary
TMS	Transportation Management Systems
VDOT	Virginia Department of Transportation
VMS	Variable Message Sign
WAN	Wide Area Network