A. ITS SYSTEM AND SUBSYSTEM-RELATED
1. ITS Architecture documents
1.1 Executive Summary [EXECSUM.DOC]
Note: A preliminary review of
this document was conducted for general background purposes only.
The preliminary review was deemed sufficient.
1.2 National Architecture Vision [NARVSN.DOC]
Note: A preliminary review of
this document was conducted for general background purposes only.
The preliminary review was deemed sufficient.
The ITS architecture is based
on 29 user services, with 19 subsystems in four major areas. It
includes a logical architecture, a physical architecture, and
a mapping. Subsystem interconnections are modeled via data flows.
1.3 Logical Architecture
[LAVOL1.DOC, La_v1c/doc, La_v2.doc, La_v3.doc]
This is an important document.
Although it deals with DD/MST contents, it provides a perspective
on the nature of ITS data and interchange among ITS subsystems.
It is also a potential source for examples for the guidelines
document. La_v3.doc contains the (full) ITS-level data dictionary.
The ITS-level DD dealt with supporting
subsystem-subsystem interfaces. One use of this global DD is for
control, somewhat also as a design specification, and somewhat
also strictly for information or communication purposes. Its form
varies from informal (text-based glossaries) to formal (CASE models).
The CASE models were produced using Cadre's TEAMWORK product.
This allows export of CDIF files, which can then be imported into
RDBMSs such as MS Access. The overall structure is: Transaction;
Data Flow; Data Element. However, the contents are not usually
(or always) limited to data elements. They address three views:
Control, Process and Data. [Note: That implies constraints/rules,
process models and data/information models]. There are 300 processes
in ITS, with 80 DFD's and one global DD. There are 2500 'entries'
in the DD: these define data elements that are interchanged
between two or more of the processes. [Note: These are not
being reviewed in detail as part of this effort, as these represent
DD content, not structure. However, cursory reviews have been
performed in conjunction with reviews of the ITS subsystem documents
noted below, to ensure that the varying nature of ITS data is
taken into account when defining the meta structures for the ITS
1.4 Standards Development
Plan (SDP) [primary document is SDP.DOC].
This document provides a good
background on the areas for standardization within ITS and the
purpose and benefits of doing standardization.
"3. A review of the Logical
and Physical Architecture data dictionaries identify elements
that span multiple physical interfaces and services. These elements
are candidates for foundational standards."
"The approach that has garnered
the most attention and analysis to date is to review each of the
subsystem interfaces defined by the Physical Architecture as potential
candidates for standardization."
"To provide separable sets
of data elements for use by standards organizations, a set of
standards packages has been developed. Eleven packages have been
defined that cover most near-term applications...These packages
select specific interfaces from the architecture that have common
data elements. For example, map databases and location information
are used in multiple places in the architecture. One would expect
that they would all conform to the same standard A standards package
focuses on these data elements wherever they appear in the architecture."
Standards Requirements Packages
[see 1.5 below] have been produced as part of the architecture
as input to the standardization process. The SRPs contain data
dictionary element (DDE) definitions and sizes. These are described
"Abstracts that describe
the composite and primitive logical architecture data elements.
This is a brief description of each data item and its use. For
a more in depth examination of a data flow and the functions that
use it, it is necessary to refer to the logical architecture documentation."
Several relevant standards (existing
and in-work) are noted on pages 31-63, including the ITS subsystems
to which they apply. Page 32 notes several data dictionary (content)-related
Towards the end of the document
is table of standards projects, noting the umbrella ITS DD and
MST as being of high-priority and early need.
1.5 Standard Requirements
Package(s) (SRPs) [SRP1 to 11.DOC, plus two other documents]
These documents are basically
a repackaging of material extracted from the ITS architecture
and arranged into logical groupings for standardization of short-term,
high priority areas of the ITS. From the perspective of the DD
and MST standards projects, little or no new information is added
beyond the architecture documents (primarily the logical architecture,
which is of most interest to the DD and MST projects). Data dictionary
element (DDE) definitions are included in the SRPs. These obviously
deal with DD and MST content issues, and can complement the logical
architecture in terms of providing a sense of the nature of the
DD/MST data elements and the nature of subsystem interchange,
and perhaps as a source for examples for the guidelines.
1.6 Traceability Tables from Logical to Physical Architecture [TRACE.DOC].
Note: This is not really relevant,
as physical architecture is not an issue here, and I did not download
any documents related directly to the physical architecture.
2. Commercial Vehicle Information
Systems and Networks (CVISN) Data Dictionary preliminary, 29 February
1996 - (1 hardcopy). Note: This is the one completed ITS subsystem
data dictionary project.
Typical EAR (per clause 1.4.3
on section 1 page 10), supplemented with data flows (and therefore
some level of processes/functions). The data flows have attributes,
too. Note: Does the standard for ITS DDs need to allow mapping
of CS data concepts (within an IS) to particular application systems/applications
not just processes (the processes are CS and are currently the
subject of the data flows). The relationships in the data model
have the full suite of cardinalities. Emphasis is on the attributes
(i.e., data elements), which they define as consisting of "a
definition and the characteristics of the data." There are
also codes representing types of valid contents (i.e., 'system
tables' of types as values for a data element such as "Accident
Parameters", which would include a one or two character code
for the accident type). The tables are stated as having attributes,
too. Applied naming standards to data elements. Keep basic data
administration meta data such as source, format, synonyms, etc.
The data element description is a text block. Used Popkin Software's
CASE tool (System Architect). Didn't address composites, only
atomic data elements. Note in the DD, using asterisks, whether
a data element is a direct/exact use of X12 or D20, versus a specialization/modification/extension
(but don't define the nature of the specialization, etc. if it
is not an exact usage).
The DD contents are voluminous.
There are lot of synonyms, as well as 'repackaging' of the same
basic information into slightly different data structures. There
are some confusing entries. For example: CV_border_clearance_data
is stated as having the purpose of conveying identification numbers
for the carrier, vehicle, driver and manifest to the roadside.
However, the listing of data elements/attributes for this data
structure does not contain this information.
Since it is based on application
systems and reports and the like, one can speculate that it reflects
more of the flavor of COBOL copylib layouts than a true logical,
or even integrated physical, database structure.
Data structures and data flows
have a listing of data elements separated by commas or pluses
at the beginning, followed by an alphabetical listing of the data
elements as attributes on the data structures/data flows. I assume
the sequence of the comma-delimited list is significant: do these
map directly to standard message sets (at least for the data flows)?
The data models contain entities
with attributes just like the data structures/data flows only
without the separate delimited versus alpha listings (just a sequential
listing with one data element per line). These appear to be 'chunkier',
more generic entities versus the packages of more specific data
implied by the data structures and data flows.
3. Advanced Public Transportation
Systems (APTS) documents:
3.1 Advanced Public Transportation Systems (APTS): Evaluation Guidelines (softcopy)
Note: This document is not particularly
relevant. Deals mostly with surveying and test specification,
but some useful background on APTS, and the discussion of APTS
data gives a flavor of the nature of the data and provides a potential
source of examples from the APTS domain.
3.2 Federal Transit Administration
(FTA) - National Transit Geographical Information Systems (GIS)
Manual (softcopy), includes Spatial Data Features Definitions
as precursor to an APTS data dictionary
This document is a good source
for understanding the nature of spatial data that must be able
to be described (at the meta level) and managed in various ITS
DDs (although this particular application is for transit use specifically).
It is based on the FGDC standard.
"Metadata describe the content,
quality, contacts, conditions and other characteristics of a data
set. Many information specialist say that in the computer age,
data is not power, "metadata" is. More than any other
standard, the metadata provides a "roadmap" to information
in a data set. The metadata provides information on the organization
of, maintenance of and investment in data, data catalogs, access
paths, and data transfer. A metadata document on geospatial data
helps people who use geospatial data find the data they need and
determine how best to use that data. To this end, the Federal
Geographic Data Committee (FGDC) developed a Content Standard
for Digital Geospatial Metadata to facilitate access to data inventoried
in the National Geospatial Data Clearinghouse. This standard provides
a format to catalog information about geospatial data sets. Appendix
D contains an adaptation of the Content Standard for Digital Transit
Geospatial Metadata reflecting transit domain considerations.
The appendix describes and explains elements of the FGDC Metadata
standard, and augments the FGDC version with guidelines for transit
features, themes and databases. Metadata documents created for
each data set in the NTG will advance appropriate use of the data,
and those created for data sets submitted to the NTG will improve
the data's integration with the NTG."
It deals mostly with the schemas
required to represent and interchange spatial/GIS data (i.e.,
it is primarily content-related as far as the DD/MTS goes), but
also deals to some degree with the meta structures used for those
"Referential Integrity refers
to the accuracy, validity or correctness of the data in meeting
the constraints and rules defined by the internal structure and
content of the data. These rules apply to multiple levels of data
and data base management systems. Tabular data are constrained
by data domain and type rules, and data base management system
rules. The relational database model must be normalized, and referential
integrity constraints ensure that a unique primary key exists
for each table and no foreign key is unmatched to a primary key.
General integrity constraints associated with geographical data
relate to data quality, such as ensuring fundamental relationships
in the graph structure. For example, the sum of the degrees of
the graph vertices equals twice the number of edges, where the
vertex is a node and the edge is the line between two nodes."
Requirements to support transaction
specifications are also discussed.
3.3 APTS Map Database User
Requirements Specification, includes Spatial Features and
Feature Types (hardcopy)
This document gives a good flavor
for the disparity of data to be described and managed in a data
dictionary even just within public transit. There is financial
data like fare collection, and geospatial data like "where
in the world is the bus stop I'm looking for." The geospatial
data raises some questions about what level(s) of this they expect
to put in (various) ITS data dictionaries, and whether that affects
the meta-data structures and relations they need. They talk for
example (on page 5) about a Geographic Layer with Spatial Object
that has examples: Point, Piece, Polygon, Path and Plane; a Transit
Concept Layer that has Spatial Feature with examples: Access Point,
Segment, Transit Route; and a Transit Application Layer that has
Included Term: Bus Stop, Fixed Route, Bicycle Path. They address
Functions, as well as Features (which are entities or objects
in everybody else's terminology) and Attributes, and the mapping
between Functions and Features+Attributes.
3.4 Final Draft White Paper
on The National ITS System Architecture: Data Dictionary for Transit
This white-paper was written
by Sandia, and esstentially states that the overall ITS data dictionary
portion of the ITS architecture did not take into their early
work on transit-related data, and does not meet the 'requirements'
for APTS. They are very implementation-oriented, and appear to
want common definitions and objects that they can easily reuse
during actual physical system development and implementation,
particularly to support real-time messaging for PT fare collection,
locationing, etc. They complain that the ITS DD (which is part
of the ITS Logical Architecture) addresses only portions of the
'technical definition' of data [elements] (such as size, data
rate, etc.) and nothing in the area of how data are physically
transferred (media, protocol, frequency bands, software standards).
It is apparent from looking at
the logical-to-physical comparison for transit-related data elements
that there are major differences. One difference they point out
is genericity versus specialization: they want common, general
data elements at the physical level, whereas the logical architecture
contains all sorts of specializations of data elements to reflect
their specific use in various data flows (which correspond to
detailed transactions to support particular services). There are
also naming conventions problems (see page 14 for an example),
and there are cases where at least some of the logical data elements
that are mapped to a single, common physical data element don't
appear to be a good (or at least intuitive) match at all.
4. Traffic Management Data Dictionary (TMDD)
Note: The frst internal draft
of the actual TMDD is due in January, but may not be available
in 'public form' until March. In lieu of this material, the following
TMDD-related documents in existence at this time were reviewed:
4.1 Strategic Plan for a Data
Dictionary for Automated Traffic Management Systems (ATMS)
- Some relevant excerpts from the Strategic Plan:
"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
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.
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.
Listing of Data Element Description
for Traffic Records Systems - ANSI D20.1
* Short Name
* 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)
* Other Characteristics
* Source of Data Representation
* Description of Data Items (Name of Item, Abbreviation, Code,
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
* 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."
Note: This is basic EAR, with
the attributes being largely extensional and most of the semantics,
including relationships and typing buried in the text-based definition.
"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."
Note: This brings up the need
to clearly allow for ES, IS and CS in the DD, but to stress that
physical implementation (IS) should not be the primary issue except
in cases of very static, hardwired interchange among homogeneous
systems. For performance, this will likely need to be the case,
for example, for real-time messaging. But you don't get information
interchange unless the CS (read, the semantics) are interchanged
between the systems, too.
"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."
Note: The messaging format used
is based on the OSI seven-layer architecture, and uses ASN.1,
as noted below:
"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). 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
Status - Support is either mandatory,
optional or obsolete."
Note: Again the semantics are
essentially only a text-string within a message.
4.2 Summary document (softcopy)
- Brief background.
4.3 The TMDD Prototype: An Analysis of ISO 11179 for the Development of ITS Standard Data Dictionaries (dated January 27, 1997)
Note: Refer also to the analysis
of the IS 11179 standard documented in the companion notes on
existing and emerging standards.
5. Data for Decision Requirements
for Transportation Systems (softcopy)
The need for intermodal data
analysis indicated in this report is a general driver for providing
a DD standard that would enable information interchange. That
interchange needn't be limited to intra-ITS systems, but also
between those systems and the systems of related external organizations
such as DoE, EPA , DoD, DoA and the Census Bureau.
"What is lacking is a systemwide
framework and capacity to integrate and compare data on a more
consistent basis over time to track system performance and determine
where the transportation system is headed."
It was noted that more 'demand-oriented
data' is needed to indicate areas of weakness and where to focus
"An effective data support
system has two essential components. First, the data should be
organized in a framework keyed to the broad subject areas of interest.
Second, analytic capability is critical to ensure that the data
are translated into information that is useful for policy analysis.
The latter is particularly important for understanding qualitative
changes that are not readily measured or, if they do appear in
time series data, are reflected too late for policy makers to
"The time and cost of collecting
and integrating data, as well as the need for systematic and reliable
monitoring over time, work against constant modification of data
bases. Thus, NTPMS is best structured not by issues, which tend
to be transient, but by major attributes of the transportation
system, which fall into four broad categories - supply, demand,
performance, and impacts."
"At a minimum, a brief description
of the data items, their sources, and methods of collection should
be provided. A summary of key trends and changes in trends would
also be appropriate, as would a discussion of the quality and
limits of the data."
"The biggest gap in DOT's
multimodal data programs is in flow data. Flow data refer to information
on passenger and freight volumes from origin to final destination
by trip purpose, distance, mode, and passenger and freight characteristics."
"The Statement of National
Transportation Policy identified safety as the top departmental
priority (DOT 1990, 7), yet the data to monitor the safety and
security of the system across all transportation modes are inadequate."
Note: This is due to different
levels of details, different measures, lack of correlation with
volume (e.g., flow) statistics, etc. Things like performance versus
condition reporting are also made difficult because of a lack
of correlation and because of differing underlying assumptions
used in statistical models. Are these assumptions ever part of
a DD, or are they strictly part of stand-alone statistical analysis
and simulation systems? If data warehousing is a technology to
be used in the future, ITS DDs will need to have such information.
It was noted that a lot of the
data envisioned as being collected by in-vehicle systems and related
traffic control systems is intended for systems management. The
DoT would also like to have access to this information for broader
statistical analysis purposes. Use of data collected by the private
sector is also desired.
Appendices provide a listing
of existing databases, data programs and reports within the agency.
6. NATO Industrial Advisory
Group, Subgroup 52 (NIAG/SG52), Allied Naval Engineering Publication
(ANEP)-51, NATO Naval Combat System Information Catalogue, Volume
0 - Introduction and Volume 4 - Message Construction Standard
At the level of Volume 0, there
appears to be many similarities to the objectives and overall
structuring of approaches between ANEP and the ITS DD standard
and guidelines and MST standard. For example, the notions of 'formally
and unambiguously' defining data structures and data elements
and the [generic] messages they get packaged into are found in
both projects. ASN.1 is the expression mechanism, with MS Access
serving at least as an interim analytical tool, if not a limited
data dictionary or registry [Note: Vol. 0 talks about standardization
of data elements and messages, particularly looking towards genericity
to reduce unnecessary differences and hence reduce ambiguity].
There are also some obvious differences in terms of the breadth
and general nature of the data being interchanged; ANEP data might
well be fairly analogous to the emergency and traffic management
data within the ITS, but doesn't deal with commercial/business
data elements, financial data feeds, etc. that are more complex
and don't map as directly to the low-level basic data types of
ASN.1 (e.g., Integer, Real, String, etc.).
Based on reviewing Volume 0,
the most relevant detailed document to review appeared to be
Volume 4: Message Construction Standard. This was stated as providing
a "formal and unambiguous syntax for the definition of messages
and data structures (components of messages)". Some of the
basic data elements are also stated as being 'formally defined'.
However,, within Volume 4 itself it makes it clear that 'formally
defined' is really only 'formally syntactically defined'. The
basic data types are really only the eight most primitive ASN.1
data types (i.e., they don't really even make use of the full
set of ASN.1 basic types). Additionally, while ASN.1 may be formal
and unambiguous in its syntax (since the syntax and at least aspects
of the associated grammar are defined in specifications that are
well-controlled standards documents), that does not in any way
mean that the [semantic] definitions one specifies using ASN.1
are necessarily formal or unambiguous. That would be presuming
the nature of content based on the nature of its form. "C"
is a formal and unambiguously defined programming language, but
that does not mean someone cannot write bad or completely nonsensical
programs in it, and while they may compile and execute, they don't
produce any meaningful output. Saying, for example, that Message
37, Incident, is a set with members Incident Type (VisibleString),
Date (VisibleString -- YYYYMMDD), ShipNumber (Integer), NatureOfIncident
(VisibleString) and Report (Sequence of Events (VisibleString))
doesn't tell a human user explicitly about what an incident is,
what a ship is, what's an acceptable description of the nature
of an incident, what constitutes and event versus a part of an
event or a description of an event. A message of this nature can
be parsed and read into a receiving application, but unless that
application already 'knows' what those data elements mean and
has the same expected meanings for them as the sending application,
then there is no assurance of nonambiguity. Given that, appropriate
questions to ask would include: do these standards at least include
a set of procedures for defining data elements in a consistent
manner using, for example, structured English; do they have a
set of real 'building blocks." In this case, the answers
seem to be 'no', and that is apparently sufficient in this case,
as the messages are simple enough and the data structures and
data elements are at a low enough level that a direct mapping
to ASN.1 basic data types provides recipients of the message all
that is necessary (in this case, syntax) to act upon the message
or otherwise make use of it in the receiving application's context.
Back to Home Page E-mail to Sue Vogel, Staff