Archived Data Management System
Data Model
FINAL REPORT
Prepared for
U.S. Department of Transportation
Federal Highway Administration
Office of Highway Policy Information
400 Seventh Street, SW
Washington, D.C. 20590
September 11, 2002
Prepared by
505 King Avenue
Columbus, OH 43021
Trevilon Corporation
Cambridge Systematics, Inc.
DISCLAIMER
This report is a work prepared for the United States Government by Battelle. In no event shall
either the United States Government or Battelle have any responsibility or liability for any
consequences of any use, misuse, inability to use, or reliance on the information contained
herein, nor does either warrant or otherwise represent in any way the accuracy, adequacy,
efficacy, or applicability of the contents hereof.
Archived Data Management System Data Model – Final Report
TABLE OF CONTENTS
Page
ACRONYM LIST .......................................................................................................................... V
EXECUTIVE SUMMARY .......................................................................................................... VI
Data Model Development Process ..................................................................................... vi
Complications ................................................................................................................... vii
The Data Model ................................................................................................................ vii
Communications Interface Model......................................................................... vii
Incident Report..................................................................................................... viii
Traffic Report.......................................................................................................... x
Compatibility Analysis ..................................................................................................... xii
Future Directions .............................................................................................................. xii
Need to Refine Model ........................................................................................... xii
Need to Harmonize Data ....................................................................................... xii
Need to Coordinate Model with Message Set Efforts ......................................... xiii
Need to Extend Model ......................................................................................... xiii
Conclusions ...................................................................................................................... xiii
CHAPTER 1:
1.1
1.2
1.3
INTRODUCTION .................................................................................................. 1
Background ............................................................................................................. 1
Objectives and Scope .............................................................................................. 1
Organization of Report ........................................................................................... 2
CHAPTER 2: LITERATURE REVIEW ....................................................................................... 3
2.1
Introduction ............................................................................................................. 3
2.2
Archived Data User Service and Archived Data Management System .................. 4
2.2.1 National ITS Architecture ........................................................................... 4
2.2.2 ADUS and ADMS ...................................................................................... 4
2.3
ADUS Standards ..................................................................................................... 9
2.3.1 ITS Standards Development ....................................................................... 9
2.3.2 ADUS Standards Development ................................................................ 10
2.4
Data Modeling ...................................................................................................... 11
2.4.1 Data Modeling Concepts........................................................................... 11
2.4.2 ADMS Data Modeling .............................................................................. 12
CHAPTER 3: DATA MODEL .................................................................................................... 16
3.1
Introduction ........................................................................................................... 16
3.1.1 General ...................................................................................................... 16
3.1.2 Actors ........................................................................................................ 17
3.1.2.1 ADMS Administrator................................................................. 17
3.1.2.2 Archived Data User.................................................................... 17
3.1.2.3 Data Provider ............................................................................. 17
3.1.2.4 Government Reporting System .................................................. 17
Archived Data Management System Data Model – Final Report
i
TABLE OF CONTENTS (CONTINUED)
Page
3.2
3.3
3.4
3.5
3.1.2.5 Remote Archive ......................................................................... 17
3.1.2.6 Financial Institution ................................................................... 18
3.1.3 Organization of Chapter ............................................................................ 18
Concept of Operations .......................................................................................... 18
3.2.1 Section Tutorial ......................................................................................... 19
3.2.2 Service Diagrams ...................................................................................... 22
3.2.2.1 Introduction ................................................................................... 22
3.2.2.2 Service Descriptions ..................................................................... 23
Functional Requirements ...................................................................................... 27
3.3.1 Section Tutorial ......................................................................................... 27
3.3.2 Service Requirements ............................................................................... 28
3.3.2.1 Login Service Requirements ......................................................... 28
3.3.2.2 Administrative Services Requirements ......................................... 28
3.3.2.3 User Services Requirements ......................................................... 32
Interaction Specification ....................................................................................... 34
3.4.1 Section Tutorial ......................................................................................... 35
3.4.2 Interface Specifications ............................................................................. 37
3.4.2.1 Manage Archive Configuration .................................................... 37
3.4.2.2 Retrieve Data ................................................................................ 39
3.4.2.3 Submit Data .................................................................................. 45
Data Dictionary ..................................................................................................... 48
3.5.1 Compatibility Analysis ............................................................................. 48
3.5.2 Section Tutorial ......................................................................................... 49
3.5.2.1 Communications Interface ............................................................ 49
3.5.2.2 Incident Report.............................................................................. 49
3.5.2.3 Traffic Report................................................................................ 56
REFERENCES ............................................................................................................................. 64
BIBLIOGRAPHY ......................................................................................................................... 65
List of Appendices
Appendix A – Manage Archive Configuration Details .............................................................. A-1
Appendix B – Retrieve Data Service Details .............................................................................. B-1
Appendix C – Submit Data Service Details ................................................................................ C-1
Archived Data Management System Data Model – Final Report
ii
TABLE OF CONTENTS (CONTINUED)
Page
LIST OF TABLES
Table 2-1. Stakeholders for Archived ITS Data ............................................................................ 5
LIST OF FIGURES
Figure ES-1.
Figure ES-1.
Figure ES-2a.
Figure ES-2b.
Figure ES-3.
Retrieve Data – View of Participating Classes Diagram ..................................... viii
Retrieve Data – View of Participating Classes Diagram ..................................... viii
Incident Report Diagram, Part 1 ............................................................................ ix
Incident Report Diagram, Part 2 ............................................................................. x
Traffic Reports Diagram ........................................................................................ xi
Figure 2-1.
Figure 2-4.
ITS Data Mart Market Package: National ITS Architecture, available at
www.iteris.com/itsarch (as of March 2001) ........................................................... 8
ITS Data Warehouse Market Package: National ITS Architecture, available at
www.iteris.com/itsarch (as of March 2001) ........................................................... 8
ITS Virtual Data Warehouse Market Package: National ITS Architecture,
available at www.iteris.com/itsarch (as of March 2001) ........................................ 9
Data Modeling Process ......................................................................................... 14
Figure 3-1.
Figure 3-2.
Figure 3-3.
Figure 3-4.
Figure 3-5.
Figure 3-6.
Figure 3-7.
Figure 3-8.
Figure 3-9.
Figure 3-10.
Figure 3-11.
Figure 3-12.
Figure 3-13.
Figure 3-14.
Figure 3-15.
Figure 3-16.
Figure 3-17.
Sample Physical Architecture for an ADMS ........................................................ 20
Identifying Actors on a System............................................................................. 21
Sample Use Case Diagram for ADMS ................................................................. 22
Login Service Diagram ......................................................................................... 23
Administrative Services Diagram ......................................................................... 24
User Services Diagram ......................................................................................... 26
Sample Sequence Diagram for Login Service ...................................................... 35
Sample VOPC Diagram for Login Service ........................................................... 36
Manage Archive Configuration - Sequence Diagram ........................................... 37
Manage Archive Configuration – View of Participating Classes Diagram .......... 39
Retrieve Data – Sequence Diagram ...................................................................... 40
Traffic Reports Diagram ....................................................................................... 42
Retrieve Data - View of Participating Classes Diagram ....................................... 43
Incident Report Diagram, Part 1 ........................................................................... 44
Incident Report Diagram, Part 2 ........................................................................... 45
Submit Data - Sequence Diagram ......................................................................... 46
Submit Data - View of Participating Classes Diagram ......................................... 47
Figure 2-2.
Figure 2-3.
Archived Data Management System Data Model – Final Report
iii
TABLE OF CONTENTS (CONTINUED)
Page
List of Figures (Continued)
Figure A-1.
Manage Archive Configuration - Sequence ........................................................ A-2
Figure B-1.
Figure B-2.
Figure B-3.
Figure B-4.
Retrieve Data – Sequence ................................................................................... B-1
Retrieve Data Consumer Interaction – Sequence ............................................... B-3
Retrieve Data Consumer-Supplier – Sequence ................................................... B-4
Retrieve Data Supplier Interaction – Sequence .................................................. B-5
Figure C-1.
SubmitData – Sequence ...................................................................................... C-2
Archived Data Management System Data Model – Final Report
iv
ACRONYM LIST
AADT – Average Annual Daily Traffic
ADMS – Archived Data Management Systems
ADU – Archived Data User
ADUS – Archived Data User Systems
CORBA – Common Object Request Broker Architecture
CVO – Commercial Vehicle Operations
DFD – Data Flow Diagram
ER – Entity Relationship
ESAL – Equivalent Single Axle Loads
FARS – Fatality Analysis Reporting System
GRS – Government Reporting System
GUI – Graphical User Interface
HAZMAT – Hazardous Material
HOV – High Occupancy Vehicle
HPMS – Highway Performance Monitoring System
IEEE – Institute of Electrical and Electronics Engineers
IT – Information Technology
ITS – Intelligent Transportation Systems
MPO – Metropolitan Planning Organization
NTCIP – National Transportation Communications for ITS Protocol
NTD – National Transit Database
TCIP – Transit Communications Interface Profiles
TDF – Travel Demand Forecasting
TMDD – Traffic Management Data Dictionary
UML – Unified Modeling Language
VOPC – View of Participating Classes
Archived Data Management System Data Model – Final Report
v
EXECUTIVE SUMMARY
Much of the data generated by intelligent transportation systems (ITS) can be of great value
beyond their immediate use in real-time situations, such as reacting to an incident. ITS
equipment collects significant amounts of data; however, little of it is archived for future use by
traffic planners and other interested parties. Performance monitoring, near-term and long-term
planning and analysis, and many other applications can make use of this information.
Accordingly, the Archived Data User Service (ADUS) was added to the National ITS
Architecture and a Federal program to promote ITS data archiving was instituted. This
document proposes a data model for use by Archived Data Management Systems (ADMS) to
store such data.
This document defines the requirements for an Archived Data Management System (ADMS) as
derived from the requirements contained in the National ITS Architecture. Reformatting of these
requirements has been performed in order to define more clearly the key actors (entities that
interact with the system), and how they use the system. These associations are then categorized
as: (1) an implementation-specific interface that is not subject to standardization, (2) a critical
association that should be investigated in the first phase of the effort to produce an Archived
Data Model, or (3) an association that may be the subject of a future effort.
Data Model Development Process
Developing a robust data model requires considerable thought. Over the years, the information
technology (IT) industry has developed well-defined systems engineering processes in order to
develop such models. The ADMS Data Modeling effort uses the state-of-the-art process known
as the Rational Unified Process, which combines the philosophies of three world-renowned
experts in IT (Ivar Jacobson, Grady Booch, and James Rumbaugh) into a single development
framework [9].
The first step in this process was to identify the major services that the system will provide. This
was initially achieved by looking at the National ITS Architecture and then was validated
through user interviews. This analysis identified two major categories of services: those
provided to ADMS administrators and those provided to more general users. Administrative
services include functionality to: (a) Request Archive Metrics, (b) Submit Data, (c) Manage the
Archive Configuration, (d) Retrieve Data, and (e) Manage the Archive. Services that relate to
ADMS end-users (also referred to as Archived Data Users [ADUs]), include the ability to: (a)
Request a Government Report, (b) Request a Data Catalog, and (c) Request Data. Both sets of
users also share a service for authentication, the Login service.
Once these services were defined, the next step was to analyze them to determine how the
system would provide these services. However, not all services needed to be investigated for the
limited purposes of this project. After reflecting on the various services and system interfaces,
the project team realized that the interface with the data providers would drive the design of the
data model because an ADMS is intended to archive data provided by these other systems. Thus,
Archived Data Management System Data Model – Final Report
vi
the analysis focused on those services that included interactions with data providers, Manage
Archive Configuration, Submit Data, and Retrieve Data.
The analysis of each of these interfaces focused on the sequence of data exchanges between the
systems and the structures of data passed at each step. The data model itself is then directly
derived from the structures passed during the data exchanges.
Complications
The reader should understand that the model proposed in this document is based on a
combination of existing standards. However, many of the interface standards for data providers
are in flux. In particular, the definition of “incident” is inconsistent among the various functional
areas of ITS (e.g., the traffic community versus the transit community versus the incident
management community). This document is based on the best attempt to be consistent with
these approaches while also considering current trends to harmonize the various standards
efforts.
The Data Model
The resulting data model contains the following three major components: the communications
interface model, the incident report model, and the traffic report model.
Communications Interface Model
The initial analysis efforts identified the overall structure/architecture required by the system.
The project team realized that the various users of ADMS systems were suggesting conflicting
arguments. Some users wanted to be able to log all information in real time, while other users
wanted to log selected information in real-time, and yet other users wanted to be able to
periodically dial-up a given system and download information that had been buffered over some
period.
Analysis of these varied needs, coupled with a review of the various designs that have been
proposed by other ITS Standards efforts, revealed a third logical architectural component, which
has been termed a Proxy. Both the Data Provider and the ADMS would log into the Proxy. The
Data Provider would transmit all information to this proxy as it became available. The ADMS
could, if desired, instruct the proxy to filter the information so that the Proxy would pass on only
information meeting certain criteria. Further, the Proxy would be able to buffer the data until the
ADMS was able to receive it (for example, at the end of the day when the ADMS calls in). This
process is depicted in Figure ES-1.
Archived Data Management System Data Model – Final Report
vii
Catalog
ADMS
Proxy
Data Provider
<<uses>>
Structured
Event
<<uses>>
Figure ES-1. Retrieve Data – View of Participating Classes Diagram
This design defines only the logical existence of a Proxy and does not specify where the Proxy
physically exists. It could be an internal part of a Data Provider, an internal part of an ADMS, a
separate physical system, or a combination (i.e., the design works with multiple layers of
proxies). This design provides considerable flexibility to implementing agencies in deciding
where equipment is located and in deciding how the equipment is funded.
In order for the ADMS to define filters, there must be some mechanism by which the ADMS can
determine what data are available from a Data Provider. The proposed model returns these data
in a Catalog object class. The ADMS then notifies the Proxy of the appropriate filters by
sending a series of strings (a string is a simple parameter and therefore is not explicitly shown in
this model).
Finally, the exchanges between the Data Provider and the ADMS would use a generic structure,
called a Structured Event, in order to pass data. The Structured Event is an abstract concept that
does not exist itself, but can be customized to represent any data structure of interest. This
project focused on two specific instances of Structured Event, the incident report and the traffic
report, which are defined below.
Incident Report
The Incident Report contains information relating to roadway incidents. Unfortunately, at
present there are very different views as to how incidents should be recorded, as reflected by
IEEE 1512, TMDD, and NTCIP standards. This model has been primarily based on the IEEE
1512 standard, as this seems to be the most mature and robust of the three. However, the reader
should realize that changes are likely in all three of these standards and these changes should be
considered before implementation. Future efforts will address the harmonization results.
Figures ES-2a and ES-2b describe how the Structured Event object class is specialized to provide
incident information. The open boxed arrow pointing from the Incident Report to the Structured
Archived Data Management System Data Model – Final Report
viii
Event indicates that an Incident Report is a type of (or specialization of) a Structured Event.
This means that it can be used anywhere a Structured Event is referenced, such as when a Data
Provider passes data to the ADMS via the Proxy. The Incident Report will include an eventID to
identify the Event with which it should be associated and may additionally contain other
associated pieces of information shown in the diagram. Over a period of time, the ADMS may
receive a series of Incident Reports that describe details of the Event as they change or become
known. Through this series of reports, the ADMS will be able to record a dynamic view of what
a given incident looks like. Alternatively, an ADMS may wish to subscribe only for final reports
about the incident, in which case the Proxy would filter out all but the final report and the ADMS
would record only the final view of the incident.
Structured Event
Incident Report
eve ntID : In teg er
1
1
1
0..1
0..*
Pedigree List
e ve nt : Strin g
e ve nt-des c : Stri ng
Traffic Plan
1
1
0 ..1
0..1
Veh icle Report
1
0 ..*
0..1
Traffic Impact
lane Con fig : Integ er
lane sBlo cked : Inte ge r
should ersBlo cke d : Inte ge r
Lanes Dire ctio nOfTravel-co de : e nu m
Lanes To talL anes-quan tity : In teg er
qual : Integ er
time : Integ er
Incident Information
Vehicle
ID : Integer
Typ : String
Dam : Stri ng
OccCnt : Integ er
VIN : String
Tag : String
Sta te : Inte ge r
Make : Integ er
Model : Intege r
Yea r : Inte ge r
Color : Integer
Desc : String
time : In teg er
q ua l : In teg er
in cidentID : Integer
The detail s here have been
omitted he re for cla ri ty. See
the subsequ ent diagram for
these deta ils.
Figure ES-2a. Incident Report Diagram, Part 1
Archived Data Management System Data Model – Final Report
ix
Incident Informat ion
Description
agencyReporting : Integer
incSubType : String
descripShortText : String
descripLongText : String
incidentCmdr : Integer
descripWitnesses : String
Description-text : String
DescriptionAuthor-text : String
NotesAndCommentsAuthor - text : String
0..1
1
1 1
1
0..*
Event Times
value : Integer
time : Integer
qual : Integer
0..1
Location
Type-code
0..* RelationToJunct ion-code
NonMotorist-code
LandmarkType-code
ExitRampEnd-identifier
Ent ranceRampBegin-identifier
Roadway-identifier
Severit y
priority : Integer
prioritizer : St ring
severit y : Int eger
fat alit yCnt : Int eger
injuryCnt : Int eger
1
1
1
1
1
0.. *
Cross Street
LRMS
OriginNodeOrder-code
OffsetType-code
NodeValence-quantity
0..*
Coordinates 0..*
Longitude
Altitude
Occurrence-number
End-text
End-identifier
Begin-text
Begin-identifier
0..*
0..*
Street
Roadway
End-number
Begin-number
Side-code
Name-text
1
0..*
Street Name
InfoFlag-c ode
IndexFlag-code
Figure ES-2b. Incident Report Diagram, Part 2
Traffic Report
The second specialization of the Structured Event object class investigated in this study was the
Traffic Report. This class describes roadway traffic conditions. Fortunately, the various ITS
Standards are much more stable in this area than in Incident Management (discussed above),
although the reader should recognize that the standards are still relatively new and in some cases
not officially balloted. Thus, the content of this model is also subject to change.
A Traffic Report is modeled as an aggregation of Roadway Link Reports and Roadway Detector
Reports. A Roadway Link Report describes the status of a Roadway Link at a specific point in
time, whereas a Roadway Detector Report describes the information obtained from a Roadway
Detector (also referred to as a Link Data Source) for a specific time. The data for the Roadway
Link are typically derived from one or more detectors on that link, and the Data Provider may
choose to summarize these data in any way it sees fit. Of course, for each report, there is also an
associated definition of the link (or detector).
Archived Data Management System Data Model – Final Report
x
Vehicle
Class : Integer
Speed : Integer
Length : Integer
FrontOv erhang : Integer
RearOv erhang : Integer
Wheelbase : Integer
Clearance : Integer
Height : Integer
Width : Integer
Gap : Integer
Headway : Integer
GrossWeight : Integer
SeqNum : Integer
StatusFlag : Integer
Acceleration : Integer
dcmNumVehicleIDs : Integer
dcmVehicleID : Integer
dcmVehicleTimeTag100 : Integer
...
NumAxles : Integer
Structured Ev ent
Traf f ic Report
1
1
Axle
Number : Integer
Width : Integer
TireCount : Integer
TireTrack : Integer
Lef tWheelWeight : Integer
RightWheelWeight : Integer
Weight : Integer
WeightViolationCode : Integer
. ..
+leadingAxle
0..*
+trailingAxle
0..*
Roa dway Li nk Repo rt
Roadway Detector Report
timestamp
LinkLanesOpen
LinkDensity
LinkLev elOf Serv ice
LinkRestrictions
LinkSurf aceCondition
LinkPriority
LinkDelay
LinkOv ersaturatedFlag
LinkSpeed
LinkStatus
LinkOccupancy Percent
LinkTrav elTime
collectionPeriod
0..*
v ol ume
occu pa ncy Perc enta ge
spee d
sm oo thed Volume
sm oo thed Occ upanc y
sm oo thed Spee d
collect io nPeri od
endTim e : Int eg er
S tatus : In tege r
0..*
WIM Measurement
weight
AxleGap
spac in g
0..*
0..*
1
LRMS
1
Roadway Link
LinkID
+associatedLink
Link Data Source
+detectors0..*
0..*
1
0. .*
1
OriginNodeOrder-code
Of f setTy pe-code
0... NodeValence-quantity
0..*
0..*
0..*
Parameter
Rea di ng
v al ue
+reading
0..*
+parameter name
def inition
1 units
Roadway Detector
DetectorID
ty pe
Figure ES-3. Traffic Reports Diagram
Archived Data Management System Data Model – Final Report
xi
Compatibility Analysis
The data presented in this document are 100% compatible with existing ITS standards, with the
exception of four new data elements. We are proposing the addition of these new data elements
in order to provide a standardized way for an archive to store non-standardized data. The new
data elements are:

Parameter
- name
- definition
- units

Reading
- value
Future Directions
This project has resulted in the production of the first draft of a data model for ADMS purposes.
However, several issues are still outstanding at the end of this project as described below.
Need to Refine Model
This project produced the first reviewed draft of the ADMS Data Model. This draft reflects user
review and comment; however, a proper systems engineering process requires an iterative
approach that considers all aspects of the system. Thus, while this process has considered the
most critical interface that impacts the design of the model, it has not fully considered other
interfaces that also may impact the model in less pronounced ways. For example, there was a
defined user need to aggregate older data so that historic information can be stored more
efficiently; however, since this did not directly involve an interface with the Data Provider, its
impact on the data model was not fully considered.
Likewise, the need for a Proxy was not fully reflected back into the full documentation. The
existence of this additional architectural component should be reflected back into the initial
levels of the analysis and applied to all aspects of the analysis in order to ensure a consistent
design. However, this was not seen to directly impact the limited goals of this project (i.e.,
producing an initial data model) and thus was not performed as a part of this project.
Need to Harmonize Data
As mentioned previously, the data model represents the best attempt made to reflect the existing
standards and current trends to harmonize these standards. However, it is inevitable that even
the best efforts to predict the future will not be 100 percent compatible with the final result.
Thus, once these harmonization issues are more completely resolved, the model will need to be
updated.
Archived Data Management System Data Model – Final Report
xii
Need to Coordinate Model with Message Set Efforts
This project was intended only to develop the data model for the data and does not define the
message structures required to ensure interoperable design. For example, the existence of a
Roadway Link Report has been defined as well as the association between the report and the
existence of the Roadway Link itself. However, exactly how the information about the Roadway
Link is transferred between the systems or what data elements in the model are mandatory for
transmission versus optional remains to be determined. In order to build interoperable systems,
these additional details must be defined.
Likewise, the concept that a Data Provider must provide a catalog of data for which an ADMS
can subscribe has been decided; however, the precise values that may be used for this catalog
have not been identified.
Need to Extend Model
Finally, this model has only scratched the surface of data that an ADMS may wish to archive.
There is a great deal of other information stored by data providers that an ADMS may wish to
record, such as any data describing the status of virtually any field device. At some point, the
model should be extended to reflect this more complete set of data.
Conclusions
This project has produced an initial data model for the ADMS effort in an attempt to promote
further discussion and progress towards achieving interoperable systems; however, additional
work remains before interoperability can be realized.
Archived Data Management System Data Model – Final Report
xiii
CHAPTER 1: INTRODUCTION
1.1
Background
Data modeling is a method used to define and analyze data requirements needed to support the
business functions of an enterprise. These data requirements are recorded as a conceptual data
model with associated data definitions. Data modeling defines the relationships between data
elements and structures. The purpose of data modeling is to provide a framework for data
integration and interoperability.
Archived Data Management System (ADMS) users have a particular need to understand the
structures and relationships of data concepts/elements from intelligent transportation systems
(ITS) because ADMS users access and combine data from multiple sources (both ITS and nonITS). An ADMS data model will help users get the most from ITS-generated data as well as
provide a basis for harmonization of similar data elements from different sources. Since there is
no overall ITS data model, this effort will produce a high-level data model suitable for ADMS
developers and users.
A high-level data model for ADMS is a generic data model that is more detailed than the
National ITS Architecture and provides developers of systems and standards with a starting point
for ADMS system design. Such a data model would promote interoperability and harmonization
of ADMS with other parts of ITS.
This work plan presents an overview of the scope and objectives of the Archived Data
Management System (ADMS) Data Model project, summarizes discussions from the expert
panel meeting, provides a commentary based on the expert discussions, and outlines the
approach for the development of the data model. The purpose of this work plan is to help the
COTR, project team, and expert panel address issues about the scope and approach arising from
the expert panel meeting. It is important that all parties have a clear understanding of and
agreement on the project scope, approach, and expectations. Consensus on these issues is critical
to the successful conduct of the project as well as the usefulness of the outputs from the project.
1.2
Objectives and Scope
The objectives of this project are to:

Develop a high-level data model for ADMS that covers the key data concepts and
relationships used in the Travel and Traffic Management user service bundle, and

Use this model to show how key data concepts from the systems and services within the
scope can be made comparable among themselves.
Archived Data Management System Data Model – Final Report
1
The ADMS data model must be consistent with the National ITS Architecture. This project will
focus on the archiving of data flows in the Travel and Traffic Management user service bundle
(e.g., Advanced Traveler Information Systems and Advanced Traffic Management Systems),
including the data needed for interfacing with other ADMS, public transportation management,
commercial vehicle electronic clearance, and traffic monitoring systems for transportation
planning purposes. The data model is expected to facilitate communication, sharing, and
archiving of data that spans different systems. The focus of the data model is on travel and
traffic management because this user service requires more data sharing than other services.
1.3
Organization of Report
The remainder of this report is divided into three chapters and three appendices:
Chapter 2 presents a literature review addressing ADUS and ADMS, ADUS Standards, and
concepts applicable to all data modeling as well as those specific to ADMS.
Chapter 3 provides the details of the data model, including descriptions of the operations and key
services of ADMS. The interaction specifications and service designs are clarified, and a
thorough listing of message exchanges by the systems and services are defined. The significance
of each of the specific classes, data elements, and methods are also clarified.
Finally, the appendices provide supplementary information about ADMS services. Appendix A
details the Manage Archive Configuration service, Appendix B discusses the Retrieve Data
service, and Appendix C concludes the document with information about the Submit Data
service.
Archived Data Management System Data Model – Final Report
2
CHAPTER 2: LITERATURE REVIEW
2.1
Introduction
A key feature of ITS is the ability to collect and use transportation information to improve the
overall system performance. ITS applications can generate vast amounts of data that are used in
managing system operations, which are also very valuable for other applications. For example,
real-time traffic data from roadway sensors and incident management centers can, in addition to
traffic operations, provide a valuable tool for planning purposes. The need to increase the
capabilities of ITS systems to include the archiving and use of real-time data is recognized [1].
The ITS Archiving 5-year Program Description report [1] identified 14 stakeholder groups as
having an interest in the use of data generated by ITS. Archived ITS data can not only replace or
supplement existing data sources but also can provide new avenues for planning and system
analysis. The continuous nature coupled with data aggregation in small intervals of time will
help in providing greater resolution and reducing sampling errors. Recognizing the need for
supporting the archival of real-time ITS data, U.S DOT revised the National ITS Architecture [2]
to include functions necessary to archive, store, and distribute these data. This goal was
achieved by adding a User Service to the existing User Services (Archived Data User Service),
the equipment package – (Archived Data Management System), and the corresponding
relationships between the other elements of the National Architecture.
Currently, various agencies around the country are in various stages of development of their
archive data management systems. Turner, 1999 [3] provides a comprehensive review of
existing applications of archived traffic data. The ADUS 5-year Program Description report [1]
has also identified concerns regarding implementations of archived data systems. Some of the
concerns include the following:






Guidance on system design of archived data systems
Data quality
Data standards. How can ITS data definitions be reconciled with traditional data
counterparts? What metadata is required? Who is responsible for collecting or assigning
the data? How can conflicts between data elements be resolved?
Data management. What ITS data should be archived and at what level of aggregation?
What types of analysis techniques are best suited for these systems?
System procurement and implementation process
Integration of ITS equipment with non-ITS data collection systems
To further encourage the use of archived ITS data, FHWA has begun work on developing the
standards for ADUS. The Strategic Plan for the Development of the ADUS Standards [4]
provides more direction on the proposed approach to identify and develop the required standards.
The strategic plan also lists the required elements of ADUS standards, including ADUS interface
identification, ADUS data dictionaries, ADUS metadata, data transfer protocols and message
sets, and standards practices.
Archived Data Management System Data Model – Final Report
3
An unambiguous definition of data elements or a data registry is required so that data elements
can be exchanged over selected protocols. The data dictionaries specified in the standards
development process help provide a uniform definition of data elements but fall short of
providing detailed information on relationships between data elements. The Center-to-Center
Working group of the National Transportation Communications for ITS Protocol effort has
suggested that the national data registry should include a data model. This requirement becomes
a necessity for center-to-center data exchanges using certain protocols. Section 2.4 deals with
these issues and the general data modeling process in further detail.
As there is no overall data model for all the subsystems defined in the National Architecture, this
effort is intended to develop a high-level data model for ADMS with a focus on data from travel
and traffic management user service bundle(s).
2.2 Archived Data User Service and
Archived Data Management System
The literature review is directed at providing a comprehensive documentation of existing
information on data models, archived data management systems, requirements, and standards.
This section describes the purpose of ADUS and ADMS within the National Architecture
framework.
2.2.1 National ITS Architecture
The National Architecture provides a common structure for the design of ITS. The architecture
defines the functions (for example, gather traffic information or request a route) that must be
performed to implement a given user service, the physical entities or subsystems where these
functions reside (for example, the roadside or the vehicle), the interfaces/information flows
between the physical subsystems, and the communication requirements for the information flows
(for example, wireline or wireless).
2.2.2 ADUS and ADMS
ADUS is the most recent addition to the list of User Services in the National Architecture. Table
2-1 shows the stakeholders who could use ITS data and the sample applications of these data
elements [1]. The National Architecture identifies the sources of these data elements, the logical
data flows from the sources to the archives, functions required for archiving, different market
packages and ways to implement ADUS, and potential users and issues.
Archived Data Management System Data Model – Final Report
4
Table 2-1. Stakeholders for Archived ITS Data
(Source: ITS Data Archiving – 5 Year Program Description, March 2000)
Stakeholder
Group
Primary Transportation-Related
Functions
MPO and state
transportation
planners
Identifying multimodal passenger
transportation improvements (long- and
short-range); congestion management;
air quality planning; develop and
maintain forecasting and simulation
models
Traffic
management
operators
Day-to-day operations of deployed ITS
(e.g., Traffic Management Centers,
Incident Management Programs)
Transit
operators
Day-to-day transit operations and shortrange planning: scheduling, route
delineation, fare pricing, vehicle
maintenance; transit management
systems; evaluation and planning
Air quality
analysts
Regional air quality monitoring;
transportation plan conformity with air
quality standards and goals
Planning for intermodal freight transfer
and port facilities
MPO/state
freight and
intermodal
planners
Safety
planners and
administrators
Identifying countermeasures for general
safety problems or hotspots
Archived Data Management System Data Model – Final Report
Example Applications
• Congestion monitoring
• Link speeds and truck percents for travel
demand forecasting and air quality
models
• Macroscopic traffic simulation
• Parking utilization and facility planning
• High occupancy vehicle, paratransit, and
multimodal demand estimation
• Congestion pricing policy
• Pre-planned control strategies (ramp
metering and signal timing)
• Highway capacity analysis
• Saturation flow rate determination
• Microscopic traffic simulation
- Historical
- Short-term prediction of traffic
conditions
• Dynamic traffic assignment
• Incident management
• Congestion pricing operations
• Capital planning and budgeting
• Corridor analysis planning
• Financial planning
• Maintenance planning
• Market research
• Operations/service planning (routes and
fares)
• Performance analysis planning
• Strategic/business planning
• Emission rate modeling
• Urban airshed modeling
• Truck flow patterns (demand by origins
and destinations)
• Hazardous materials and other
commodity flow patterns
• Safety reviews of proposed projects
• High crash-rate location analysis
• Generalized safety relationships for
vehicle and highway design
• Countermeasure effectiveness (specific
geometric and vehicle strategies)
• Safety policy effectiveness
5
Table 2-1. Stakeholders for Archived ITS Data (Continued)
(Source: ITS Data Archiving – 5 Year Program Description, March 2000)
Stakeholder
Group
Primary Transportation-Related
Functions
Construction
and
maintenance
personnel
Planning for the rehabilitation and
replacement of pavements, bridges, and
roadside appurtenances; scheduling of
maintenance activities
Commercial
vehicle
enforcement
personnel
Accident investigations; enforcement of
commercial vehicle regulations
Transportation
system
monitoring
personnel
Data collection related to system
conditions and performance
Land use
regulation and
growth
management
planners
Transportation
researchers
Development and monitoring of
ordinances related to land development
Private sector
users
Federal
government
Example Applications
• Pavement design (loadings based on
Equivalent Standard Axle Loads
[ESALs])
• Bridge design (loadings from the “bridge
formula”)
• Pavement and bridge performance
models
• Hazardous materials response and
enforcement
• Congestion management
• Intermodal access
• Truck route designation and
maintenance
• Truck safety mitigation
• Economic development
• Provide data for other stakeholders:
• Traffic counts and travel times for
planners (Annual Average Daily Traffic
[AADT], K- and D-factor estimation;
temporal distributions)
• Truck weights for maintenance
personnel
• Performance metrics for administrators
• Zoning regulations
• Comprehensive plan development
• Impact fees
• Taxation policies
• Car-following and traffic flow theory
Development of forecasting and
development
simulation models and other analytic
• Urban travel activity analysis
methods; improvements in data
collection practices
Provision of traffic condition data and route guidance (Information Service
Providers); commercial trip planning to avoid congestion (carriers)
Maintain national databases related to
• Highway Performance Monitoring
traffic operations, safety, transit, and
System
freight/CVO
• Fatal Accident Reporting System
• National Transit Database
Archived Data Management System Data Model – Final Report
6
The user service requirements can then be broken down into process specifications and data
flows for the logical architecture. For example, the ADUS requirement “ … shall be capable of
collecting user-selected data” (National Architecture User Service requirement # 7.1.2.2) would
be provided by the following process specifications: Get Archive Data (Pspec # 8.1), Manage
Archive Data Administrator Interface (Pspec # 8.3), Process On Demand Archive Requests
(Pspec # 8.7). Each of these process specifications is then broken down into various input/output
data flows.
ADMS is the physical architecture complement of the user services requirements and data flows.
ADMS is termed a “center” subsystem. A center subsystem provides 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.
As specified in the National Architecture, the ADMS collects, archives, manages, and distributes
data generated from ITS sources for use in transportation administration, policy evaluation,
safety, planning, performance monitoring, program assessment, operations, and research
applications. The data received are formatted, and then tagged with attributes that define the
data source, conditions under which they were collected, data transformations, and other
information (i.e., metadata) necessary to interpret the data. The subsystem can fuse ITS
generated data with data from non-ITS sources and other archives to generate information
products utilizing data from multiple functional areas, modes, and jurisdictions. The subsystem
prepares data products that can serve as inputs to federal, state, and local data reporting systems.
This subsystem may be implemented in many different ways. It may reside within an
operational center and provide focused access to a particular agency's data archives.
Alternatively, it may operate as a distinct center that collects data from multiple agencies and
sources to provide a general data warehouse service for a region.
The National Architecture identifies three market packages which address the needs of ADMS –
ITS Data Mart (Figure 2-1), ITS Data Warehouse (Figure 2-2), and ITS Virtual Data Warehouse
(Figure 2-3). These market packages connect several different subsystems, equipment packages,
and terminators that provide the desired service. The market packages also identify the data
communications between different subsystems (architecture flows).
Archived Data Management System Data Model – Final Report
7
Figure 2-1. ITS Data Mart Market Package: National ITS Architecture, available at
www.iteris.com/itsarch (as of March 2001)
Figure 2-2. ITS Data Warehouse Market Package: National ITS Architecture,
available at www.iteris.com/itsarch (as of March 2001)
Archived Data Management System Data Model – Final Report
8
Figure 2-3. ITS Virtual Data Warehouse Market Package: National ITS
Architecture, available at www.iteris.com/itsarch (as of March 2001)
The market packages and the data flow diagrams provide information on the exchange of
information to and from the archived data system. The standards development process is
intended to provide a common data dictionary, and to standardize the data exchanges and the
communication protocols for doing so.
2.3
ADUS Standards
2.3.1 ITS Standards Development
Standards development is of interest to nearly all organizations involved with the deployment of
ITS. It is anticipated that product developers, communication providers, and private service
providers will play an equal role in standards activities with local, regional, state, and federal
public infrastructure agencies. The National Architecture identified 13 key standard areas that
are relatively independent. Most of these ITS standards relate to how the various ITS
subsystems interoperate through the unambiguous interchange of data. The Data Modeling
White Paper [5] broadly classifies ITS standards into one of the following areas:




Data Dictionaries
Message Sets
Protocols
Profiles
Archived Data Management System Data Model – Final Report
9
Data Dictionaries – Data dictionaries document the precise meaning of the each of the data
elements involved. IEEE has defined a standard for data dictionaries for ITS (IEEE 1489-1999)
[6]. It provides support not only to the definition of data elements but also to the meta-data that
characterize them. Any data dictionary developed for ITS must conform to this standard. This
standard defines three basic levels of data dictionaries:



Application Data Dictionaries – These dictionaries help in manipulating and using data
elements in individual ITS systems.
Functional Area Data Dictionaries – These dictionaries provide nationally standardized
definitions of data elements within a functional area of ITS; these definitions then feed
the development of a national data registry. Examples include the Traffic Management
data dictionary and the Advanced Public Transportation Systems Data Dictionary.
Data Registry – This is a single composite data dictionary consisting of all those terms
standardized by functional area dictionaries, with additional details provided for each
data element. This registry is envisioned as the ultimate reference for data element
definitions within the industry and is designed to help the unambiguous interchange and
reuse of data and data concepts among the ITS subsystems and application systems. As
functional area dictionaries are developed, they are entered into the data registry. If
similar elements or concepts are submitted from different functional areas, any
differences need to be resolved by a consensus process.
Message Sets – A message set defines how data elements can be combined to exchange
information between two system components. This is achieved by developing a standard
message set template. IEEE has defined a trial-standard for message set template documentation
(IEEE 1488-2000) [7]. However, there has not been a consensus on how these message sets
relate to protocols, partly because different protocol stacks impose different requirements and
restrictions upon how the messages operate.
Protocols – A communications protocol is a set of rules for how messages are coded and
transmitted between electronic devices. The equipment at each end of a data transmission must
use the same protocol to communicate successfully. To allow integration projects to mix
equipment and software from different sources in the same system and to communicate between
adjacent agencies, the National Transportation Communications for ITS Protocol (NTCIP) was
tasked with providing common protocol standards that can be used by all vendors and system
developers to help overcome these differences.
2.3.2 ADUS Standards Development
The specific objectives of the ADUS standards development process have been identified in the
Strategic Plan for the Development of ADUS Standards, as follows [4]:


Coordinate with other ITS data dictionary efforts, either planned or under development,
that are relevant to ADUS
Help to reconcile differences between the data definitions in the pre-existing ITS data
dictionaries and those of ADUS stakeholders
Archived Data Management System Data Model – Final Report
10





Outline standards that will define and promote the interfaces necessary to implement
ADUS in the field
Ensure consistent deployments of ADUS throughout the country
Facilitate the interchange of data between ITS and non-ITS information systems
Eliminate duplicative data collection and storage
Enhance the usefulness of archived ITS data to end users by providing consistent data
definitions, documentation of data collection and processing activities, and efficient data
management techniques
ADUS standards development focuses on specifying the ADUS data dictionary, identifying and
standardizing metadata and its attributes, message sets, data transfer protocols for ADMS, and
standard practices.
ADUS Data Dictionary and Metadata – As in the national data dictionaries, this dictionary
provides unique identification and description of the data elements involved with this user
service. An important point to note is that the development of this data dictionary has to take a
more collaborative approach than the other functional area dictionaries. This is because most of
the data in the ADUS dictionary will be provided by other functional areas and specified in the
respective functional area dictionaries. In addition, data definitions must be created for
transformations of data like aggregation, conversion, and analysis. Also, a proper documentation
of the data collection and processing methodology is needed. Metadata is additional information
describing the data elements in the dictionary, such as size, source, data structures, linkages, and
relationships. Metadata is useful for retrieval and searching, summarizing, interpretation,
administration, and analysis.
ADMS Message Sets and Data Transfer Protocols – Standards will be developed to ensure
uniform communication formats to transfer data across interfaces. As mentioned earlier, centerto-center exchanges will use either CORBA or DATEX-ASN protocols. If a CORBA-based
communication protocol is selected, then a data model for ADMS becomes necessary.
2.4
Data Modeling
2.4.1 Data Modeling Concepts
A single national data registry is being developed to ensure interoperability of ITS subsystems
throughout the infrastructure and to specify the data elements uniquely. The Center-to-Center
working group of the NTCIP effort identified the need for a data model to complement the data
registry and established a Data Modeling Task Force. A data model is a conceptual
representation of the way information is stored. A data model can consist of a very detailed,
highly formal data storage system scheme or may be a very informal depiction of the way in
which data is stored. The Data Modeling White Paper [6] defined a data model as a diagram that
depicts the four key relationships as follows:
Archived Data Management System Data Model – Final Report
11




It identifies the properties of each entity (For example, Length is a property of the LINK
entity type.)
It identifies inheritance between entities (For example, Truck is a special type of the
VEHICLE entity. All VEHICLE attributes exist in a Truck but Truck has some other
attributes.)
It identifies containment by value (For example, a LANE is an entity [with attributes like
width, type] which is a component part of LINK and is dependent on LINK.)
It identifies containment by reference (For example, Starting NODE is a property of a
LINK, however NODE exists independently of LINK.)
These relationships are presented in Unified Modeling Language (UML) diagrams. UML is used
in the specifying, visualizing, constructing, and documenting the artifacts of software systems, as
well as business modeling and other non-software systems. Various UML diagrams are used for
modeling, including [8]:
Structural Diagrams include the Class Diagram, Object Diagram, Component Diagram, and
Deployment Diagram.
Behavior Diagrams include the Use Case Diagram (used by some methodologies during
requirements gathering), Sequence Diagram, Activity Diagram, Collaboration Diagram, and
State chart Diagram.
Model Management Diagrams include Packages, Subsystems, and Models. These diagrams
provide multiple perspectives of the system under analysis or development. It is to be noted that
UML does not support Data Flow Diagrams (DFD) because DFDs do not fit cleanly into the
object-oriented paradigm. Activity Diagrams and collaboration diagrams accomplish much of
what is needed from DFDs.
The need for a data model is partially dependent on the protocols, which may be used to
exchange the data. CORBA is a data model that provides a valuable tool for describing the
relationships between data.
2.4.2 ADMS Data Modeling
ADMS users have a particular need to understand the structures and the relationships of data
concepts/elements from ITS since they access and combine data from multiple sources. The
ADMS data model will provide a basis for harmonization of similar data elements from different
sources. The data model is a generic data model that is more detailed than the National ITS
Architecture and provides developers of systems and standards a starting point for ADMS
systems design.
Data models are a simplification of reality and are a central part of all activities that lead up to
the deployment of good software. Data models help to visualize a system, specify the behavior
of a system, provide a template for constructing a system, and document decisions made.
Alternative data modeling choices include an object-oriented approach, using an object model, or
the traditional relational approach, which uses a variant of the Entity-Relationship (ER) model.
Archived Data Management System Data Model – Final Report
12
An object-oriented approach will be used in developing the ADMS data model. Some of the
benefits of using an object model approach include:

Natural Description: the components representing complex phenomena are easily
described as objects with associated operations and functionality.

Flexibility: an object data model is adaptable to organizations in a particular field and
is adaptable across many technologies. This flexibility is provided by the richer
modeling constructs and concepts as inheritance and aggregation found in objectoriented technology.

Reuse of Other Work: Elements of other research can be incorporated more easily
when using an object model.
The Unified Modeling Language (UML), an object-oriented approach, will be used in
developing the data model. This is an industry-accepted, object-oriented modeling notation. The
following are the object modeling concepts:

Objects and Classes – An object class represents a group of objects with common
operations, attributes, and relationships. An object is a specific instance of a class.
Objects are typically nouns in the problem statement document. Each object can have
attributes and operations. An attribute is a data value held by objects in a class. An
operation is a function that may be applied to or by objects in a class.

Using UML notation, a class is represented by a box that may have four sections. The
sections contain, from top to bottom, class name, list of attributes, list of operations, and
list of responsibilities (i.e., a text note on the behavior of the class).

Associations/Relationship – An association (i.e., “relationship” in this report) is a
structural relationship that specifies that object classes of instances are connected to other
objects and are indicated by single lines connecting object / class boxes. “References” is
the name of the association (i.e., relationship) connecting the point event object and the
traversal reference point object.
An association that has class-like properties, such as attributes, operations, and other
associations are designated as an “association class.” An association class is shown as a
class symbol attached by a dashed line to an association. The association class
“represents” between line and anchor section objects and has “from position” and “to
position” attributes.
Multiplicity specifies how many instances of one class may relate to a single instance of
an associated class. A multiplicity specification is shown as a text string of integer
intervals in the format: lower bound. . upper-bound.

Aggregation – Aggregation is a special type of relationship where objects representing
the components of something are associated with an object representing the entire
assembly. Aggregation is an “a-part-of” or “has-a” relationship, drawn like a
relationship, except a small diamond indicates the assembly end of the relationship.
Archived Data Management System Data Model – Final Report
13

Generalization /Inheritance – Generalization is the relationship between a more general
class, called a superclass, and one or more specific versions of that class, known as
subclasses. Generalization has been called an “is-a” relationship since each instance of a
subclass is an instance of the superclass as well.
Figure 2-4 outlines the systems engineering process for data modeling. This process consists of
four major steps, as described below:
The first step defines the concept of operations and involves the following:
-
Defines how the system will be used
Focuses on inputs and outputs
Defines high level system entities
Defines high level interfaces
Develop concept
of operations
Develop functional
1.0
REQUIREMENTS
Develop dialogues per
functional requirement
Define data and
relationships
Figure 2-4. Data Modeling Process

The second step develops the functional requirements associated with each use of the
system, which may include:
-
Performance requirements
Pre-conditions
Post-conditions
Data quality requirements
Archived Data Management System Data Model – Final Report
14

The third step develops the dialogues where the messages are defined, which includes:
-
Logical structures that must be exchanged
Sequence of data exchanges
Branching statements
Entities that must be linked together
Links are provided by associations
The fourth step defines the data and relationships. Each piece of information within a message is
called a data element and each data element must be formally defined. Also, each data element
must be accessible by the entity sending the message. Access is provided by associations.
This project focuses on developing a data model that covers the key data concepts and
relationships from the travel and traffic management user service bundle only. Chapter 3 of this
report describes the development of the data model.
Archived Data Management System Data Model – Final Report
15
CHAPTER 3: DATA MODEL
3.1
Introduction
3.1.1 General
Much of the data generated by intelligent transportation systems (ITS) can be of great value
beyond their immediate use in real-time situations, such as reacting to an incident. Performance
monitoring, near-term and long-term planning and analysis, and many other applications can
make use of this information. Accordingly, the Archived Data User Service (ADUS) was added
to the National ITS Architecture, and a federal program to promote ITS data archiving was
instituted.
This document defines the requirements for an Archived Data Management System (ADMS) as
derived from the requirements contained in the National ITS Architecture. Reformatting of these
requirements has been performed in order to more clearly define the key actors (entities that
interact with the system), how the system is used, and to identify which actors use the ADMS in
which ways. These associations are then categorized as: (1) an implementation-specific
interface that is not subject to standardization, (2) a critical association that should be
investigated in the first phase of the effort to produce an Archived Data Model, or (3) an
association that may be the subject of a future effort.
The critical interfaces that have been identified to date are those that deal with retrieving
information from a data provider, such as a Traffic Management Center, an Incident
Management Center, or one of the other center subsystems of the National ITS Architecture.
Specifically, in order to follow the concepts of iterative development, the scope of this initial
effort was limited to retrieving information about traffic incidents and the state of the traffic
network (e.g., volume, speed, and occupancy).
When considering how this interface works, it is important to consider how these systems store
and handle the data so that the ADMS will be able to store this information with a minimal
amount of manipulation prior to archiving. Nonetheless, the interface had to be designed to
support the variety of systems that are likely to be deployed; as such, they should be designed in
a modular fashion. For example, some systems may provide detailed information about average
speed (e.g., the averaging method, the number of vehicles included in the average), while other
systems may only provide the top-level information (i.e., the average speed itself). The interface
had to be designed to allow the variability among implementations while also allowing for the
more detailed features.
The design also had to consider that some of the information covered by this interface may be of
a sensitive nature and must be kept private (i.e., the names of the parties involved in an accident).
As such, information exchanges should be protected by a security mechanism.
Archived Data Management System Data Model – Final Report
16
Existing implementations of archived data systems may not be able to support the new interfaces
outlined in this document without significant modifications. The ADMS solution described here
is intended for future design and has not been developed to support present systems.
This document investigates the critical associations required in the early phases of development.
It begins with a high-level view of the various participants and systems that were involved, and
then gradually works through to more granular levels of detail.
3.1.2 Actors
An actor is any external entity that will interact with an ADMS.
3.1.2.1
ADMS Administrator
An Archived Data Management System Administrator is responsible for typical administration
activities associated with large-scale databases, including managing the archive schema,
managing user access, managing the submission of data into the system, and monitoring system
performance and metrics.
3.1.2.2
Archived Data User
An Archived Data User is any user or system representing a user of archived data and/or reports
derived from archived data.
3.1.2.3
Data Provider
A Data Provider may be any of the center subsystems identified in the National ITS Architecture,
the roadside subsystem, or any of several terminators. It is distinguished from a Remote Archive
in that the data received from a Data Provider is archived into the local archive.
3.1.2.4
Government Reporting System
A Government Reporting System is any system that submits data or reports to a government data
system in order to monitor transportation statistics.
3.1.2.5
Remote Archive
A Remote Archive is any other ADMS to which this ADMS connects in order to exchange
information. Data retrieved from a Remote Archive is not archived locally.
Archived Data Management System Data Model – Final Report
17
3.1.2.6
Financial Institution
A Financial Institution represents the financial infrastructure from which payments can be
received for certain services offered by the ADMS.
3.1.3 Organization of Chapter
This chapter is presented in 5 major sections. The first section provides general information
about the data model.
Section 2 explains how the systems are expected to operate. The discussion of these operational
concepts leads to the identification of certain key services that must be provided by an ADMS.
Section 3 explicitly defines these services and how they interact with the various parties using
the systems. A context is provided for each service along with an overview of the process steps
necessary to fulfill the service.
Section 4 completes the definition of each service defined in Section 3. In some cases, a single
Section 4 solution may fulfill multiple Section 3 services.
Section 5 defines each specific class, data element, and method referenced in Section 4.
3.2
Concept of Operations
This document was developed using the Rational Unified Process by Jacobson, et al. [9]. This
approach to software engineering is widely accepted in the information technology industry
because it helps to identify and address risks early in the development process, resulting in
better-designed systems. The first stage in this process is to identify the ways in which the
system will be used. In the case of this document, this entails identifying the various ways in
which a data user may use an Archived Data Management System (ADMS) in order to fulfill
their duties.
This concept of operations provides the reader with:



A detailed description of the scope of this document
An explanation of how the ADMS is expected to fit into the larger context of an ITS
infrastructure
An understanding of the perspective of the document designers
This section is intended for all readers of the document, including:




Transportation operations managers
Transportation operations personnel
Archived data users
Transportation engineers
Archived Data Management System Data Model – Final Report
18



System integrators
ADMS developers
Conformance Testers
The first four categories of readers will find this section useful in order to understand how
ADMS services can be integrated into their systems. They will be able to become familiar with
each service covered by the document and determine how their existing ITS equipment will
integrate into the system.
The last three categories of readers will find this section useful in order to gain a more thorough
understanding as to why the more detailed requirements (as specified in later sections of this
document) exist.
3.2.1 Section Tutorial
Throughout this document, Unified Modeling Language (UML) diagrams are provided to more
concisely depict the services presented in the text of the document. UML is the primary
language for modeling, visualizing, and documenting software systems today. UML consists of
a variety of diagrammatic techniques in order to convey the requirements structure and
operational design in a relatively easy-to-understand format without losing important details.
Most importantly, the diagrams can be designed to depict only the information of interest,
thereby allowing the developers to illustrate a complex system through a series of relatively
simple diagrams. For these reasons, UML is being widely adopted by the ITS standards
community as the tool of choice.
However, it is recognized that a large portion of the intended audience of this document may not
have much experience in reading UML diagrams. As a result,


All of the information presented in the diagrams is also presented in the text of the
document, and
Each section of the document contains a tutorial section so that those unfamiliar with
UML are able to gain a better understanding of what the diagrams indicate.
As mentioned above, this section identifies the various ways in which archived data user may
use an ADMS in order to fulfill their duties. In UML terminology, each possible use of the
system is termed to be a use case. However, many people unfamiliar with UML find this term to
be confusing; thus for the purpose of clarity, the term service is used to refer to use cases. The
two terms are interchangeable within the scope of this document.
The services are presented from the perspective of the archived data user. They are written from
this perspective in order to ensure that the document captures all of the end-user requirements for
each end-user service that is identified. However, the reader should be aware that this document
is only concerned with the interface between the ADMS and the Data Provider; in order to fulfill
the end-user service, additional requirements may exist. Figure 3-1 indicates how these various
entities are connected.
Archived Data Management System Data Model – Final Report
19
Figure 3-1. Sample Physical Architecture for an ADMS
When designing a system, it is important to clearly define the system boundaries so that the
inputs and outputs of system data are well defined. In order to do this, the entities that provide
data to and/or accept data from ‘our system’ must be identified. An easy check to ensure that all
boundaries are defined would be achieved by envisioning a box around the subject system on a
diagram such as Figure 3-1 (in this case, the ADMS and the Data Provider). As mentioned
previously, this section is written from the perspective of the archived data user; thus, one
interface is between the archived data user and the ADMS. However, this is only one boundary
on the figure; the other boundary for this document is between the ADMS and the data providers.
More specifically, this system accepts data from various data providers and outputs data to the
archived data user.
In UML, any entity that inputs data into and/or accepts data from the system of interest is called
an actor and is represented as a stick figure in UML diagrams. This conversion is depicted in
Figure 3-2.
Archived Data Management System Data Model – Final Report
20
Figure 3-2. Identifying Actors on a System
Once the boundaries and actors are defined, the services provided by the system can then be
considered. In UML, each service provided by the system is indicated by a separate oval, as seen
in Figure 3-3. Solid lines are then drawn to indicate which actors are associated with which
services. Arrowheads on these lines indicate the direction in which requests and/or notices are
initiated; responses to these requests / notifications may then be returned and may be quite large
(for example, a response containing data is often larger than the request for data). A solid line
without an arrowhead, however, signifies that a request or notification can occur from either side
of the association. For example, System A subscribes for data from System B—this shows
directionality from A to B. System B then provides data to System A as they become
available—this is directionality from B to A. Thus, in this example, the association is depicted
without an arrow).
Archived Data Management System Data Model – Final Report
21
Figure 3-3. Sample Use Case Diagram for ADMS
In the above depiction, a service called Submit Data has been identified and a use case has been
created to represent this service. Additionally, the directionality of initiation has been specified
by placing arrowheads on the links between objects. Here, the Archived Data User (ADU)
initiates a request to the Submit Data service. The service then initiates a request to the Data
Provider. Each diagram in this document will be supplemented with descriptive text to better
explain concepts represented in UML notation.
For the purposes of this document, the standardizing of the communications interface between
the ADMS and the Data Provider will be the primary concern. A more detailed discussion of use
case diagrams can be found in Schneider and Winter’s guide [10].
3.2.2 Service Diagrams
3.2.2.1
Introduction
This section will provide a diagram for each of the three major types of services defined in this
document: login services, administrative services, and user services.
The definition of each actor is provided in Section 3.1.2. The context of each service is provided
after the presentation of each diagram in this section, and the full definitions of each service are
located in Section 3.3. Note that while some services are more completely defined, all identified
services are shown. This will provide the full system context and ensure traceability to the
National Architecture.
Archived Data Management System Data Model – Final Report
22
This specification does not include any details about system redundancy, data backup, or
reliability in general. However, in order for the ADMS to provide continued value, an
infrastructure must be created to address reliability concerns.
3.2.2.2
Service Descriptions
3.2.2.2.1
Login Service. This diagram depicts the Login service. ADMS
Administrators, Government Reporting Systems, Archived Data Users, and Remote Archives use
the Login service.
ADMS
Administrator
Government
Reporting System
Login
Archived Data User
Remote Archive
request.credentials()
Figure 3-4. Login Service Diagram
3.2.2.2.1.1 Login. The design of this service is based on providing the necessary
services to enable an ADMS user or administrator to gain appropriate access to the ADMS. The
Login service provides a security mechanism to ensure that only authorized parties can access
potentially sensitive data. When an ADU requests access, the Login service will validate the
user's credentials against a table of authorized users. If the ADU is successfully authenticated,
the user will be able to access appropriate functions. Otherwise, the user will be denied access to
Archived Data Management System Data Model – Final Report
23
the ADMS. Some data may exist in the public domain and may not require end-users to be
authenticated. Therefore, this service is optional.
3.2.2.2.2
Administrative Services. The following figure depicts the services
offered to the ADMS Administrator. These include Request Archive Metrics, Submit Data,
Retrieve Data, Manage Archive Configuration, and Manage Archive.
Request Archive Metrics
Subject
interfaces for this
document
Submit Data
ADMS
Administrator
Retrieve Data
Data Provider
<<include>>
Manage Archive Configuration
Manage Archive
Implementation
specific
user-interfaces
Figure 3-5. Administrative Services Diagram
3.2.2.2.2.1 Manage Archive. The design of this service is based on providing the
necessary services to enable an ADMS Administrator to manage archived data. An
Administrator may wish to delete records, optimize storage space, make back-up copies of the
data, or perform other managerial activities on the data. This service will retrieve the records
that should be managed based on filtering criteria provided by the ADMS Administrator. The
Administrator will then specify what actions should be performed on the data and this service
will carry out those functions.
Archived Data Management System Data Model – Final Report
24
This service will additionally provide the Administrator with basic database administrative
functions and the ability to manage security features. The Administrator may wish to modify
user access, change user passwords, add and/or delete records, etc. This service shall provide the
services necessary to support these functions.
3.2.2.2.2.2 Manage Archive Configuration. This service enables an ADMS
Administrator to manage importation of data into the archive. After requesting data catalogs, an
ADMS Administrator will decide what data to store in the ADMS for archival purposes. The
Administrator will work through this service to select a data provider and will then specify the
data subscription. This service will then present the Administrator with an array of configurable
variables for the data selection and the Administrator will specify the conditions for data
retrieval. This service is included as a part of the Retrieve Data service, which carries out the
task of subscribing to the data volumes.
However, providing data is also a dynamic system; the data offered by the system may change
over time. Whenever this occurs, the data provider shall notify the ADMS of the change and
may terminate or alter the subscription of data in order to reflect new limitations of available
data.
In order to access more complete data, a provider may wish to charge a fee. This service will
support the interchange of charges between ADMS users and data providers.
3.2.2.2.2.3 Request Archive Metrics. This service enables an ADMS Administrator
to request the status of an archive. An Administrator may have a number of processes pending,
such as requests to submit data or retrieve data. This service will query the ADMS to determine
the status of pending processes and will return the results to the Administrator. Other functions
this service performs include returning information to the ADMS Administrator about the state
of the archive itself -- data such as performance measurements and volume usage.
3.2.2.2.2.4 Retrieve Data. This service enables the ADMS to obtain data from
various data providers -- such as Traffic Management Centers and roadside devices -- for storage
in the ADMS for archival purposes. An ADMS Administrator will decide which data is
desirable for archival in the ADMS for future access and then initiate a subscription for the data.
The administrator will do this by configuring the parameters for data retrieval through the
Manage Archive Configuration service, which will in turn pass these variables to the Retrieve
Data service. Subsequently, the Retrieve Data service shall subscribe to appropriate data
providers to retrieve the specified data.
The data provider will validate the ADMS's credentials; therefore, the ADMS will return only
authorized data. Once the subscription has begun, the data provider will periodically contact the
ADMS and provide the subscribed data back to this service. The Retrieve Data service will then
perform appropriate quality checks on the data and format the data so that they are suitable,
according to the specifications received from the Manage Archive Configuration service.
Connections between the data providers and the ADMS may be transient (e.g., dial-up circuits).
The design of these services shall ensure that all requested data are eventually captured within
Archived Data Management System Data Model – Final Report
25
the ADMS, even if communications with the ADMS are unavailable when the data become
available.
3.2.2.2.2.4 Submit Data. This service enables an ADMS Administrator to request
data to be imported into the archive. An Administrator may determine that it is desirable to store
certain data in the ADMS for archival purposes. The Administrator will first request catalogs to
determine where the data are located and then request that certain data be stored in the ADMS.
This process occurs when the Administrator selects which data should be submitted and then this
service retrieves and processes the data. The service will retrieve only data that the
Administrator is authorized to access. The Submit Data service will perform quality checks on
the incoming data and then process the data to ensure that they are in the appropriate format for
the database. The service is complete once the data have been submitted to the archive, the
transaction has been logged and the user has been notified of the results.
3.2.2.2.3
User Services. The diagram below depicts the User services for the
ADMS. Some of the interfaces shown are implementation specific, while others will be defined
elsewhere.
Government
Reporting System
Request Government Report
Remote Archive
Request Catalog
Archived Data User
Request Data
Financial Inst itut ion
Other interfaces that should be
defined elsewhere. Presumably
they are all SQL interfaces, except
for the financial interface which will
likely be dictated by others.
Figure 3-6. User Services Diagram
Archived Data Management System Data Model – Final Report
26
3.2.2.2.3.1 Request Government Report. This service enables a government
system to obtain a properly formatted report. Federal, state and local governments will require
certain reports with statistical and other information. A government reporting system will access
the ADMS and submit a request for a government report in a specified format. This service will
then search for the requested data in the archive and return matches. The Request Government
Report service will return only data to which the system has access. The returned data will be in
a report formatted as specified by the government reporting system. This service will also
support the provision of reports to ADMS users as well.
3.2.2.2.3.2 Request Catalog. This service enables an ADMS user to retrieve
catalogs defining what data are stored by the ADMS. The ADU will use the catalogs to
determine what data are available and which to request. This service will validate the user's
credentials and return only catalogs for which the ADU is authorized to have access.
3.2.2.2.3.3 Request Data. This service enables an ADMS user to request data from
the archive. The ADU is not requesting data from remote data providers; rather, the ADU is
merely accessing the existing ADMS archive to obtain certain data.
3.3
Functional Requirements
This portion of the document defines the functional requirements related to each of the
previously identified services that may be offered by an ADMS.
This section is intended for most readers of the document, including:






Transportation operations personnel
Archived data users
Transportation engineers
System integrators
ADMS developers
Conformance testers
The intent of this section is to provide the complete, formal, and measurable requirements for
each identified service. These requirements are presented at a high-level in order to provide a
clear definition of what is required of the system without becoming mired in the technical details
of how these requirements are met.
3.3.1 Section Tutorial
Section 3.2 identified the various services that may be offered by an ADMS. This section
provides a fuller definition of each service by providing the typical flow of events associated
with the service. The definition of each service includes a detailed workflow structure, the
identification of any conditions that must be true prior to the service being available, the
identification of any conditions that are always true after the service is performed and that may
Archived Data Management System Data Model – Final Report
27
impact other services, and references to existing ITS architectures and standards. This section
does not require the use of any UML diagrams.
3.3.2 Service Requirements
3.3.2.1
Login Service Requirements
3.3.2.1.1
Login
3.3.2.1.1.1 Definition. The Login service allows users (both persons and systems) to
access the system while blocking access to unauthorized parties. Some data may exist in the
public domain and may not require end-users to be authenticated. Therefore, this service is
optional.
3.3.2.1.1.2
service:
1.
2.
3.
4.
5.
Flow of Events. The following represents the flow of events for login
The user will request access.
The ADMS shall prompt the user for credentials.
The user will enter unique credentials.
The ADMS shall validate user credentials against authentication database.
If the user is successfully authenticated, the ADMS shall allow access to the
appropriate functions for the user type; otherwise, if authentication fails, the ADMS
shall return an error to the user and request resubmission of credentials.
3.3.2.1.1.3
PreConditions. User account must exist.
3.3.2.1.1.4
PostConditions. The user must be logged into the system.
3.3.2.1.1.5
Architecture.
3.3.2.2
References. This service was not explicitly defined in the National ITS
Administrative Services Requirements
3.3.2.2.1
Manage Archive
3.3.2.2.1.1 Definition. The Manage Archive service allows the ADMS administrator
to manage data in the archive. This service shall support the aggregation of data by an
administrator; for example, an administrator may wish to periodically convert hourly data into
daily data in order to minimize the size requirements for older information. This service shall
also support deleting records and backing up data by an administrator.
Archived Data Management System Data Model – Final Report
28
3.3.2.2.1.2 Flow of Events. The following represents the flow of events for
administrative services:
1.
2.
3.
4.
5.
6.
7.
8.
9.
The administrator will initiate request to manage archive.
The ADMS shall prompt user for criteria to filter records.
The administrator will input search criteria.
The ADMS shall query the archive.
The ADMS shall display matches to Administrator.
The administrator will select data to manage.
The administrator will select actions to be performed on data.
The ADMS shall process the data accordingly.
The ADMS shall log the activity.
3.3.2.2.1.3
PreConditions. User must be logged into the system with Administrative
3.3.2.2.1.4
PostConditions. There are no postcondition requirements.
rights.
3.3.2.2.1.5 References. National ITS Architecture references include the following:
A portion of PSpec 8.2 - Manage Archive, a portion of 8.3 - Manage Archive Data Administrator
Interface, a portion of the “archive management request” architecture flow from the Archived
Data Administrator to the Archived Data Management Subsystem (ADMS) and a portion of the
“archive management data” architecture flow from the ADMS to the Archived Data
Administrator.
3.3.2.2.2
Manage Archive Configuration
3.3.2.2.2.1 Definition. The Manage Archive Configuration service allows the ADMS
administrator to control the retrieval of data from data providers. It supports the administration
of the process to import data into the archive, including requests for data products, catalogs,
formatting instructions, specifications for performing checks on the incoming data, quality
metrics, methods to apply to the data, and the parameters that govern any cleansing operations.
3.3.2.2.2.2 Flow of Events. The following represents the flow of events for
managing the archive configuration:
1.
2.
3.
4.
5.
6.
The ADMS Administrator initiates request to manage the configuration.
The ADMS shall display a list of data providers from which data can be retrieved.
The user will select the provider from which to retrieve data.
The ADMS shall contact the selected system in order to retrieve a data catalog.
The ADMS shall display the data catalog.
The user will select which data to retrieve from the data provider and the form in
which it is to be retrieved.
7. The ADMS shall update its configuration and alter the retrieve data function as
needed. If required by the provider, a fee may be assessed for this service. In this
Archived Data Management System Data Model – Final Report
29
case, this service will prompt the user for financial information and pass this
information to the provider.
8. The ADMS shall display the results of the operation to the user.
9. The ADMS shall log the activity.
3.3.2.2.2.3
PreConditions. User must be logged into the system with Administrative
3.3.2.2.2.4
PostConditions. There are no postcondition requirements.
rights.
3.3.2.2.2.5 References. National ITS Architecture references include the following:
A portion of PSpec 8.3. Manage Archive Data Administrator Interface, a portion of PSpec 8.2
Manage Archive, a portion of the “archive management request” architecture flow from the
Archived Data Administrator to the Archived Data Management Subsystem (ADMS) and a
portion of the “archive management data” architecture flow from the ADMS to the Archived
Data Administrator.
3.3.2.2.3
Request Archive Metrics
3.3.2.2.3.1 Definition. The Request Archive Metrics service allows the ADMS
administrator to request the status of the archive, including information related to the retrieval of
data and the requests for data.
3.3.2.2.3.2
archive metrics:
1.
2.
3.
4.
5.
6.
Flow of Events. The following represents the flow of events to request
User initiates request for archive metrics.
The ADMS shall display a list of metrics that it can return.
The user will select which metrics it would like to view.
The ADMS shall measure the requested processes.
The ADMS shall display the results of the operation to the user.
The ADMS shall log the activity.
3.3.2.2.3.3
PreConditions. User must be logged into the system with Administrative
3.3.2.2.3.4
PostConditions. There are no postcondition requirements.
rights.
3.3.2.2.3.5 References. National ITS Architecture references include the following:
A portion of PSpec 8.3. Manage Archive Data Administrator Interface, a portion of PSpec 8.2
Manage Archive, a portion of the “archive management request” architecture flow from the
Archived Data Administrator to the Archived Data Management Subsystem (ADMS) and a
portion of the “archive management data” architecture flow from the ADMS to the Archived
Data Administrator.
Archived Data Management System Data Model – Final Report
30
3.3.2.2.4
Retrieve Data
3.3.2.2.4.1 Definition. The Retrieve Data service shall collect data from various
management subsystems, roadside devices, and external sources for archival purposes. The data
retrieved by the service shall be determined by the configuration parameters set through the
Manage Archive Configuration services. Based on these parameters, it shall subscribe for data
from various data providers.
The returned data may include metadata along with the operational data to describe the
conditions under which the operational data were collected or any other information about the
operational data. When data are received this process shall perform quality checks such as range
validation or reformat the data as necessary to meet the archive schema. This process shall
execute methods on the incoming data such as cleansing, summarizations, aggregations, or
transformations applied to the data before they are stored in the archive in order to ensure that
archived data are stored in a common format according to the configuration parameters set
through the Manage Archive Configuration service. Any changes made to the data shall be
recorded in associated metadata attributes stored in the archive to assist in the reconstruction of
the original data if possible.
Any errors during this process shall be recorded in a system log.
3.3.2.2.4.2
retrieving data:
Flow of Events. The following represents the flow of events for
1. The ADMS shall monitor the archive configuration.
2. When directed by the configuration, the ADMS shall contact remote data providers in
order to request the selected data.
3. The remote data providers return to the ADMS the data requested by the system.
While the ADMS initiates the request, the bulk of the communication between the
ADMS and the data providers consist of the transmissions of the selected data back to
the ADMS.
4. The ADMS shall process this data so that it conforms to the database schema for the
archive and shall also perform quality checks to ensure bad data do not corrupt the
archive. Missing and suspect data shall be flagged in the database.
5. The ADMS shall store the processed data into the archive.
6. The ADMS shall log the activity.
3.3.2.2.4.3 PreConditions. The ADMS must be configured as to which data to
retrieve from which systems. The ADMS must be authorized to retrieve information from the
data provider for each specific type of information requested.
3.3.2.2.4.4
PostConditions. Data will be stored in the archive.
3.3.2.2.4.5 References. National ITS Architecture references include the following:
A portion PSpecs 8.1 Get Archive Data, a portion of PSpec and 8.9 Manage Roadside Data
Collection, a portion of the “traffic_management_archive_request” architecture flow from the
Archived Data Management System Data Model – Final Report
31
ADMS to the data providers, a and a portion of the “traffic_management_archive_request_data”
architecture flow from the data providers to the ADMS.
3.3.2.2.5
Submit Data
3.3.2.2.5.1 Definition. The Submit Data service allows the ADMS administrator to
request data to be imported into the archive.
3.3.2.2.5.2
submitting data:
Flow of Events. The following represents the flow of events for
1.
2.
3.
4.
5.
6.
7.
8.
Administrator initiates request to submit data.
The ADMS shall display a list of systems from which data can be retrieved.
The administrator will select the provider from which to retrieve data.
The ADMS shall contact the selected system in order to retrieve a data catalog.
The ADMS shall display the data catalog.
The administrator will select which data to submit from the data provider.
The ADMS shall retrieve the selected data.
The ADMS shall process this data so that it conforms to the database schema for the
archive and shall also perform quality checks to ensure bad data do not corrupt the
archive. Missing and suspect data shall be flagged in the database.
9. The ADMS shall store the information in the archive.
10. The ADMS shall display the results of the operation to the user.
11. The ADMS shall log the activity.
3.3.2.2.5.3
PreConditions. User must be logged into the system with Administrative
3.3.2.2.5.4
PostConditions. There are no postcondition requirements.
rights.
3.3.2.2.5.5 References. National ITS Architecture references include the following:
A portion of PSpec 8.7 Process On Demand Archive Requests, a portion of the
“fadu_on_demand_archive_request” architecture flow from the ADMS to the archive, and a
portion of the “tadu_on_demand_archive_request” architecture flow from the archive to the
ADMS.
3.3.2.3
User Services Requirements
3.3.2.3.1
Request Catalog
3.3.2.3.1.1 Definition. The Request Catalog service shall allow the user to request a
catalog of the analysis products available.
Archived Data Management System Data Model – Final Report
32
3.3.2.3.1.2 Flow of Events. The user's systems shall be able to request a catalog of
the data stored by the ADMS. Upon receipt, the ADMS will provide the requester with the
catalog.
3.3.2.3.1.3
PreConditions. User must be logged into the system with User rights.
3.3.2.3.1.4
PostConditions. There are no postcondition requirements.
3.3.2.3.1.5 References. National ITS Architecture references include the following:
A portion of PSpec 8.2 Manage Archive, a portion of PSpec 8.5 Process Archived Data User
System Requests, a portion of the “archive data product requests” architecture flow from the
Archived Data User Systems to the ADMS, and a portion of the “archive data products”
architecture flow from the ADMS to the Archived Data User Systems.
3.3.2.3.2
Request Data
3.3.2.3.2.1 Definition. This service allows an ADU to request archive data, including
optional analysis of this data, such as data mining, data fusion, summarizations, aggregations,
and recreation from archive data.
3.3.2.3.2.2 Flow of Events. The users’ systems shall request data from a display of
available data offered by the system, the system shall then retrieve the data from the archive,
and, if needed, from remote archives. When data and metadata are returned from the archive and
any optional analysis is performed, the system will check to determine if financial payment is
required. If so, the Financial Institution will be contacted to process payment. Once completed,
the results will be sent to the ADMS.
3.3.2.3.2.3 PreConditions. Data must exist in the archive. User must be logged into
the system with User rights.
3.3.2.3.2.4
PostConditions. There are no postcondition requirements.
3.3.2.3.2.5 References. National ITS Architecture references include the following:
A portion of PSpec 8.5 Process Archived Data User System Requests, a portion of & PSpec 8.6
Analyze Archive, a portion of the “archive data product requests” architecture flow from the
Archived Data User Systems to the ADMS, and a portion of the “archive data products”
architecture flow from the ADMS to the Archived Data User Systems.
3.3.2.3.3
Request Government Report
3.3.2.3.3.1 Definition. The Request Government Report service prepares data or
reports required by Federal, State, and/or local governments. These reports may be requested by
an end-user or by a government reporting system.
Archived Data Management System Data Model – Final Report
33
3.3.2.3.3.3
government report:
Flow of Events. The following represents the flow of data to request a
1. The Government Reporting System or an ADU initiates a request to retrieve a report.
2. The ADMS shall prompt the requester to specify what data to retrieve and in what
format.
3. The requester will select the data and specify the format of the report.
4. The ADMS shall search for data matches and will process results in the specified
format.
5. The ADMS shall deliver the report to the requester.
6. The ADMS shall log the activity.
3.3.2.3.3.3 PreConditions. Data must exist in the archive. User must be logged into
the system with User rights.
3.3.2.3.3.4
PostConditions. There are no postcondition requirements.
3.3.2.3.3.5 References. National ITS Architecture references include the following:
A portion of PSpec 8.8 Prepare Government Reporting Inputs, a portion of the
“tgrs_government_data_report_input” architecture flow from the ADMS to the Government
Reporting System (GRS), and a portion of the “fgrs_government_data_report_input” architecture
flow from the GRS to the ADMS.
3.4
Interaction Specification
This section describes how the ADMS services, which were identified in Section 3.2 and
formally defined in Section 3.3, are achieved.
This section provides the reader with the following:



A detailed description of service interactions
An explanation of messages exchanged by the systems
A thorough technical view of how the services are designed.
This section is intended for only a subset of potential readers, such as:



System integrators
ADMS developers
Conformance testers.
These readers will find this section useful in order to understand the details of how ADMS
services are achieved. They will be able to draw upon the specified design when considering the
integration of existing systems and ITS equipment with the ADMS.
Archived Data Management System Data Model – Final Report
34
3.4.1 Section Tutorial
This section of the document describes both the dynamic and static representation of the system
design. In order to fully and clearly describe the design of the system, an object-oriented
approach is adopted; however, this object-oriented design in no way imposes a requirement for
an object-oriented implementation. The diagrams shown within this document are solely
intended to show the details of the interface logic and static structures; the implementation may
follow an object-oriented or structured approach.
The dynamic view describes how the system works for a given service. It indicates the sequence
of events that occur in order to provide the specific service and is typically shown through a
sequence diagram. The various objects that participate in providing the service appear across the
top of the diagram. A solid message line with an arrowhead indicates an initiation of a request
from one object to another. A dashed-line with an arrowhead indicates a return value to a
request. Generally, the objects that initiate requests are on the left of those receiving the request;
requests that travel right-to-left generally indicate a return value (dashed-line) or a function call
back (solid-line). The flow of events can be followed by looking at the message lines between
objects as they move across and down the page.
: ADMS Login
Service
: Archived Data
User
: User
: Access
Control List
reques t_acc ess()
Repeat until
username found or
until end of list .
request_credentials()
// returns credentials
validat e_credent ials()
validat e( )
// user validated
// credentials validated
Figure 3-7. Sample Sequence Diagram for Login Service
Archived Data Management System Data Model – Final Report
35
Once the designer has produced a sequence diagram, one or more corresponding class diagrams
can be produced. A class diagram provides a static view of the relationships between key
entities (classes). However, the classes and relationships shown in such a diagram are only those
related to the subject service being discussed. They will include those classes that are included
in the sequence diagram and may also include classes that are exchanged as a part of the
messages that are exchanged. This diagram is commonly known as a view of participating
classes diagram. The purpose of this diagram is to describe how each of the logical software
components relates to one another in order to achieve the service and to clearly indicate the
associations among the related data.
User
Access Control List
Archived Data User
validate.credentials()
0.. *
0..*
1
username
password
validate()
request.credentials()
1
1
ADMS Login Service
request.access()
Figure 3-8. Sample VOPC Diagram for Login Service
The different object classes are represented by boxes that may list any applicable attributes
and/or operations that apply to the class. The top section of the box identifies the name of the
class. The middle section of the box, if present, indicates attributes (a.k.a. properties) of the class
(for example, password is an attribute of a User). The bottom section of the box, if present,
indicates functions offered by the class (e.g., the User Class can validate an incoming request
against the username and password stored as attributes). Lines between classes indicate that the
classes have a relationship. Arrowheads on the lines further define the relationship. A standard
arrowhead, such as the one on the relationship between the ADMS Login Service and the Access
Control List, indicates that the relationship has directionality. In this case the ADMS Login
Service can call the validate.credentials () function of Access Control List, but the ADMS
Control List is not allowed to call any function of the ADMS Login Service.
A diamond on the end of a line indicates aggregation. The class that has the diamond is the
whole; the other class represents a part. If the diamond is solid it indicates composition, which
means that the part may be owned only by one whole and when the whole is deleted, all of its
parts are automatically deleted. (For example, if the user deletes the Access Control List, all
Users are deleted as well.) However a part of an aggregate relationship can exist without the
whole or may be part to several wholes. At a university, for example, a Class would be
considered to be an aggregation of students. A student may be enrolled in several classes at once
and is not “deleted” if his class is cancelled.
Archived Data Management System Data Model – Final Report
36
A number at the end of a relationship line indicates the number of those classes that may exist in
relation to the other class. An asterisk (*) indicates an infinite number. A range of values may
be indicated in the format of a number followed by two periods followed by another number.
Thus, in this example, an Access Control List may be associated with zero (0) to an infinite
number of Users.
A more detailed discussion of interpreting class and sequence diagrams can be found in Booch,
Rumbaugh, and Jacobson [11]. Formal definitions of each class can be found in Section 3.5.
3.4.2 Interface Specifications
3.4.2.1
Manage Archive Configuration
3.4.2.1.1
Manage Archive Configuration - Sequence. This diagram depicts
how an ADMS allows an ADMS Administrator to manage the archive configuration.
ADMS
: ADMS
Administrator
: Data Provider
Manage Archive Configuration()
// Return
Select Provider()
Interface of
interest
See Annex A for
more details
RetrieveDataCatalog()
// Return
/ / Return -- Prompt for Edits to S election ()
Selec t Data()
//Return -- Dis play Result s()
Figure 3-9. Manage Archive Configuration - Sequence Diagram
Archived Data Management System Data Model – Final Report
37
3.4.2.1.1.1 1: Manage Archive Configuration(). The ADMS Administrator
initiates a request to manage the archive configuration. This service is always initiated by the
ADMS Administrator accessing the user interface. While there may be several reasons the
administrator may want to manage the configuration, this sequence diagram only addresses the
specific case where the administrator wishes to manage the configuration of a data subscription.
All other management activities are internal to the design of an implementation and are not
addressed by this document.
3.4.2.1.1.2 2: // Return. The ADMS responds to this action by prompting the
administrator to select a specific data provider for which the subscription is to be viewed and
possibly modified. The list of data providers is presumably stored internal to the ADMS and
does not require accessing any systems external to the ADMS.
3.4.2.1.1.3 3: Select Provider(). The Administrator then selects the desired provider
from the list and returns control to the ADMS.
3.4.2.1.1.4 4: RetrieveDataCatalog(). The ADMS then contacts the selected data
provider and requests a catalog of all data available from the selected provider.
3.4.2.1.1.5 5: // Return. The Data Provider responds to this request by returning a
data catalog to the ADMS identifying all data for which the ADMS is authorized to retrieve.
3.4.2.1.1.6 6: // Return -- Prompt for Edits to Selection (). The ADMS then
combines this listing with its current subscription information and returns to the administrator
indicating which data are currently being archived and what other data are available.
3.4.2.1.1.7 7: Select Data(). The ADMS Administrator then selects the data that are
desired and passes this information to the ADMS.
3.4.2.1.1.8 8: // Return -- DisplayResults(). The ADMS processes the request and
displays the result of the operation.
3.4.2.1.2
Manage Archive Configuration - View of Participating Classes.
This diagram depicts the relationships between the various data involved in this process. An
ADMS Administrator uses the ADMS in order to connect to a selected Data Provider. There can
be multiple administrators, each authorized to access multiple ADMSs and each ADMS may be
connected to multiple data providers. Finally, each data provider may be connected to multiple
ADMSs. A Data Provider uses a Catalog to report the data types that it supports. (See Section
3.5 for a description of a Catalog.) An ADMS uses a Subscription structure to store its existing
configuration. However, this structure is never exchanged across an interface and is therefore
not defined in this document.
Archived Data Management System Data Model – Final Report
38
ADMS
0..*
0..*
0.. *
ADMS Admin
0.. *
Data Provider
<<uses>>
<<uses>>
Subsc riptions
Catalog
dataType[] : String
Figure 3-10. Manage Archive Configuration – View of Participating
Classes Diagram
3.4.2.2
Retrieve Data
3.4.2.2.1
Retrieve Data – Sequence. This diagram depicts how the ADMS
receives data from the Data Provider. One of the challenges in reaching consensus on how such
connections are made is who is responsible for performing filtering and/or buffering of data. An
additional concern was to meet the conflicting requirements being suggested by various users of
ADMS systems. Some users want to be able to log all information in real time, while other users
want to log selected information in real-time, and yet other users want to be able to periodically
dial-up a given system and download information that has been buffered over some period. The
current trends in various standards efforts indicate that this function will be performed by a third
logical entity called a Proxy. The Proxy may be implemented as a part of the data provider, as a
part of the ADMS, as a third physical component, or any combination. Regardless of the actual
physical arrangement, the process is the same. Both the ADMS and the Data Provider connect to
a common Proxy. The ADMS may then register filters with the Proxy to limit what data it
receives. Finally as logable events occur, the Data Provider notifies the Proxy and the Proxy
passes this information along to the ADMS. Depending on the communications environment,
the Proxy may buffer the data until a connection is available. This diagram is a simplification
that is protocol generic; actual implementation will vary based on the protocol used.
Archived Data Management System Data Model – Final Report
39
Int erface of
int erest
: ADMS
Proxy
: Data Provider
register supplier ()
// return
register_consumer ()
// return
add_filter()
// return
push_structured_events()
push_structured_events()
Figure 3-11. Retrieve Data – Sequence Diagram
3.4.2.2.1.1 1: register supplier (). The Data Provider notifies the Proxy that it is
able to provide data.
3.4.2.2.1.2 2: // return. The operation returns a reference to which the Data Provider
shall publish all event information.
3.4.2.2.1.3 3: register_consumer (). The ADMS registers with the Proxy in order
to receive notifications of new events. This registration includes a reference to which all
notifications will be sent.
3.4.2.2.1.4 4: // return. The ADMS receives an indication of whether the request
was successful and a reference to which it can send requests to modify filters.
Archived Data Management System Data Model – Final Report
40
3.4.2.2.1.5 5: add_filter(). The ADMS can then add filters in the data it receives by
sending specially formatted strings to the Proxy.
3.4.2.2.1.6 6: // return. The Proxy then notifies the ADMS of the success or failure
of applying the filter.
3.4.2.2.1.7 7: push_structured_events(). Once the Proxy applies the registered
filters, it sends any remaining data to the ADMS.
3.4.2.2.1.8 8: push_structured_events(). Whenever a recordable event occurs, the
Data Provider sends a push_structured _events notification to the Proxy. This message includes
a “Structured Event” as a parameter, a generic type defined further in 3.5.3.14.
3.4.2.2.2
Traffic Reports. Another example of a Structured Event is a Traffic
Report. Fortunately, the various ITS Standards have a more common view of how to describe
the status of a roadway network.
A Traffic Report is merely an aggregation of Roadway Link Reports and Roadway Detector
Reports. A Roadway Link Report describes the status of a Roadway Link at a specific point in
time, whereas a Roadway Detector Report describes the information obtained from a Roadway
Detector (a.k.a. Link Data Source) for a specific time. The data for the Roadway Link is
typically derived from one or more detectors on that link, but a Data Provider may choose to
provide only summarized or detailed information.
A variety of parameters may be provided within each report, but some systems may also support
non-standardized data that an ADMS may wish to record. The model provides for this flexibility
by defining a Parameter class, which is intended to be a user-defined parameter that may be
recorded. Each report may then include readings for these parameters.
Finally, the model also shows that a Roadway Detector Report may include detailed information
about individual vehicles that it detected. For example, it may identify the speed of each vehicle
and/or the weight of each axle of each vehicle. Obviously, such data would require specialized
equipment, but the model describes how these data could be provided and stored.
Archived Data Management System Data Model – Final Report
41
Vehicle
Class : Integer
Speed : Integer
Length : Integer
FrontOv erhang : Integer
RearOv erhang : Integer
Wheelbase : Integer
Clearance : Integer
Height : Integer
Width : Integer
Gap : Integer
Headway : Integer
GrossWeight : Integer
SeqNum : Integer
StatusFlag : Integer
Acceleration : Integer
dcmNumVehicleIDs : Integer
dcmVehicleID : Integer
dcmVehicleTimeTag100 : Integer
NumAxles : Integer
Structured Ev ent
Traf f ic Report
1
1
Axle
Number : Integer
Width : Integer
TireCount : Integer
TireTrack : Integer
Lef tWheelWeight : Integer
RightWheelWeight : Integer
Weight : Integer
WeightViolationCode : Integer
+leadingAxle
0..*
+tra il in gA xl e
0..*
Roadway Link Rep ort
Roadway Detector Report
timestamp
LinkLanesOpen
LinkDensity
LinkLev elOf Serv ice
LinkRestrictions
LinkSurf aceCondition
LinkPriority
LinkDelay
LinkOv ersaturatedFlag
LinkSpeed
LinkStatus
LinkOccupancy Percent
LinkTrav elTime
collectionPeriod
0..*
v olume
occupancy Percentage
speed
smoothedVolume
smoothedOccupancy
smoothedSpeed
collectionPeriod
endTime : Integer
Status : Integer
0..*
WIM Measurement
weight
AxleGap
spacing
0..*
0..*
1
LRMS
1
Roadway Link
LinkID
+assoc ia tedL in k
Link Data Source
+detectors0..*
0..*
1
0..*
1
OriginNodeOrder-code
Of f setTy pe-code
0... NodeValence-quantity
0..*
0..*
0..*
Parameter
Reading
v alue
+reading
0..*
+parameter name
def inition
1 units
Roadway Detector
DetectorID
ty pe
Figure 3-12. Traffic Reports Diagram
Archived Data Management System Data Model – Final Report
42
3.4.2.2.3
Retrieve Data - View of Participating Classes. This diagram
depicts the relationships between the entities involved in this process. The communication
between the Data Provider and the ADMS consists of the passing of Structured Events. The
Data Provider accesses the Proxy in order to register and send event notifications. The ADMS
accesses the Proxy in order to register and modify subscriptions. The Proxy accesses the ADMS
through a call back in order to forward the event notifications from the Data Provider(s). In
order for the ADMS to define filters, there must be some mechanism by which the ADMS can
determine what data are available from a Data Provider. The proposed model returns these data
in a Catalog object class. The ADMS then notifies the Proxy of the appropriate filters by
sending a series of strings (a string is a simple parameter and therefore is not explicitly shown in
this model).
The process uses the Structured Event class in order to transmit the event notifications. The
structured event class is a generalized class that can represent any type of information. This
initial cut at a data model has developed two specific specializations of this class, one for
Incident Reports and another for Roadway Reports.
Catalog
dataType[] : String
ADMS
Proxy
0..*
0..*
0..*
0..*
Data Provider
<<uses>>
Structured
Event
<<uses>>
Figure 3-13. Retrieve Data - View of Participating Classes Diagram
3.4.2.2.4
Incident Report, Part 1. One example of a Structured Event is an
Incident Report. Unfortunately, at present there are very different views as to how Incidents
should be recorded, as reflected by IEEE 1512, TMDD, and TCIP standards. The good news is
that there are efforts underway to harmonize these approaches. This model is primarily based on
the IEEE 1512 standard. However, the reader should realize that changes are likely in all three
of these standards and these changes should be considered prior to implementation. The
recording of harmonization results is left to future efforts.
The figure describes this generic structure by indicating that an Incident Report is a
specialization of a Structured Event, such as in the Retrieve Data Sequence Diagram, an Incident
Report can be used. The Incident Report will include an eventID to identify the Event with
Archived Data Management System Data Model – Final Report
43
which it should be associated. Over a period of time, the ADMS may receive a series of Incident
Reports that describe details of the Event as they change or become known.
An Incident Report itself is mainly an aggregation of any of the following:
Traffic Plans, which may be put into affect as a result of the incident.
Pedigree Lists, which define other related events.
Vehicle Reports, which describe vehicles involved in the incident.
Other Incident information, including,
- A description
- A timeline of the Event
- The incident severity
- The incident location
Each of these is described further in Section 3.5, but a detailed analysis was not performed due to
the likelihood that details will change.
Structured Event
Incident Report
eventID : Integer
1
1
1
0..1
0..*
Pedigree Lis t
event : String
event-des c : String
Traffic Plan
1
1
0..1
0..1
Veh icle Report
1
0 ..*
0..1
Traffic Im pact
lane Con fig : Integ er
lane sBlo cked : In tege r
s hould ersBlo cke d : Inte ge r
Lanes Dire ctio nOfTravel-co de : e nu m
Lanes To talL an es -quan tity : Integ er
qual : Integ er
tim e : Integ er
Incident Inform ation
Vehicle
ID : Integer
Typ : String
Dam : Stri ng
OccCnt : Integer
VIN : String
Tag : String
Sta te : Integer
Make : Integ er
Model : Integer
Year : Inte ger
Color : Integer
Des c : String
tim e : Integer
q ual : Integer
incidentID : Integer
The details here have been
om itted here for clarity. See
the s ubs equent diagram for
thes e details .
Figure 3-14. Incident Report Diagram, Part 1
Archived Data Management System Data Model – Final Report
44
3.4.2.2.5
Incident Report, Part 2. This diagram is a continuation of the previous
diagram. Here the Incident Information class is detailed.
Incident Informat ion
Description
agencyReporting : Integer
incSubType : String
descripShortText : String
descripLongText : String
incidentCmdr : Integer
descripWitnesses : String
Description-text : String
DescriptionAuthor-text : String
NotesAndCommentsAuthor - text : String
0..1
1
1 1
1
0..*
Event Times
0.. 1
Location
Type-c ode
0..* Relat ionToJunct ion-code
NonMot orist -code
LandmarkType-code
Exit RampEnd-identifier
Ent ranceRampBegin-identifier
Roadway-ident ifier
Severit y
priority : Integer
prioritizer : St ring
severit y : Int eger
fat alit yCnt : Int eger
injuryCnt : Int eger
value : Integer
time : Integer
qual : Integer
1
1
1
1
1
0.. *
Cross Street
LRMS
OriginNodeOrder-code
OffsetType-code
NodeValence-quantity
0..*
Coordinates 0.. *
Longitude
Altitude
Occurrence-number
End-t ext
End-ident ifier
Begin-text
Begin-identifier
0..*
0..*
Street
End-num ber
Begin-num ber
Roadway
Side-code
Name-text
1
0..*
Street Name
InfoFlag-code
IndexFlag-code
Figure 3-15. Incident Report Diagram, Part 2
3.4.2.3
Submit Data
3.4.2.3.1
Submit Data – Sequence. This diagram depicts the communication
between the ADMS Administrator, the ADMS, and the Data Provider in order to submit data.
First, the ADMS requests to Submit Data. The ADMS prompts the Administrator to select a
Data Provider. The ADMS retrieves the data catalog from the Data Provider, and then the
Administrator specifies which data to submit. The ADMS then retrieves the data, and the results
are displayed to the Administrator.
Archived Data Management System Data Model – Final Report
45
: ADMS
: ADMS
Administ rator
: Data Provider
SubmitData()
PromptForSelection()
Int erface of
int erest
See Annex C for
more details
// Return
Ret rieveDataCatalog()
// Return
PromptForDataSelection()
// Return
Ret rieveData()
// Return
DisplayResults()
Figure 3-16. Submit Data - Sequence Diagram
3.4.2.3.1.1 1: SubmitData(). This ADMS Administrator issues a request to the
ADMS indicating that the Administrator would like to Submit Data.
3.4.2.3.1.2 2: PromptForSelection(). The GUI sends a list of desired Data
Providers to the ADMS Administrator.
3.4.2.3.1.3 3: // Return. The Administrator transmits the name of the Data Provider
from which to retrieve data.
3.4.2.3.1.4 4: RetrieveDataCatalog(). The ADMS requests a catalog from the Data
Provider that defines what data are available.
Archived Data Management System Data Model – Final Report
46
3.4.2.3.1.5 5: // Return. The Data Provider returns a list of strings that identify the
data that the Data Provider offers.
3.4.2.3.1.6
Administrator.
6: PromptForDataSelection(). The GUI sends this list of strings to the
3.4.2.3.1.7 7: // Return. The Administrator selects the desired data and returns the
associated strings to the ADMS.
3.4.2.3.1.8 8: RetrieveData(). The ADMS retrieves the selected data by passing
these strings to the Data Provider.
3.4.2.3.1.9
Structured Event.
9: // Return. The Data Provider passes back the requested data in a
3.4.2.3.1.10 10: DisplayResults(). The results of the operations are displayed to the
ADMS Administrator.
3.4.2.3.2
Submit Data - View of Participating Classes. This diagram depicts
the relationships between the various data involved in this process. An ADU connects to a Data
Provider via the ADMS so that the user can subscribe to Structured Events. The types of
Structured Events are the same as those previously defined for the Retrieve Data Service.
ADMS
Archived Data
User
Dat a Provider
request.credentials()
Structured E vent
Figure 3-17. Submit Data - View of Participating Classes Diagram
Archived Data Management System Data Model – Final Report
47
3.5
Data Dictionary
This section provides full definitions of the data concepts found in this document. This reference
fully explains each class, including any input or output values. This section also includes a
detailed compatibility analysis that attempts to harmonize each data concept with those contained
in the overall ITS Data Registry.
This section is intended for only a subset of potential readers, such as:



System integrators
Device manufacturers
Conformance testers
These readers will find this section useful in order to understand the data concepts used by the
ADMS. Software architects will be able to draw upon the requirements specified here when
building future extensions of the system.
3.5.1 Compatibility Analysis
All of the data identified in this effort have been compared to data that are being defined in the
other ITS Standards efforts in order to ensure that data definitions are as compatible as possible.
As a result of the process that we followed, the data were found to be 100 percent compatible
with existing ITS Standards, with the exception of four new data elements, as follows:




Parameter.name
Parameter.definition
Parameter.units
Reading.units
We are proposing the addition of these new data elements in order to provide a standardized way
for an archive to store non-standardized data. For example, if one of the systems providing data
to an archive data management system supports customized data that are not covered by the ITS
Standards, it is still desirable to archive the information. This is achieved by the ADMS
Administrator recording the definition of the data in the Parameter object class and then selecting
its collection. Each reading of the parameter is then stored in a distinct instance of the
Reading.units data element. This approach allows a ADMS User to recognize that this additional
information is available and to retrieve the definition of the parameter as needed.
All of the other data defined in this model maps directly to data elements defined by other
standards efforts. Thus, rather than repeating definitions for these data elements, their unique
identifiers as used by the ITS Data Registry are provided for reference.
Archived Data Management System Data Model – Final Report
48
3.5.2 Section Tutorial
The dictionary is divided into the three major packages discussed throughout this document:
Communications Interface, Incident Report, and Traffic Report. Within each package, the
classes are listed alphabetically. The definition of the class follows its name. Each definition
will also list any attributes, or properties, of the class.
3.5.2.1
Communications Interface
The details of the classes in this package are beyond the scope of this initial effort.
3.5.2.1.1
ADMS. This class represents the Archived Data Management Service.
3.5.2.1.2
Data Provider. A Data Provider may be any of the center subsystems
identified in the National ITS Architecture, the roadside subsystem, or any of several
terminators. It is distinguished from a Remote Archive in that the data received from a Data
Provider are archived into the local archive.
3.5.2.1.3
Proxy. The proxy acts as a filter and is created by the ADMS and the
Data Provider to delimit the information passed during data subscription.
3.5.2.2
Incident Report
This package defines the data concepts that are related to the Incident Report specialization of a
Structured Event.
3.5.2.2.1
Coordinates. This class contains incident location coordinate
information. The data here are useful in order to define the exact location of an incident. For the
purposes of this model, Coordinates may be described by altitude, latitude, and longitude.
3.5.2.2.1.1 Altitude
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3225
EVENT_LocationCoordinatesAltitude_location
3.5.2.2.1.2 Latitude
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3226
EVENT_LocationCoordinatesLatitude_location
Archived Data Management System Data Model – Final Report
49
3.5.2.2.1.3 Longitude
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3227
EVENT_LocationCoordinatesLongitude_location
3.5.2.2.2
Cross Street. This class contains incident location cross street
information. For the purposes of this model, a Cross Street may be described by begin-identifier,
begin-text, end-identifier, end-text, and occurrence number.
3.5.2.2.2.1 Begin-identifier
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3231
EVENT_LocationCrossStreetBegin_identifier
3.5.2.2.2.2 Begin-text
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3229
EVENT_LocationCrossStreetBegin_text
3.5.2.2.2.3 End-identifier
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3234
EVENT_LocationCrossStreetEnd_identifier
3.5.2.2.2.4 End-text
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3232
EVENT_LocationCrossStreetEnd_text
3.5.2.2.2.5 Occurrence-number
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3235
EVENT_LocationCrossStreetOccurence_number
3.5.2.2.3
Description. This class contains information describing a roadway
incident. For the purposes of this model, a Description may be described by nine attributes,
which are defined below.
3.5.2.2.3.1 AgencyReporting
ID12621
CPT_AgencyID_code
3.5.2.2.3.2 descripLongText
ID12518
IM_IncidentDescLong_text
Archived Data Management System Data Model – Final Report
50
3.5.2.2.3.3 descripShortText
ID12519
IM_IncidentDescShort_text
3.5.2.2.3.4 DescriptionAuthor-text
ID130
EVENT_DescriptionAuthor_text
3.5.2.2.3.5 Description-text
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3209
EVENT_Description_text
3.5.2.2.3.6 descripWitnesses
ID12564
IM_WitnessStatement_text
3.5.2.2.3.7 incidentCmdr
ID12502
IM_EmployeeIDSystem_number
3.5.2.2.3.8 incSubType
ID12524
IM_IncidentSubtype_code
3.5.2.2.3.9
NotesAndCommentsAuthor - text
ID135
EVENT_DescriptionNotesAndCommentsAuthor_text
3.5.2.2.4
Event Times. This class contains incident time information. For the
purposes of this model, Event Times may be described by the attribute of time, defined as
ID12630, CPT_DateTime_time.
3.5.2.2.5
Incident Information. This class relates information regarding an
incident. It is an aggregation of several classes, including Description, Event Times, Severity,
and Location.
3.5.2.2.6
Incident Report. An Incident Report details incident information. It is
mainly an aggregation of related data, such as Traffic Plans, Pedigree Lists, Vehicle Reports, and
other Incident information. Each Incident Report has a unique event ID. For the purposes of this
model, an Incident Report may be described by the attribute defined as event ID, TMDD
Standard: ITE/AASHTO Std #TM1.03, ID3215, EVENT_Identifier_identifier.
Archived Data Management System Data Model – Final Report
51
3.5.2.2.7
Location. This class contains incident location information. For the
purposes of this model, a Location may be described by the following seven attributes.
3.5.2.2.7.1 EntranceRampBegin-identifier
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3239
EVENT_LocationEntranceRampBegin_identifier
3.5.2.2.7.2 ExitRampEnd-identifier
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3242
EVENT_LocationExitRampEnd_identifier
3.5.2.2.7.3 LandmarkType-code
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3245
EVENT_LocationLandmarkType_code
3.5.2.2.7.4 NonMotorist-code
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3367
EVENT_LocationNonMotorist_code
3.5.2.2.7.5 RelationToJunction-code
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3366
EVENT_LocationRelationToJunction_code
3.5.2.2.7.6 Roadway-identifier
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3259
EVENT_LocationRoadway_identifier
3.5.2.2.7.7 Type-code
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3265
EVENT_LocationType_code
3.5.2.2.8
LRMS. This contains Location Reference Message Set information. For
the purposes of this model, a LRMS may be described by the following three attributes.
3.5.2.2.8.1 NodeValence-quantity
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3252
EVENT_LocationLRMSNodeValence_quantity
Archived Data Management System Data Model – Final Report
52
3.5.2.2.8.2 OffsetType-code
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3253
EVENT_LocationLRMSOffsetType_code
3.5.2.2.8.3 OriginNodeOrder-code
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3254
EVENT_LocationLRMSOriginNodeOrder_code
3.5.2.2.9
Pedigree List. This class contains information about incidents that
preceded the current event but are tied to the same incident. For the purposes of this model, a
Pedigree List may be described by the attributes event and event-desc.
3.5.2.2.9.1 event
ID165
EVENT_Identifier_identifier
3.5.2.2.9.2
event-desc
ID125
EVENT_Description_text
3.5.2.2.10
Roadway. This class contains roadway location information. For the
purposes of this model, a Roadway may be described by the attributes name-text and side-code.
3.5.2.2.10.1 Name-text
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3260
EVENT_LocationRoadwayName_text
3.5.2.2.10.2 Side-code
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3261
EVENT_LocationRoadwaySide_code
3.5.2.2.11
Severity. This class contains incident severity information. For the
purposes of this model, a Severity may be described by the following five attributes.
3.5.2.2.11.1 fatalityCnt
ID12516
IM_HumanFatalityCount_quantity
3.5.2.2.11.2 injuryCnt
ID12517
IM_HumanInjuryCount_quantity
Archived Data Management System Data Model – Final Report
53
3.5.2.2.11.3 prioritizer
ID12502
IM_EmployeeIDSystem_number
3.5.2.2.11.4 priority
ID12658
CPT_PriorityLevel_number
3.5.2.2.11.5 severity
ID12671
CPT_SeverityLevel_number
3.5.2.2.12
Street Address. This class contains street location information, which
is useful in pinpointing the location of an incident. For the purposes of this model, a Street
Address may be described by the attributes begin-number and end-number.
3.5.2.2.12.1 Begin-number
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3264
EVENT_LocationStreetAddressBegin_number
3.5.2.2.12.2 End-number
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3263
EVENT_LocationStreetAddressEnd_number
3.5.2.2.13
Street Name. This class contains street name information that is useful
in pinpointing the location of an incident. For the purposes of this model, a Street Name may be
described by the following two attributes.
3.5.2.2.13.1 IndexFlag-code
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3256
EVENT_LocationLRMSStreetAddressIndexFlag_code
3.5.2.2.13.2 InfoFlag-code
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3257
EVENT_LocationLRMSStreetNameInfoFlag_code
3.5.2.2.14
Structured Event. A Structured Event is a data element. In the
Incident Report package, this class is a generalization of an Incident Report.
Archived Data Management System Data Model – Final Report
54
3.5.2.2.15
Traffic Impact. This class contains information about the impact on
traffic arising from a traffic incident. For the purposes of this model, a Traffic Impact may be
described by the following five attributes.
3.5.2.2.15.1 laneConfig
ID182
EVENT_LanesTotalOriginal_quantity
3.5.2.2.15.2 lanesBlocked
ITE.TMDD.event-lanes-blocked-or-closed;3219
3.5.2.2.15.3 LanesDirectionOfTravel-code
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3220
EVENT_LanesDirectionOfTravel_code
3.5.2.2.15.4 LanesTotalLanes-quantity
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3221
EVENT_LanesTotalLanes_quantity
3.5.2.2.15.5 time
ID262
EVENT_TimelineStart_UTC
3.5.2.2.16
Traffic Plan. This class contains information about managing traffic
after an incident occurs. It is an aggregation of data from Traffic Impact.
3.5.2.2.17
Vehicle. This class contains information about vehicles involved in
incidents. For the purposes of this model, a Vehicle may be described by the following ten
attributes.
3.5.2.2.17.1 Color
ID12551
IM_VehicleColor_text
3.5.2.2.17.2 Dam
ID12552
IM_VehicleDamage_text
3.5.2.2.17.3 Make
ID12566
IM_VehicleMake_text
Archived Data Management System Data Model – Final Report
55
3.5.2.2.17.4 Model
ID12557
IM_VehicleModel_text
3.5.2.2.17.5 OccCnt
ID12558
IM_VehicleOccupantCount_quantity
3.5.2.2.17.6 State
ID12560
IM_VehicleState_text
3.5.2.2.17.7 Tag
ID12561
IM_VehicleTag_text
3.5.2.2.17.8 Typ
ID12555
IM_VehicleInvolvedType_code
3.5.2.2.17.9 VIN
ID12693
CPT_VehicleIdNumber_text
3.5.2.2.17.10 Year
ID12562
IM_VehicleYear_number
3.5.2.2.18
Vehicle Report. This class contains a report of vehicle information. It
is a composition of Vehicle class information.
3.5.2.3
Traffic Report
This package defines the data concepts that are related to the Traffic Report specialization of a
Structured Event.
3.5.2.3.1
Axle. An Axle is a logical grouping of wheels that rotate about a
common axis. For the purposes of this model, an Axle may be described by the following eight
attributes:
3.5.2.3.1.1 LeftWheelWeight
NTCIP 1206, section 2.3.1.1.1.18
dcmLeftWheelWeight
Archived Data Management System Data Model – Final Report
56
3.5.2.3.1.2 Number
NTCIP 1206, section 2.3.1.1.1.1
dcmAxleNumber
3.5.2.3.1.3 RightWheelWeight
NTCIP 1206, section 2.3.1.1.1.19
dcmRightWheelWeight
3.5.2.3.1.4 TireCount
NTCIP 1206, section 2.3.1.1.1.14
dcmAxleTireCount
3.5.2.3.1.5 TireTrack
NTCIP 1206, section 2.3.1.1.1.15
dcmAxleTireTrack
3.5.2.3.1.6 Weight
NTCIP 1206, section 2.3.1.1.1.20
dcmAxleWeight
3.5.2.3.1.7 WeightViolationCode
NTCIP 1206, section 2.3.1.1.1.25
dcmAxleWeightViolationCode
3.5.2.3.1.8 Width
NTCIP 1206, section 2.3.1.1.1.12
dcmAxleWidth
3.5.2.3.2
AxleGap. An AxleGap is the space between a leading axle and a trailing
axle. For the purposes of this model, an AxleGap may be described by the attribute of spacing,
defined as NTCIP 1206, section 2.3.1.1.1.8, dcmAxleSpacing.
3.5.2.3.3
Link Data Source. This class contains information about the source of
roadway link data. It is an aggregation of LRMS data and a generalization of Roadway Detector
data.
3.5.2.3.4
LRMS. This contains Location Reference Message Set information. For
the purposes of this model, a LRMS may be described by the following three attributes.
3.5.2.3.4.1 NodeValance-quantity
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3252
EVENT_LocationLRMSNodeValence_quantity
Archived Data Management System Data Model – Final Report
57
3.5.2.3.4.2 OffsetType-code
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3253
EVENT_LocationLRMSOffsetType_code
3.5.2.3.4.3 OriginNodeOrder-code
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3254
EVENT_LocationLRMSOriginNodeOrder_code
3.5.2.3.5
Parameter. This class contains the data collected from roadway links.
The attributes of this class do not already exist in other standards, but have been added here to
allow a standardized way to record non-standard data in an archive. For the purposes of this
model, a Parameter may be described by the following three attributes.
3.5.2.3.5.1
definition. Short text description of parameter.
3.5.2.3.5.2
name. Name of parameter.
3.5.2.3.5.3
units. Units used to measure parameter.
3.5.2.3.6
Reading. This class contains readings collected from ITS equipment.
The attributes of this class do not already exist in other standards, but have been added here to
allow a standardized way to record non-standard data in an archive. For the purposes of this
model, a Reading may be described by the attribute of value, defined as value reported.
3.5.2.3.7
Roadway Detector. This class contains information about ITS
equipment that detects roadway properties. For the purposes of this model, a Roadway Detector
may be described by the following two attributes.
3.5.2.3.7.1 DetectorID
ID401
DETECTOR_Linkidentifier_identifier
3.5.2.3.7.2
type
ID402
DETECTOR_Type_code
3.5.2.3.8
Roadway Detector Report. This class contains a report of information
from Roadway Detector. For the purposes of this model, a Roadway Detector Report may be
described by the following six attributes.
Archived Data Management System Data Model – Final Report
58
3.5.2.3.8.1
endTime
ID389
DETECTOR_EndTime_UTC
3.5.2.3.8.2 occupancyPercentage
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3020
LINK_Occupancy_percent
3.5.2.3.8.3 speed
NTCIP 1206, section 2.3.1.1.1.4
dcmVehicleSpeed
3.5.2.3.8.4 startTime
ID398
DETECTOR_StartTime_UTC
3.5.2.3.8.5 Status
ID400
DETECTOR_Status_code
3.5.2.3.8.6 volume
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3040
LINK_Volume_quantity
3.5.2.3.9
Roadway Link. This class contains information about a segment of
roadway. For the purposes of this model, a Roadway Link may be described by the attribute of
LinkID, defined as TMDD Standard: ITE/AASHTO Std #TM1.03, ID3012,
LINK_Identifier_identifier.
3.5.2.3.10
Roadway Link Report. This class contains a report of information
from Roadway Link. For the purposes of this model, a Roadway Link Report may be described
by the following 13 attributes.
3.5.2.3.10.1 collectionPeriod
ID70
LINK_MeasurementDuration_quantity
3.5.2.3.10.2 LinkDelay
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3005
LINK_Delay_quantity
Archived Data Management System Data Model – Final Report
59
3.5.2.3.10.3 LinkDensity
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3006
LINK_Density_rate
3.5.2.3.10.4 LinkLanesOpen
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3015
LINK_LanesNumberOpen_quantity
3.5.2.3.10.5 LinkLevelOfService
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3017
LINK_LevelOfService_code
3.5.2.3.10.6 LinkOccupancyPercent
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3020
LINK_Occupancy_percent
3.5.2.3.10.7 LinkOversaturatedFlag
ID359
LINK_OversaturatedFlag_code
3.5.2.3.10.8 LinkPriority
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3023
LINK_PriorityType_code
3.5.2.3.10.9 LinkSpeed
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3033
LINK_Speed_rate
3.5.2.3.10.10 LinkStatus
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3036
LINK_Status_code
3.5.2.3.10.11 LinkSurfaceCondition
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3037
LINK_SurfaceCondition_code
Archived Data Management System Data Model – Final Report
60
3.5.2.3.10.12 LinkTravelTime
TMDD Standard: ITE/AASHTO Std #TM1.03
ID3038
LINK_TravekTime_quantity
3.5.2.3.10.13 timestamp
ID71
LINK_MeasurementEndTime_UTC
3.5.2.3.11
Structured Event. A Structured Event is a data element. In the Traffic
Report package, this class is a generalization of Traffic Reports.
3.5.2.3.12
Traffic Report. This class contains information of traffic conditions
comprised of data collected from roadway detectors, and other sources. It is an aggregation of
the Roadway Link Report and Roadway Detector Report classes.
3.5.2.3.13
Vehicle. This class contains data elements that pertain to vehicles. For
the purposes of this model, a Vehicle may be described by the following 19 attributes.
3.5.2.3.13.1 Acceleration
NTCIP 1206, section 2.3.1.1.1.26
dcmVehicleAcceleration
3.5.2.3.13.2 Class
NTCIP 1206, section 2.3.1.1.1.3
dcmVehicleClass
3.5.2.3.13.3 Clearance
NTCIP 1206, section 2.3.1.1.1.10
dcmVehClearance
3.5.2.3.13.4 dcmNumVehicleIDs
NTCIP 1206, section 2.3.1.1.1.27
dcmAxleWeight
3.5.2.3.13.5 dcmVehicleID
NTCIP 1206, section 2.3.1.1.1.28
dcmVehicleID
3.5.2.3.13.6 dcmVehicleTimeTag100
NTCIP 1206, section 2.3.1.1.1.29
dcmVehicleTimeTag100
Archived Data Management System Data Model – Final Report
61
3.5.2.3.13.7 FrontOverhang
NTCIP 1206, section 2.3.1.1.1.6
dcmFrontOverhang
3.5.2.3.13.8 Gap
NTCIP 1206, section 2.3.1.1.1.16
dcmVehicleGap
3.5.2.3.13.9 GrossWeight
NTCIP 1206, section 2.3.1.1.1.22
dcmGrossVehicleWeight
3.5.2.3.13.10 Headway
NTCIP 1206, section 2.3.1.1.1.17
dcmVehicleHeadway
3.5.2.3.13.11 Height
NTCIP 1206, section 2.3.1.1.1.11
dcmVehicleHeight
3.5.2.3.13.12 Length
NTCIP 1206, section 2.3.1.1.1.20
dcmAxleWeight
3.5.2.3.13.13 NumAxles
NTCIP 1206, section 2.3.1.1.1.2
dcmNumAxles
3.5.2.3.13.14 RearOverhang
NTCIP 1206, section 2.3.1.1.1.7
dcmRearOverhang
3.5.2.3.13.15 SeqNum
NTCIP 1206, section 2.3.1.1.1.23
dcmVehicleSeqNum
3.5.2.3.13.16 Speed
NTCIP 1206, section 2.3.1.1.1.4
dcmVehicleSpeed
3.5.2.3.13.17 StatusFlag
NTCIP 1206, section 2.3.1.1.1.24
dcmVehicleStatusFlag
Archived Data Management System Data Model – Final Report
62
3.5.2.3.13.18 Wheelbase
NTCIP 1206, section 2.3.1.1.1.9
dcmVehWheelbase
3.5.2.3.13.19 Width
NTCIP 1206, section 2.3.1.1.1.13
dcmVehicleWidth
3.5.2.3.14
WIM Measurement. This class contains the Weigh In Motion reading.
For the purposes of this model, a WIM Measurement may be described by the attribute of
weight, defined as NTCIP 1206, section 2.3.1.1.1.20, dcmAxleWeight.
Archived Data Management System Data Model – Final Report
63
REFERENCES
1. ITS Archiving 5-year Program Description, Mitretek Report, March 2000, available at
www.itsa.org/resources.nsf/urls/adusr.html
2. U.S Department of Transportation, National ITS Architecture, available at
www.iteris.com/itsarch
3. Turner, S.M., Eisele, W.L., Gajewski, B.J., Albert, L.P., and R.J. Benz, ITS Data
Archiving: Case Study Analyses of San Antonio TransGuide Data, FHWA-PL-99-024,
Federal Highway Administration, Texas Transportation Institute, College Station, Texas,
August 1999.
4. Strategic Plan for the Development of ADUS Standards, Cambridge Systematics, May
2000.
5. Data Modeling Task Force, Data Modeling White Paper, Version 1.0, January 1998.
6. Institute of Electronics and Electrical Engineers (IEEE), Standard for Data Dictionaries
for Intelligent Transportation Systems, IEEE Std. 1489-1999, January 2000.
7. Institute of Electronics and Electrical Engineers (IEEE), Trial Use Standard for Message
Set Templates for Intelligent Transportation Systems, IEEE Std. 1488-2000, July 2000.
8. Object Management Group, UML Resource Page, available at
www.omg.org/technology/uml/index.htm
9. Jacobson, I., Booch, G. and J. Rumbaugh, The Unified Software Development Process,
Addison-Wesley, Reading, Massachusetts, February 1999.
10. Schneider, G. and J. P. Winters, Applying Use Cases: A Practical Guide, AddisonWesley, 1997.
11. Booch, G., Rumbaugh, J., and I. Jacobson, The Unified Modeling Language User Guide,
Addison-Wesley, 1999.
Archived Data Management System Data Model – Final Report
64
BIBLIOGRAPHY
1. ADMS Data Modeling Group, ADMS Requirements, Issue 1.01 Federal Highway
Administration, January 2002.
2. National Transportation Communications for ITS Protocol, The NTCIP Guide, AASHTO,
ITE, NEMA, available at http://www.ntcip.org/library/guide.asp, December 1999.
3. TMDD and MS/ETMCC Guide, Version 1, AASHTO, ITE, available at http://www.itsstandards.net/Documents/tmdd_draft.pdf, October 2000.
4. U.S Department of Transportation/Federal Highway Administration; Institute for
Transportation Engineers, Intelligent Transportation Primer, 2000.
Archived Data Management System Data Model – Final Report
65
APPENDIX A – Manage Archive Configuration Details
This material was produced during the project and may allow readers to gain a better technical
understanding of the process and ideas that were considered in the analysis. However, the
information contained within this appendix is purely informational and does not impact the
design of any interfaces or the ADMS Data Model in any way.
This diagram depicts how the Manage Archive Configuration service works. First, ADMS
Admin requests a provider list, which ManageArchiveConfig retrieves from Catalog. ADMS
Admin then selects the specific catalog of data, which ManageArchiveConfig obtains from
DataProvider. ManageArchive also retrieves the configuration from ArchiveConfiguration.
Once ADMS Admin selects the specific data, ManageArchiveConfig updates
ArchiveConfiguration and logs the transaction.
Archived Data Management System Data Model – Final Report
A-1
: User
Interface
: ADMS
Administrator
ManageArchiveConfig()
: ADMS
: Catalog
:
ArchiveConfigurat ion
: Data Provider
: Log
RequestProviders()
RetrieveProviderList()
DisplayProviders()
PromptForSelection()
RequestCatalog()
RetrieveDataCatalog()
RetrieveConfig()
The Retrieve Data service uses
ArchiveConfiguration to determine
which data to retrieve
PromptForEditsToSelection()
SelectData()
UpdateConfig()
DisplayResults()
DisplayResults()
LogTransaction()
Figure A-1. Manage Archive Configuration - Sequence
Archived Data Management System Data Model – Final Report
A-2
1: ManageArchiveConfig()
This service is always initiated by the ADMS Administrator accessing the user interface and
requesting to manage the archive configuration. While there may be several reasons the
administrator may want to manage the configuration, this sequence diagram addresses only the
specific case where the administrator wishes to manage the configuration of a data subscription.
All other management activities are internal to the design of an implementation and are not
addressed by this document.
2: RequestProviders()
This service is always initiated by the ADMS Administrator accessing the user interface and
requesting to manage the Archive Configuration.
3: RetrieveProviderList()
The ADMS then retrieves the provider list from the Catalog in order to obtain list of providers.
4: [return]
The Catalog then returns the list of data providers to the ADMS.
5: DisplayProviders()
The ADMS then passes this list to the GUI for display to the user.
6: PromptForSelection()
The ADMS Admin GUI then displays the list and prompts the user to select which provider
interface it wants to manage.
7: [return]
The Administrator makes the selection and the response is passed to the ADMS Admin GUI.
8: RequestCatalog()
The GUI passes the selection to the ADMS. The ADMS will then request a catalog to manage.
9: RetrieveDataCatalog()
The ADMS then retrieves a catalog of data from the Data Provider.
10: [return]
The Data Provider returns a data catalog to the ADMS.
11: RetrieveConfig()
The ADMS then retrieves archive configuration information.
12: [return]
The Archive Configuration is returned to the ADMS.
13: [return]
The data catalog and configuration information is returned to the ADMS Administrator.
Archived Data Management System Data Model – Final Report
A-3
14: PromptForEditsToSelection()
The ADMS Admin GUI then displays the list and prompts the user to select which data to
retrieve and the form in which it is to be retrieved.
15: [return]
The selection is returned to the GUI.
16: SelectData()
The GUI passes the users selection the ADMS. The data selected will be updated in the
ArchiveConfiguration.
17: UpdateConfig()
The Archive Configuration is updated with new data.
18: [return]
A confirmation is returned to the ADMS.
19: DisplayResults()
The ADMS passes the results of the update to the GUI.
20: DisplayResults()
The GUI displays the results to the ADMS Administrator.
21: LogTransaction()
The AMDS logs the details of the transaction.
Archived Data Management System Data Model – Final Report
A-4
APPENDIX B – RETRIEVE DATA SERVICE DETAILS
This material was produced during the project and may allow readers to gain a better technical
understanding of the process and ideas that were considered in the analysis. However, the
information contained within this appendix is purely informational and does not impact the
design of any interfaces or the ADMS Data Model in any way.
This diagram depicts the specific interactions that occur during the Retrieve Data service. When
notified by the Archive Configuration, the Data Retriever initiates a data subscription to the Data
Provider. Once the data are returned, the data are validated, formatted, and stored in the Archive
Configuration. All transactions are then logged.
RetrieveData()
happens per request
:
ArchiveConfiguration
: Dat aRetriever
: Log
: Data Provider
U pdate Subscripti on()
RetrieveData()
For t he de tails of this interaction , see
Retrieve D ata C onsu mer In terac tion,
Retrieve D ata S uppl ier Int eracti on an d
Retrieve D ata C onsu mer-S uppli er dia grams
DataValidation()
DataFormatting()
Lo gT ransacti on()
T ransmission of data from
DataProvider to ADMS. Bulk of
communication between two
systems occurs here. See Retrieve
Data Consumer-Supplier diagram.
Figure B-1. Retrieve Data – Sequence
1: UpdateSubscription()
The Archive Configuration notifies the data retriever to update the current subscription. This
action is resultant from an earlier command by an ADMS Administrator to manage the archive
configuration. (See Manage Archive Configuration interaction diagrams.)
2: RetrieveData()
The Data Retrever issues a RetrieveData() command on DataProvider to request data.
Archived Data Management System Data Model– Final Report
B-1
3: [return]
The data are returned.
4: DataValidation()
RetrieveData runs DataValidation() process to ensures that data will not corrupt archive.
5: DataFormatting()
RetrieveData runs DataFormatting() process to ensure that it conforms to the database schema.
6: LogTransaction()
The details of the transaction are logged.
This diagram depicts the setup for communication for the Retrieve Data service. The Data
Retriever issues a new_for_consumers() command on the Event Channel, which in turn creates
the Consumer Admin. The Consumer Admin then creates a Sequence Proxy Push Supplier
object when notified to do so by the Data Retriever. Then, the Data Retriever connects to the
Data Provider through the Sequence Proxy Push Supplier.
Archived Data Management System Data Model– Final Report
B-2
: DataRetriever
new_for_consum ers()
: EventChannel
:
ConsumerAdmin
obtain_notification_push_supplier()
:
SequenceProxyPushSupplier
connect_sequence_push_consumer()
Figure B-2. Retrieve Data Consumer Interaction – Sequence
1: new_for_consumers()
The new_for_consumers operation is invoked to create a new Notification Service style
ConsumerAdmin instance. The operation accepts as an input parameter a Boolean flag, which
indicates whether AND or OR semantics will be used when combining the filter objects
associated with the newly created ConsumerAdmin instance with those associated with a
supplier proxy.
2: [return]
The Event Channel creates the Consumer Admin object.
3: [return] The Event Channel returns a reference to the newly created Consumer Admin
instance.
Archived Data Management System Data Model– Final Report
B-3
4: obtain_notification_push_supplier()
The obtain_notification_push_supplier operation accepts as an input parameter a flag that
indicates that a Sequence-style of push-style proxy supplier instance should be created.
5: [return]
The Consumer Admin creates a Sequence Proxy Push Supplier object.
6: [return]
The reference to the new proxy supplier instance is returned as the operation result.
7: connect_sequence_push_consumer()
This operation is invoked in order to establish a connection between a push-style consumer of
events in the form of sequences of Structured Events, and the notification channel.
This diagram depicts the transmission of data from the DataProvider to the Data Retriever.
: DataRetriever
push_structured_events()
Filter
: Data Provider
p ush_structu red_ even ts()
T he dotted message line between
SequenceProxyPushConsumer and
SequenceProxyPushSupplier indicates
that there is 'behind-the-scenes' activity
occuring between the flow and the
classes. Filtering and other activities
may occur as data is passed through.
T hese details are beyond the scope of
this diagram.
Figure B-3. Retrieve Data Consumer-Supplier – Sequence
Archived Data Management System Data Model– Final Report
B-4
1: push_structured_events()
The push_structured_events operation takes as input a parameter a sequence of Structured Events
being delivered to the consumer by the supplier to which it is connected.
2: push_structured_events()
The push_structured_events operation takes as input a parameter a sequence of Structured Events
being delivered to the consumer by the supplier to which it is connected.
This diagram depicts the setup for communication for the Data Provider. The Data Provider
issues a new_for_suppliers() command on the Event Channel, which in turn creates a Supplier
Admin object. The Supplier Admin then creates a Sequence Proxy Push Consumer instance
when notified to do so by the Data Provider. Then, the Data Provider connects to the ADMS
through the Sequence Proxy Push Consumer.
: Data Provider
Filter
new_for_suppliers()
obtain_notification_push_consumer()
connect _sequence_push_supplier()
Figure B-4. Retrieve Data Supplier Interaction – Sequence
1: new_for_suppliers()
The operation accepts as an input parameter a Boolean flag, which indicates whether AND or
OR semantics will be used.
2: [return]
The operation returns the reference to the new SupplierAdmin instance as the result of the
operation.
Archived Data Management System Data Model– Final Report
B-5
3: obtain_notification_push_consumer()
The obtain_notification_push_consumer operation accepts as an input parameter a flag, which
indicates that a Sequence style of push-style proxy consumer instance.
4: [return]
The reference to the new proxy consumer instance is returned as the operation result.
5: connect_sequence_push_supplier()
The connect_sequence_push_supplier operation accepts as an input parameter the reference to an
object supporting the SequencePushSupplier interface.
Archived Data Management System Data Model– Final Report
B-6
APPENDIX C – SUBMIT DATA SERVICE DETAILS
This material was produced during the project and may allow readers to gain a better technical
understanding of the process and ideas that were considered in the analysis. However, the
information contained within this appendix is purely informational and does not impact the
design of any interfaces or the ADMS Data Model in any way.
This diagram depicts the interaction that occurs during the Submit Data service. First, the
ADMS Administrator goes through the ADMS to retrieve a list of providers from Catalog.
Then, the ADMS Administrator requests a catalog of data, which the Data Submitter retrieves
from the Data Provider. The ADMS Administrator then selects the data desired, which causes
the GUI to issue an ImportData() command. The Data Submitter retrieves the data, which are
then validated and formatted. The Data Submitter updates the catalog, displays the result of the
transaction to the ADMS Administrator and logs the transaction.
Archived Data Management System Data Model – Final Report
C-1
: User
Interface
: ADMS
Administrator
: Data
Submitter
: Catalog
: Data Provider
: Log
SubmitData()
RequestProviders()
RetrieveProviderList()
DisplayP roviders()
PromptForSelection()
RequestCatalog()
RetrieveDataCatalog()
PromptForDataSelect ion()
Im portData()
RetrieveData()
DataValidation()
DataFormatting()
UpdateCatalog()
LogTransaction()
DisplayResults()
DisplayResults()
Figure C-1. SubmitData – Sequence
1: SubmitData()
The ADMS Administrator issues a string of data indicating the request to Submit Data to the
archive. Only the Administrator is authorized to issue this command.
2: RequestProviders()
The GUI issues a string of data on the Data Submitter in order to retrieve a catalog of data
providers.
Archived Data Management System Data Model – Final Report
C-2
3: RetrieveProviderList()
The Data Submitter issues a function call to retrieve a list of data providers.
4: [return]
The catalog returns a string of data that contains the provider list.
5: DisplayProviders()
The ADMS transmits the provider list to the ADMS Administrator via the GUI.
6: PromptForSelection()
The GUI prompts the ADMS Administrator to select the catalog from which to pull data.
7: [return]
The Administrator transmits strings of data that specify the catalogs from which to retrieve data.
8: RequestCatalog()
The GUI passes strings of data indicating which catalogs to retrieve to the Data Submitter in
order to retrieve data catalog(s).
9: RetrieveDataCatalog()
The ADMS passes strings of data to the Data Provider in order to retrieve a catalog of data.
10: [return]
The Data Provider returns strings of data that contain the specified catalog(s).
11: [return]
The data catalog is passed to ADMS Administrator via the GUI.
12: PromptForDataSelection()
The GUI prompts the Administrator to specify the data to submit.
13: [return]
The Administrator transmits data strings that specify the data that are to be submitted to the
ADMS.
14: ImportData()
The GUI transmits the Administrator's data strings to the Data Submitter in order to import
selected data.
15: RetrieveData()
The Data Submitter transmits the data strings to retrieve the select data from the Data Provider.
16: [return]
The Data Provider passes back strings containing the requested data.
Archived Data Management System Data Model – Final Report
C-3
17: DataValidation()
The Data Submitter calls the DataValidation() process to ensure that data will not corrupt the
archive.
18: DataFormatting()
The Data Submitter calls the DataFormatting() process to ensure that the data conform to the
database schema.
19: UpdateCatalog()
The DataSubmitter issues a string on the Catalog in order to update the catalog.
20: LogTransaction()
Strings of data containing transaction details are logged.
21: DisplayResults()
Strings of data representing the results of the operations are displayed to the ADMS
Administrator via the GUI.
22: DisplayResults()
Strings of data representing the results of the operations are displayed to the ADMS
Administrator.
Archived Data Management System Data Model – Final Report
C-4