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, OH43021
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.
Table of Contents
Page
ACRONYM LIST
Executive Summary
Data Model Development Process
Complications
The Data Model
Communications Interface Model
Incident Report
Traffic Report
Compatibility Analysis
Future Directions
Need to Refine Model
Need to Harmonize Data
Need to Coordinate Model with Message Set Efforts
Need to Extend Model
Conclusions
CHAPTER 1: INTRODUCTION
1.1Background
1.2Objectives and Scope
1.3Organization of Report
CHAPTER 2: LITERATURE REVIEW
2.1Introduction
2.2Archived Data User Service and Archived Data Management System
2.2.1National ITS Architecture
2.2.2ADUS and ADMS
2.3ADUS Standards
2.3.1ITS Standards Development
2.3.2ADUS Standards Development
2.4Data Modeling
2.4.1Data Modeling Concepts
2.4.2ADMS Data Modeling
CHAPTER 3: DATA MODEL
3.1Introduction
3.1.1General
3.1.2Actors
3.1.2.1ADMS Administrator
3.1.2.2Archived Data User
3.1.2.3Data Provider
3.1.2.4Government Reporting System
Table of Contents (CONTINUED)
Page
3.1.2.5Remote Archive
3.1.2.6Financial Institution
3.1.3Organization of Chapter
3.2Concept of Operations
3.2.1Section Tutorial
3.2.2Service Diagrams
3.2.2.1Introduction
3.2.2.2Service Descriptions
3.3Functional Requirements
3.3.1Section Tutorial
3.3.2Service Requirements
3.3.2.1Login Service Requirements
3.3.2.2Administrative Services Requirements
3.3.2.3User Services Requirements
3.4Interaction Specification
3.4.1Section Tutorial
3.4.2Interface Specifications
3.4.2.1Manage Archive Configuration
3.4.2.2Retrieve Data
3.4.2.3Submit Data
3.5Data Dictionary
3.5.1Compatibility Analysis
3.5.2Section Tutorial
3.5.2.1Communications Interface
3.5.2.2Incident Report
3.5.2.3Traffic Report
References
Bibliography
List of Appendices
Appendix A – Manage Archive Configuration Details...... A-
Appendix B – Retrieve Data Service Details...... B-
Appendix C – Submit Data Service Details...... C-
Table of Contents (CONTINUED)
Page
List of TABLES
Table 2-1. Stakeholders for Archived ITS Data
List of Figures
Figure ES-1.Retrieve Data – View of Participating Classes Diagram
Figure ES-1.Retrieve Data – View of Participating Classes Diagram
Figure ES-2a.Incident Report Diagram, Part 1
Figure ES-2b.Incident Report Diagram, Part 2
Figure ES-3.Traffic Reports Diagram
Figure 2-1.ITS Data Mart Market Package: National ITS Architecture, available at (as of March 2001)
Figure 2-2.ITS Data Warehouse Market Package: National ITS Architecture, available at (as of March 2001)
Figure 2-3.ITS Virtual Data Warehouse Market Package: National ITS Architecture, available at (as of March 2001)
Figure 2-4.Data Modeling Process
Figure 3-1.Sample Physical Architecture for an ADMS
Figure 3-2.Identifying Actors on a System
Figure 3-3.Sample Use Case Diagram for ADMS
Figure 3-4.Login Service Diagram
Figure 3-5.Administrative Services Diagram
Figure 3-6.User Services Diagram
Figure 3-7.Sample Sequence Diagram for Login Service
Figure 3-8.Sample VOPC Diagram for Login Service
Figure 3-9.Manage Archive Configuration - Sequence Diagram
Figure 3-10.Manage Archive Configuration – View of Participating Classes Diagram
Figure 3-11.Retrieve Data – Sequence Diagram
Figure 3-12.Traffic Reports Diagram
Figure 3-13.Retrieve Data - View of Participating Classes Diagram
Figure 3-14.Incident Report Diagram, Part 1
Figure 3-15.Incident Report Diagram, Part 2
Figure 3-16.Submit Data - Sequence Diagram
Figure 3-17.Submit Data - View of Participating Classes Diagram
Table of Contents (CONTINUED)
Page
List of Figures (Continued)
Figure A-1.Manage Archive Configuration - Sequence...... A-
Figure B-1.Retrieve Data – Sequence...... B-
Figure B-2.Retrieve Data Consumer Interaction – Sequence...... B-
Figure B-3.Retrieve Data Consumer-Supplier – Sequence...... B-
Figure B-4.Retrieve Data Supplier Interaction – Sequence...... B-
Figure C-1.SubmitData – Sequence...... C-
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
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, 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.
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 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.
Figure ES-2a. Incident Report Diagram, Part 1
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).
Figure ES-3. Traffic Reports Diagram
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.
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.