U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590

Skip to content U.S. Department of Transportation/Federal Highway AdministrationU.S. Department of Transportation/Federal Highway Administration

Asset Management


Transportation Asset Management Case Studies
Data Integration: The Virginia Experience

How is VDOT Getting There?

Overall Approach

VDOT began development of the Asset Management System by revisiting the original requirements of the BPR. In contrast to the single off-the-shelf system envisioned in early efforts, VDOT staff divided the BPR requirements into a series of components that could be developed individually and integrated incrementally. The new Asset Management System has six key components:

  • Condition Assessment Module
  • Needs-Based Budget Request Module
  • Planning and Scheduling Module
  • Work Order and Accomplishment Module
  • Inventory Module
  • Analysis Tools Module

As part of previous information technology (IT) initiatives, VDOT has developed agency-wide architecture standards and metadata. VDOT plans to adhere to these standards for all future decision-support systems, including the Asset Management System. Adherence to these standards will help ensure that all of VDOT's decision-support tools are eventually fully integrated.

Data Integration Process

Work on the first two components of the Asset Management System-the Condition Assessment Module and the Needs-Based Budget Request Module-began in 2003. In developing these modules, VDOT followed a formal systems development process designed to provide consistency between the individual development efforts and ensure that data required for the Asset Management System is fully integrated. This two-phase process consists of the following steps:

Phase I

  • Document and review systems that will provide source data, and interview system owners
  • Investigate alternatives for the system's data repository and reach consensus on the best approach
  • Develop metadata (i.e., identify all data items required for the system and the key characteristics of each item)
  • Design the data repository
  • Map required data from its source to its eventual location in the data repository
  • Develop data queries and routines required to export data from other systems and convert them for use in the system
  • Populate the data repository

Phase II

  • Connect the data repository to the new software tool
  • Connect the data repository to other systems and data repositories as required

From an organizational point of view, key conditions would be required for the success of VDOT's development effort:

  • Upper management will support the business objectives of the project and the creation of a new system to meet these objectives.
  • Project managers will be provided with the budget, staff, and IT resources necessary to initiate and complete the development process.
  • All stakeholders and eventual system users from the districts and headquarters will cooperate with the project team throughout the development efforts.

Data Integration Strategy

VDOT's new data integration strategy has enabled it to make significant progress without waiting for the details of the "target" Asset Management System to be finalized.

The following figure illustrates VDOT's new data integration strategy. Relevant data from various systems are being processed and imported into a data repository. VDOT is proceeding with this work without fully understanding the details of the "target" Asset Management System. This work is independent of what the final system will look like. For example, the final Asset Management System may consist of a series of individual tools, or it may resemble the comprehensive enterprise resource planning system once proposed. It is anticipated that if all relevant data are cleansed, normalized, and stored in a single data repository, VDOT will be able to export data to any future system.

This strategy provides VDOT with tremendous flexibility in designing the final Asset Management System. The design will continue to evolve based on organizational requirements, funding availability, and emerging technologies. In the meantime, this approach has enabled VDOT to make significant progress both in the development of individual maintenance decision-support tools and in the integration of maintenance data, without waiting for the final details of the comprehensive Asset Management System to be developed.

Data Conversion and Migration Strategy.The schematic shows a data conversion and migration strategy. There are 2 phases: Phase 1 is labelled as Independent of target system; Phase 2 is labelled as Dependent on target system. At the start of Phase 1, Source A, Source B, or Source C lead to the Initial Conversion Programs and Proceesses, which in turn leads to Data Repository. This leads into Phase 2, first to Final Conversion Programs and Processes, then to Asset Management System, the final step in the strategy.

Needs-Based Budget Request Module

VDOT's Needs-Based Budget Request Module enables users to develop maintenance budgets that reflect the current condition of its assets. In the context of the data integration strategy described above, this system is not the target system: it is an interim module that relies on data stored in the data repository. The architecture of the Needs-Based Budget Module consists of three tiers:

  • The Data Tier resembles a mini data warehouse. The system relies on inventory and condition data stored in VDOT's pavement management system, bridge management system, and condition assessment module. Relevant data are exported from these systems, transformed, and loaded into an Oracle database. The database uses a data model that is optimal for performing queries. The database stores both raw data and results generated by the application.
  • The Application Logic Tier includes an analytic engine that processes business rules and models stored in the database. This design enables VDOT to update its rules and models without modifying the application. For some types of assets (e.g., pavement, pavement markings, guardrail, culverts, grass), the application includes models and generates results based on these models. For other types of assets (e.g., bridges and traffic signals), the system reports results that have been pre-calculated by other systems.
  • The Front-End Tier provides users with an interface to the system. A Web-based application enables users to perform queries, modify business rules and model assumptions, and generate reports based on the results.

Linear Referencing System

A linear referencing system (LRS) provides the foundation for VDOT's data integration efforts and has three functions:

  • Defining location in space and on the network (i.e., spatial referencing)
  • Defining connectivity of assets to the network and of parts of the network to itself (i.e., establish topology)
  • Defining temporal versions of the spatial and attribute data to support planning scenario evaluations

For the ICAS project, VDOT adopted the standards and methods recommended in the National Cooperative Highway Research Program (NCHRP) 20-27 Project on Linear Referencing Systems Implementation. The Highways by Exor program was selected for the ICAS project in part because it meets the requirements of the NCHRP 20-27 data model, and was therefore able to perform the linear data management and temporal data management required by ICAS. VDOT has since implemented the ESRI transportation data model known as UNETRANS, which incorporates elements of NCHRP 20-27 but is also flexible. UNETRANS includes temporal data versioning, which reduces the need for a proprietary program such as Highways by Exor.

PDF files can be viewed with the Acrobat® Reader®
Updated: 06/27/2017
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000