Prepared by:
Institute of Transportation Engineers
Washington, DC

Prepared for:
Federal Highway Administration
US Department of Transportation
Washington, DC

March 8, 1996

Table of Contents

STRATEGIC PLAN
FOR THE DEVELOPMENT OF AN
ATMS DATA DICTIONARY
Version 1.0
March 8, 1996

1.0 BACKGROUND

The Intelligent Transportation Systems (ITS) program has now evolved to the stage where emphasis is being placed on the development of national standards. These are seen as critical for enhanced system interoperability and to accelerate general market development. As part of this growing standards development activity, the Federal Highway Administration (FHWA) recently entered into a set of cooperative agreements with five Standards Development Organizations (SDO's) . These agreements are intended "to foster the development of ITS standards by augmenting the resources available to existing standard setting bodies and activities." The scope of intended standards development areas includes data dictionaries for specific ITS user areas. These five SDO's are now defining their specific standards development areas of responsibilities and are expected to begin their actual cooperatively funded standards development activities in the near future.

The development of a standardized data dictionary for Advanced Traffic Management Systems (ATMS) is a high priority for the ITS program. Such a dictionary is essential to the ability to efficiently and effectively exchange messages between individual traffic management systems as well as between an ATMS and other ITS users and/or suppliers of ATMS related information. The development of a standardized ATMS Data Dictionary (TMDD) is further seen as an important first step in achieving the broader goal of implementing a national architecture which will assist in the deployment of ITS services and functions.

In an August, 1995 ATMS Standards Workshop involving a range of national public and private ATMS stakeholders, FHWA agreed to support the development of a TMDD and to take actions to expedite this activity. One of the immediate actions included an initial task to develop a strategic plan for the TMDD development and to establish a national steering committee. This report is part of this initial task and presents the strategic plan. A previous report dealing with the selection and establishment of the steering committee was provided to FHWA February 9, 1996.

This Strategic Plan provides context and recommendations for the TMDD development. It is intended to assist the Steering Committee to more rapidly begin the actual TMDD

development. Specific activities discussed as part of this Strategic Plan include:

• A framework of goals to guide the TMDD development
• Review of existing examples of TMDD's
• Interfaces and relationships with major ITS user areas and national standards activities
• A listing and discussion of a range of policy considerations
• TMDD development approach including recommendations on partitioning and prioritizing the scope of work
• Roles of the Steering Committee and the supporting SDO(s).
• Schedule and resource considerations
• Suggested specific next steps

At the center of the overall TMDD development strategy is the focus on the Steering Committee's essential role as the overall strategist and decisionmaker in this effort. Over and above the specific message set definition activities, they will have a continuing set of key strategic decisions to make throughout the TMDD development. These include initial decisions such as selecting the actual form of the TMDD plus selecting the strategy for partitioning the overall ATMS message sets and prioritizing their sequence of TMDD development. Thus, this Strategic Plan is intended to provide an assessment of these and other TMDD related considerations to assist the Steering Committee in its decisionmaking role.

Table of Contents

2.0 DATA DICTIONARIES - GENERAL

One of the most important aspects when designing and implementing systems is the uniform understanding of the terminology being used. A data dictionary provides a unique identification and description of the data elements used in the transmission and communication of messages between computer systems. For each data element there normally is a description, size estimate, and listing and description of its critical attributes. Some dictionaries will include other features such as description of origin, timing requirements, and valid entries for the data element.

Perhaps surprisingly, there is some inconsistency as to the name of an individual data dictionary entry and at what information level it exists. At various times, these entries are referred to as data flows, messages, message sets, tables, data elements, and/or objects. It is commonly understood that a data dictionary holds data elements, but what appears to not be always understood is at what level these elements are being defined. This confusion has been recognized by others and Allan Kirson is preparing an excellent paper defining terminology and hierarchical structure for this area of message exchange. For this report, a data dictionary entry will be called a data element and will normally represent the smallest variable data unit definable. That is, a data element will normally consist at the level in a message where it cannot be further decomposed or subdivided.

As a simple but relevant comparison, a data element in a data dictionary is the equivalent of a word definition in a Webster's dictionary. This comparison to a language dictionary is instructive in many ways. For example, a word may have different meanings when used in different contexts. Each of these are defined in a dictionary. Further, individual words may have a unique definition when used as a word set and this word set must also be uniquely defined. For example, "hash mark" has a meaning different than the individual word definitions of "hash" and "mark".

The ATMS Data Dictionary (TMDD) will identify and define the specific data elements which make up the messages exchanged between an ATMS Traffic Management Center (TMC) and other external systems and subsystems. These may include, but are not limited to other TMC's, traffic control devices, surveillance systems, motorist information systems, and ITS applications such as Advanced Public Transportation Systems (APTS), Advanced Traveler Information Systems (ATIS), Commercial Vehicle Operations (CVO), etc. Referring to Figure 1, some typical examples of this information exchange relationship are depicted for the nine primary components of the Intelligent Transportation Infrastructure (ITI). The TMDD does not necessarily seek to identify data terms used only internally within a proprietary system or its database. Also, it is important to emphasize a data dictionary in itself does not seek to determine a database design, file structure or any method of internal storage in a system.

Data dictionaries are an essential part of designing, operating and maintaining modern computer-based systems as they are an integral feature of database driven systems. However, data dictionaries are not necessarily complex or esoteric documents but rather can be relatively straightforward descriptions of important data terms. For example, a data dictionary for traffic records system was developed in the 1970's as a formal ANSI standard (D20.1) in a process that took six years. Consisting of approximately 200 pages, it's purpose "is to provide a common language for developers and users of State and local traffic records systems." It provides common names, abbreviations, definitions, uses, sources, synonyms, and representation of data elements transmitted and communicated by State and local traffic records systems. For each data element it maintains the information shown in Table 1.

Table 1

Listing of Data Element Description for

Traffic Records Systems - ANSI D20.1

• Name
• Short Name
• Abbreviation
• Definition
• Sources
• Uses
• Type of Data Element (Basic or Composite)
• Type of Representation (Name, Abbreviation, Code, Numeric Value)
• Type of Character(s) (Numeric, Alphanumeric, Alphabetic, Special)
• Length (Fixed or Variable and Number of Characters)
• Synonyms
• Other Characteristics
• Source of Data Representation
• Description of Data Items (Name of Item, Abbreviation, Code, Definition)

The information in Table 1 is an example of the structure of a data dictionary. It again demonstrates that a data dictionary can generally be described as having the following features:

• A definition of the term similar to a glossary.
• A listing of the various attributes or properties of the particular data element.
• A definition of how attributes are coded and the length or size property of the coded data element.

Table of Contents

3.0 PROGRAM GOALS

The program to develop a TMDD has several overall goals and anticipated results which serve to guide and focus this activity as listed in Table 2. Achieving these goals will depend on developing an understanding of the many issues involved and will require that the TMDD process coordinate with and build on the work of several past, as well as current related activities. These goals also serve to scope the TMDD effort and develop an initial sense of the more important aspects of this effort. The specific implications and considerations of this framework of TMDD development goals are the subject of much of the following portions of this strategic plan.

Table 2

GOALS FOR THE DEVELOPMENT OF AN

ATMS DATA DICTIONARY

• Develop a nationally accepted, standardized ATMS Data Dictionary

• Consolidate the various ATMS data elements from other sources including previous and current activities such as National Architecture and NTCIP

• Resolve differences of definition or usage of terms

• Provide a nationally accepted definition of ATMS data elements which will support the development of desired ATMS related standards and protocols.

• Facilitate the efficient and effective interchange of messages and data flows between TMC's and other users/sharers of this information at the local and regional application level

• Facilitate the functional integration of individual systems into overall major corridor traffic management and/or motorist advisory systems

• Support the development and deployment of new ITI systems and technology with greatly enhanced interoperability and interchangeability.

Table of Contents

4.0 EXISTING ATMS DATA DICTIONARIES

TMDD's or their general equivalent have existed in various forms since the early stages of traffic engineering. For example, the current Highway Capacity Manual includes a glossary defining over 160 traffic engineering related terms. (It's interesting to note, however, that the ill-defined term "link" is not included in these definitions). The Traffic Control Systems Handbook contains an even larger set. The AASHTO Transportation Glossary includes sections on Traffic with over 65 terms being defined. From another perspective, documentation for FHWA research on the Integrated Traffic Data System in the 1980's listed over 70 data elements and their units of definition which were common to various traffic simulation models.

Focusing on purer forms of TMDD's finds they exist primarily for specific traffic management systems which have been designed and developed by major traffic systems firms. Specific examples were examined in visits to PB Farradyne, Loral AeroSys and JHK & Associates.

These individual data dictionaries were developed to support the data flow with their system database. They generally are organized in a hierarchy consisting of a set of tables for some function, with the tables made up of individual definitions. In database terminology this structured definition is called a schema. In this structure, one set of tables could, for example, be grouped under "Device Modules" with individual tables prepared for detector stations, ramp control, camera control, etc. To get a sense of size, the PB Farradyne Mist System contains over 130 individual tables with each table containing from as few as two defined attributes to as many as 20. An example of the table for LINK DEF is shown in Figure 2 and is one of the longer tables with 19 entries defining specific attributes. In addition to the exact attribute name and its description (definition), each attribute is described by its data type which is based on a structured format chosen by the system designer.

Examination of the data dictionary or schema for other systems shows a similar structure consisting of tables for specific message sets. For example, the schema for the Loral AeroSys system database also includes a table for LINK but is significantly larger as it contains 32 attributes which are defined. Inspection will show, however, part of the increase is due to the system designers including environmental information in their table. (Figure 3).

This comparison of how similar terms are handled by different system designers provides insight into the specific work that must be performed during the TMDD development. First, a common set of data elements must be identified; second, the specific definition of each data element must be established; and then, third, a table or list of the necessary attributes must be established. This demonstrates that consolidation and coordination of terminology and even system structure will be a considerable part of the TMDD development activity.

Table of Contents

5.0 INTERFACES AND RELATIONSHIPS

The development of the TMDD must deal with a complex set of interfaces and relationships as part of the larger network of ITS data flows and standards development activities. The more significant are discussed in this section.

Table of Contents

5.1 Relationship With National Architecture

The development of the TMDD has a direct relationship with the structure and products of the National Architecture (NA) program which through a top down, highly structured process provided a rigorous systems engineering perspective of ITS. Based on the definition of mission requirements and user service requirements, a "logical architecture" was developed. This included process specifications (P-Specs) describing what data was supplied and required by the various ITS functional entities to perform their user service functions. The logical architecture also included the development of data flow diagrams describing the message interchange between the functional entities and the development of a high level data dictionary for the data elements in these message sets. Thus, this structured approach consisted of the following layers:

• Process Specifications - Describes the functional process in terms of what it does, what data it needs and what data it provides.

• Data Flow Diagram - Graphical view of how processes are related and what data flows between them.

• Data Dictionary - Provides a comprehensive definition of the data elements associated with all information flow and storage required to interconnect the processes.

The ITS data dictionary developed in the NA program is substantial and consists of approximately 2500 entries. A rough estimate is that approximately 600 of these entries are related to ATMS. The NA program also developed a set of Standards Requirements Packages including two directly related to ATMS. These are, Traffic Management Subsystem to Other Centers and Traffic Management Subsystem to Roadside Devices and Emission Monitoring. An example of the format and content of the data dictionary developed by the NA team is shown in Figure 4. Compared to the two data dictionaries shown for the PB Farradyne and Loral AeroSys systems, there are similarities in structure but clear differences in detail. The NA dictionary provides a definition of each entry including both data flows and stores. The components, if any, of a data entry are listed and the size for the primitive dataflow is shown in bytes.

The two industry system data dictionaries, however, generally provide more detail in their description of the attributes for each entry. Also, the industry versions have additional entries which have been added during development to directly support actual implementation of the functional processing. Further, as would be expected, they are much more tied to the physical architecture of a system. In this regard they have provision for such things as the specific geographical location of a device, or its identification number, or the geographical location of a particular data event, etc. These differences in detail and philosophy are basically the outgrowth of the purpose for which each data dictionary has been developed. The NA data dictionary is at the level where it is documenting the definition of data elements which have been identified in the individual process specifications and data flow diagrams for the various user services. As such the NA data dictionary is written more at the functional level and with less bias from the actual physical architecture of the deployed system. Thus, the NA data dictionary has definitions for all data elements and sizes for nearly all the primitives but much less application detail than the industry versions.

The NA data dictionary and those of specific systems should, however, be quite complementary to each other in the upcoming development of a national standardized TMDD. The NA process and data flow structure in general and the two NA ATMS related Standards Requirements Packages in specific have established an overall data flow universe for the ATMS and its interfacing with other ITS user services. They will provide a higher level, structured check on the completeness and consistency of the TMDD. Finally, the NA data dictionary provides specific definitions and insight which will be a valuable input to the final selection and definition of the TMDD data elements.

Table of Contents

5.2 Relationship with NTCIP

The current effort to develop a National Transportation Control/ITS Communications Protocol Standard (NTCIP) has aspects which bear directly on the TMDD. The NTCIP effort also serves as an excellent model for how public and private transportation interests can work together through a national steering committee to achieve mutual goals involving transportation system standards. The NTCIP process, the technical issues it is resolving and the resulting documentation is a technically sophisticated and detailed subject. For this detail, the reader is directed to documentation which can be accessed through the NTCIP site which has been established on the Internet at the following address: http://www-atms.volpe.dot.gov/ntcip/. This source of information was the major reference for the following description of the relationship between NTCIP and TMDD.

The NTCIP development began with the traffic control equipment industry recognizing the need to extend existing standards to include more complex issues of systems inter-operability and communications. This evolved into a national commitment to establish "open" protocol standards that would serve the transportation information network and be adaptable to different communications architectures. To achieve that objective, NTCIP has been developed in conformance with the ISO Open Systems Interconnection Reference Model which is a broadly accepted international set of standards for exchanging information between computer based systems.

The relationship between the NTCIP communication protocol and the TMDD can be generally portrayed as shown in Figure 5. In this simplified drawing, the NTCIP is that set of standards and protocols which apply to the seven layers of the OSI Model and their respective interfaces. Thus, information that needs to be interchanged between systems is interfaced into the communication network through the top "Application" layer. Stepping downward through the seven layers, the information is formatted, packaged, and assembled for communication in accordance with the specific NTCIP standards specified at each layer. Following transmission through the communication n medium (wire, RF, etc.) the information is reverse processed through the receiving OSI seven layer stack and reformatted into the original information which is provided to the receiving system.

The TMDD is the standardized definition of the data elements associated with the message sets which have meaning and utility to the actual using system, as in this case an ATMS. Thus, the TMDD provides the fundamental definition of information exchanged at the Application Layer. At first, it might be assumed that this definition of the actual information would be independent of its communication processing and transmission. However, while the NTCIP committee believed that the content of the end-application messages had to be independent of the communications protocol, it also believed a standardized method for structuring , representing, encoding and decoding data was needed. This led to the establishment of the Simple Transportation Management Framework (STMF) feature of NTCIP. The STMF incorporates a structure based on a standardized procedure for structuring message formats of various communications protocols known as Abstract Syntax Notation One (ASN.1)29. Basically, it defines data terms which it calls "Objects" in five fields as follows:

Object name - A textual name and an identifier for the object type.

Syntax - The abstract syntax of the object, i.e. how it is built.

Definition - A textual description of the meaning of the object type.

Access - The object can read-only, read-write, write-only, or not accessible.

Status - Support is either mandatory, optional or obsolete.

To facilitate open communications under NTCIP, sets of objects for various traffic management functions have been uniquely identified. The NTCIP procedure also calls for the registration and maintenance of these objects by an SDO. At present, the NTCIP committee has prepared Object Definitions for Actuated Traffic Signal Controllers and Variable Message Signs. Examples of some of the object types defined for traffic control and coordination functions include:

Current Time

Pattern

Sync Command

Special Functions

Local Status

Detector Data

The conclusion when examining the products of the NTCIP activity is that there is clearly an overlap of the TMDD and the NTCIP at the NTCIP Object Definition level. This is the primary reason that it was believed essential that the TMDD Steering Committee include individuals who are also members of the NTCIP Steering Committee. This will assure that the results of the NTCIP development process are incorporated where appropriate into the TMDD. It should also assure that the TMDD is developed to be compatible with the data structure interface established by the NTCIP.

Table of Contents

5.3 Relationship With Existing ATMS Data Dictionaries

Section 4 of this report previously described some of the existing data dictionaries of proprietary, industry developed traffic management systems. The TMDD will need to be cognizant of not only these but other existing dictionaries, protocols and glossaries which relate to it. These range from these dictionaries developed by proprietary systems to the national architecture document, and other standards or technical guideline type documents which have a substantial bearing on the TMDD such as was described in the previous NTCIP discussion. To illustrate this, an examination of a particular data element (or table) was made using the relevant data dictionaries which were reviewed as part of this initial task. The variable message sign (VMS) function was selected for this illustration as most of these data dictionaries included some terms for this function. Figures 6 through 10 are reprints from five of these existing dictionaries including the NA, PB Farradyne, Loral AeroSys, Atlanta Regional ATMS and the NTCIP. A comparison will reveal that not only is the specific format different between all the examples; but, the actual entry (object/table/etc.) is different. That is, the set of terms or data elements which are defined for the VMS application are not consistent between the various examples.

This example is not intended to suggest that one approach is correct and the others incorrect; but, rather to provide insight into one major aspect of the coordination and consolidation involved in the development of the TMDD.

Table of Contents

5.4 Relationship To Other User Services and ITS Functions

The scope of the TMDD development includes not only the specific information used within an ATMS, but the information that must be interchanged with other ITS user services. Thus, in addition to the user service bundle Travel and Transportation Management, these include user services associated with the ITS areas of Travel Demand Management, Public Transportation Operations, Commercial Vehicle Operations, Emergency Management, and, eventually, Advanced Vehicle Control and Safety Systems.

Some of these ITS applications either have and/or will soon be developing their own data dictionaries. For example, the SAE Navigation Working Group has recently developed a draft message set for in-vehicle navigation systems. This draft contains several messages which would presumably interface with ATMS including such examples as dynamic link times, vehicle probe reports, advisory messages (traffic, safety, weather), regional systems status reports, etc. Similarly, the APTS community has developed a data dictionary for its needs which also contains several message areas which interface with ATMS.

From the overall ITS perspective, a primary objective of the NA was to identify and describe the multitude of ITS subsystem interfaces. Products of the National Architecture program will soon include data dictionary level guidance for eleven areas. This information is contained in the following eleven standards requirements packages nearing completion by the Architecture Development Team.

1. Dedicated Short Range Communications (DSRC)
2. Digital Map Data Exchange and Location Referencing Formats
3. Information Service Provider Wireless Interfaces
4. Inter-Center Data Exchange for Commercial Vehicle Operations
5. Personal, Transit, and HAZMAT MAYDAYS
6. Traffic Management Subsystem to Other Centers (except EMS)
7. Traffic Management Subsystem to Roadside Devices and Emissions Monitoring
8. Signal Priority for Transit and Emergency Vehicles
9. Emergency Management Subsystem to Other Centers
10. Information Service Provider Subsystem to Other Centers (except EMS and TMS)
11. Transit Management Subsystem to Transit Vehicles and Transit Stops

A complete TMDD is expected to have data elements which will interface with essentially all the above areas. The following are among the more obvious:

• The Information System Providers (ISP's) will have a major information interface with ATMS. The ISP's will receive ATMS related traffic condition information and after formatting and packaging will provide it to their customers for a range of different market applications. Similarly, the ISP's may also provide certain types of traffic surveillance and status information to the ATMS.

• Directly related to ITS communications is TMDD relevant work in vehicle-roadside communications now known as Dedicated Short Range Communications (DSRC). For example, the roadside interface described in the NA's DSRC Standards Requirements Package includes the following functions which directly interface with ATMS.

- In-vehicle signing

- Probe data collection

- Intersection collision avoidance

- AHS interface to the infrastructure

The DSRC standards development has also been given high priority within the ITS community and is expected to be supported by one or more of the five FHWA cooperative agreements with SDO's.

• In addition, Digital Map Data Exchange and Location Referencing Formats will bear on how the TMDD defines data terms associated with links, roadway elements, traffic control device location, etc. Signal Priority for Transit and Emergency Vehicles as well as Transit Management Subsystem to Transit Vehicles and Transit Stops identify the important interface between ATMS and APTS which must be coordinated in the TMDD development.

Table of Contents

5.5 International Standards Activities

The United States was an early organizer and now participates in international ITS standards setting activities through the ISO TC204 and its many working groups. The scope of this international set of activities includes essentially the full range of ITS. Thus, there are several working groups whose scope relates to the TMDD. For example, of the now active fourteen working groups, WG1, Architecture, Taxonomy and Terminology has produced a substantive draft of a Glossary of Transport Information and Control Systems. Another directly related group is WG9, Integrated Transport Information, Management and Control which is currently quite active. Technical coordination between the activities of the TMDD and these relevant ISO activities are enhanced by having two members of the TMDD Steering Committee who also are US members of ISO WG1 and WG9. Additional coordination will be maintained overall through the ITS America Standards and Protocols Committee which provides US coordination with these international activities.

Table of Contents

6.0 POLICY CONSIDERATIONS

There are a range of what can be referred to as policy considerations that are associated with the development of the TMDD. These have various aspects which, if not dealt with appropriately, could seriously limit a successful outcome of the TMDD effort. Although many of these issues are inter-related, the more important issues are separated out for discussion.

Table of Contents

6.1 National Stature

A primary and fundamental requirement for the TMDD effort to successfully meet its goals is for this effort to be acknowledged as the authoritative and recognized national forum for ATMS TMDD decisionmaking. That is, the TMDD Steering Committee and associated standards making process must be recognized and supported by the ATMS stakeholder community as the final authority for resolving for the United States the many issues confronting the development of a standardized national TMDD. There are a range of ways to assure this national stature is achieved and maintained. One key requirement is for the FHWA, in particular, to put its full commitment behind this specific effort and support it and resulting products in times of controversy. This is essential for this TMDD effort to realize its primary objective to establish a single, nationally recognized TMDD as contrasted to simply being another version which is used by some and ignored by others.

Table of Contents

6.2 Duplication and Overlap

Closely related to the preceding topic is the issue of existing duplication and overlap of documents, guidelines, etc. relating to the TMDD. The technical aspects of this were discussed in Section 5 where the many existing assortment of ATMS data dictionaries and/or related documents and activities were describe. The TMDD development effort can perhaps be best characterized as a consolidation and resolution activity. The committee will have to agree on that set of data elements which are representative and necessary to acceptably define the information which must be exchanged within the ATMS environment and with other users services.

This coordination becomes especially important in resolving differences of semantics or syntax on data elements shared with other ITS user services. Where the TMDD Steering Committee is being established as the authority for ATMS definitions, it obviously does not have that same authority for these other non-ATMS applications. This will mean that the various needs and approaches which have been used by others must be understood, reconciled, coordinated and then consolidated into a standardized set of terms. Thus, the establishing of specific liaison with these non-ATMS user services will be required as the TMDD development takes place. This responsibility of the TMDD Steering Committee is further evidence for the need to support their national stature and authority for this level of decision making.

Table of Contents

6.3 Building National Acceptance for the TMDD

One primary way for eventually gauging the national value of this TMDD development activity will be the degree of national acceptance and implementation of resulting TMDD products. This acceptance will be influenced and shaped by a number of factors, some of which have already been discussed. These include the following:

• The perceived national stature and authority of the TMDD activity and its principals. This is seen as so important that it has been separately discussed as the first policy consideration of this activity. Suffice it to repeat, the TMDD Steering Committee and associated process must be recognized as the national focal point and authority for decision making related to the TMDD.

• Gaining and maintaining this national stature and authority also require that the principals involved, especially the members of the Steering Committee, be recognized as knowledgeable and respected professionals in the ATMS community. Further, the Steering Committee must maintain an acceptable balance of philosophy and public/private perspective. This has been a primary consideration in recommending the specific group of individuals for the Steering Committee. However, as the TMDD process unfolds, attention must be given to assuring that the membership continues to reflect the proper balance and provides an open and honest hearing of various viewpoints and positions.

• The national acceptance of TMDD products will also be influenced by the national stature of the SDO(s) responsible for the TMDD development and who will support the TMDD Steering Committee in its deliberations and operations. This appears to be assured as the SDO's will include the ITE and AASHTO in some form of participating relationship. Both the ITE and AASHTO will significantly aid the acceptance of both the TMDD process and its products through publicity in its in-house publications, meetings, conferences and related workshops. It will also be incumbent on the TMDD SDO's to liaison with other standard development organizations in the TMDD development. These would certainly include NEMA, SAE, IEEE and ANSI and others should be approached as to their interest.

• Establishing and maintaining effective outreach with the ATMS stakeholder community dictates that the TMDD development be as open as possible consistent with the Steering Committee maintaining the ability to function efficiently. As part of this openness, it is recommended that a larger "Friends Committee" be established. This committee would have informal membership open to all interested parties but would not directly participate in Steering Committee meetings. Rather, they would be kept briefed on the current development status, provided draft positions and afforded an opportunity to comment. This open process can be assisted and made more efficient by establishing a TMDD site on the Internet as has been done by others notably the NTCIP activity. As in the NTCIP model, documents and status would be open to any Internet user. A separate closed area would be maintained for the use of the Steering Committee as they develop, review and dialogue in the development of draft positions, etc.

• Finally, to assure formal acceptance of final products, there is the question of whether to establish the resulting TMDD as a formal standard at the national level and possibly at the ISO level. This can be a lengthy process and may not be required before actually implementing TMDD products in operational systems. However, this option can be considered later in the TMDD development if changing factors or positions appear to warrant a formal standard.

Table of Contents

6.4 Timeliness of Product and Prioritization

This is seen as a policy consideration as the overall and complete development of a TMDD with its information interfaces with other ITS user services could be a lengthy process. Depending on the number of issues that arise and the efficiency with which they can be resolved, it clearly is a process that can be measured in years rather than months when compared to other similar standards development activities. While every effort will be made to expedite the complete TMDD development, it is believed to be prudent to plan the process such that individual pieces of the TMDD can be completed in sequence such that a stream of completed sections can be provided to the user community. This will serve to maintain the ATMS community's interest and support of this effort and help assure acceptance of TMDD products. This development process will require a partitioning of the overall effort and a prioritization of when individual sections will be developed. Some considerations on this item are included in the following section.

Table of Contents

7.0 DEVELOPMENT APPROACH

7.1 Organization Structure and Roles

The organization structure and respective roles for the TMDD Steering Committee and related organizations are diagrammed in Figure 11. In overall philosophy of approach, the Steering Committee is at the center of the TMDD development. The Steering Committee is supported technically and administratively in performing its functions by the ITE. The FHWA financially assists the ITE in its support of the TMDD development through a cooperative agreement. The Steering Committee also interfaces with other SDO's and an outreach "Friends Committee" to assure the opportunity for comment and consideration of other outside activities which may be relevant to the TMDD.

This structure places a premium on vesting the overall TMDD decisionmaking responsibility in a steering committee composed of peer stakeholders. This is considered essential to both maintaining focus on a practical, relevant product as well as assuring its acceptance by the ATMS community. A list of the roles and responsibilities of the Steering Committee are shown in Table 3.

Table 3

ROLES AND RESPONSIBILITIES OF

THE TMDD STEERING COMMITTEE

The TMDD Steering Committee is the authoritative national body for this effort and is charged with a full range of planning, management and coordination tasks. It is the national forum within which TMDD issues are identified and resolved. A listing of the significant roles and functions of this committee include:

• Strategically plan and guide the TMDD development including establishing the priority and sequence of work on individual ATMS functional areas and interfaces including those with other user services.

• Coordinate and liaison with other groups, activities and interests that relate to a TMDD.

• Determine the scope, organization and substance of the TMDD including the specific data elements and definitional structure that will be included.

• Establish the actual definition and related attributes or parameters for TMDD data elements.

• Assess the relevance of existing TMDD's and related standards and protocols and determine if and how their data elements will be incorporated.

• Provide direction to the supporting SDO on required work tasks including, assembling necessary resource material, developing draft documents, etc.

• Guide and assist in the acceptance of the resulting TMDD by the United States ATMS community including both system and hardware suppliers, operators, owners and policy related organizations.

As the Steering Committee consists of voluntary participation by members with other full-time responsibilities, it will not be normally expected that the committee members perform the staff work associated with this activity. For this purpose the ITE will provide staff support through both direct ITE staff as well as professional service agreements with others as required. For the acquisition of these services, ITE will provide the contract administration. A listing of the support functions provided by the ITE to the TMDD Steering Committee is shown in Table 4.

Table 4

ITE SUPPORT FUNCTIONS FOR

THE TMDD STEERING COMMITTEE

• Coordinate with AASHTO and other interested SDO's in the cooperative performance of the TMDD development

• Identify, assess and provide applicable documents, practices, standards, etc. relating to a TMDD

• Analyze issues and alternatives and prepare position papers and draft standards

• Contract for and oversee professional service support activities

• Arrange and administratively support committee meetings including serving as Committee Secretary

• Provide travel financial assistance to public members as required

• Maintain liaison with and represent the TMDD effort in related national standards activities

• Establish and maintain a TMDD site on the Internet.

• Interface with the FHWA in their cooperative support of the TMDD effort

• Assist the Chairman in planning and coordination activities including senior level interfacing with outside interests, organizations and activities.

• Perform outreach activities including support of Friends Committee, publicity and publications, presentations in selected national and international forums, and maintaining active liaison with key stakeholder groups

• Provide program management including planning, scheduling, monitoring, review and reporting for the overall effort.

Table of Contents

7.2 Packaging the TMDD Scope of Work

The actual development of a complete TMDD that will cover the information interfaces with all ITS user services is a very substantial undertaking. Using the old analogy, it clearly is too big an elephant to eat at one time. What is required at the beginning of the program is to decompose the overall effort into separate packages and to then undertake their individual development in some sequence. This dictates the need for establishing the structure of these packages as well as their priority in their sequencing for TMDD development.

There are different broad strategies or rationales that can be used to partition the overall universe of TMDD data elements into some number of smaller groupings or packages. For example:

1. One obvious approach is to group the TMDD data elements into those used only within ATMS and then those subsets which support or interface with the different major ITS functions or user areas of APTS, ATIS, CVO, etc.
2. Another approach is to attempt to group the data elements according to completed or on-going efforts that directly relate to the TMDD such as those identified by the NTCIP. These data sets could then be brought before the TMDD Steering Committee and either enhanced, modified, or accepted. This strategy could hopefully complete the TMDD process more quickly in those areas where substantial work has already occurred. This would make the biggest contribution in terms of providing early TMDD products.
3. Another approach is to structure the data element packages in a form of hierarchy. That is, those data sets needed for interstate coordination such as the I-95 Corridor, those for regional coordination in large urban areas, and then those at the local coordination level within a particular municipality or city.

Actually, these three possible packaging approaches are not necessarily independent but could be combined in some instances. For example, the second approach could be used where applicable in either one or two.

Table of Contents

7.3 Development Tasks

Within each package, a straightforward development approach would include:

1. Collect and assemble all subject relevant material from existing glossaries, data dictionaries, and architectures, etc.
2. Prepare an initial candidate list of all data elements and/or message sets
3. Decompose the list with its different variants of similar data elements into root data elements and/or groupings having essentially the same meaning or purpose.
4. Assess the candidate list as to completeness for its intended application
5. Resolve differences in function, application and terminology.
6. Prepare a recommended TMDD for that package and distribute for comment.
7. Review comments, finalize and distribute the package for implementation.

 Table of Contents

8.0 SCHEDULE AND RESOURCES REQUIRED

8.1 Schedule Considerations

Developing a realistic schedule for the TMDD development is difficult at best. The big unknown is predicting the number and the time that will be required to resolve particular definitional and application issues that will arise. To better estimate, guidance was sought by examining existing examples of similar national activities.

As earlier noted, the Traffic Records Systems described their standards development as taking place over six years. The SAE standards committees typically meet every two months on its high priority activities. There work on a data set for Navigation has taken approximately three years to date. The NTCIP process has now been actively underway for about two years.

It is not meant to infer that the TMDD is directly comparable to these preceding examples, but there is enough similarity to believe that the completion of a full TMDD will not be a short task. In discussion with different individuals who are familiar with this area as well as some of the preceding activities, it was generally believed that this activity would require at least two years. There are, however, strong needs to complete the TMDD sooner as there is clearly a sense of urgency to put in place the necessary standards to facilitate the deployment of the Intelligent Transportation Infrastructure (ITI). This is a commitment of both the US DOT as well as the ITS user community which expects to see the ITI providing the information base for various private industry ITS market applications.

It is believed that dealing with this schedule/need dilemma places a major emphasis on packaging the overall TMDD work such that key deliverables can be provided early and then consistently throughout the TMDD development. This was also the point of discussion in the previous section because clearly the completion of the full TMDD scope is expected to be a multiyear endeavor due to the extensive coordination with other ITS user services and functions. It is possible, however, that the core ATMS message sets can be developed as a draft in approximately one year if consensus can be achieved expeditiously.

Table of Contents

8.2 Resource Considerations

In Section 7.1 the roles of the Steering Committee and the responsible SDO were described. The SDO professional and administrative staff needed to support the TMDD development is estimated as shown in Table 5.

Table 5

TMDD STAFF RESOURCE NEEDS

Table of Contents

9.0 FUTURE MAINTENANCE

The most effective means of maintaining completed ITS standards is an item under debate within the ITS community. Although maintenance of the completed TMDD is not in the scope of this effort, it is an important issue that deserves highlighting. The policy assumption for this Strategic Plan is that the TMDD will be developed in series of individual sections (or packages). Each of these as they are completed will be released initially in some form of "Recommended Practices" to expedite their early introduction. Subsequently, they may be further formalized in the normal standards process and/or incorporated into various specifications and Federal Aid requirements as desired.

The point is simply to emphasize that there will be a continuing requirement in the ITS community to maintain the individual sections of the TMDD and to guide their possible formalization into US standards and ISO standards. The TMDD Steering Committee may find it useful to consider these maintenance needs and to provide their recommendations as the overall ITS standards and architecture maintenance policy evolves.

Table of Contents

10.0 NEAR TERM ACTIONS

With the priority attached to the development of a standardized TMDD, there are a set of near term actions that should be performed to rapidly transition into the actual TMDD development. Most of these actions have been discussed previously in this report in some form or other. These are summarized and presented in Table 6. Responsibilities and scheduling are noted where relevant.

This report prepared for the Institute of Transportation Engineers by:

Lyle Saxton
Consultant
6108 Browning Lane
Broad Run, VA 22014
540-347-9512
March 8, 1996

Table 6

TMDD DEVELOPMENT NEAR-TERM ACTIONS

Table of Contents