U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000
Federal Highway Administration Research and Technology
Coordinating, Developing, and Delivering Highway Transportation Innovations
REPORT |
This report is an archived publication and may contain dated technical, contact, and link information |
|
Publication Number: FHWA-HRT-15-049 Date: April 2015 |
Publication Number: FHWA-HRT-15-049 Date: April 2015 |
© gyn9037/Shutterstock.com The LTPP database provides nearly three decades of pavement performance information and continues to evolve in size, content, and structure. |
The extraordinary volume and complexity of pavement performance data present a real challenge to the LTPP program—providing quality control, security, and ease of access are the primary considerations. Fortunately, as the mountain of data grows, computer technology advances in ways that continue to benefit the program.
The founders of the LTPP program knew that to achieve the primary engineering objectives of the program, it would be necessary to establish a robust pavement performance research database. Previous efforts to collect research-quality pavement performance data had been short-lived and geographically limited, and they did not secure the data for future use. The LTPP program has successfully accomplished the major challenge of developing, maintaining, and updating a database to support a national approach to improving pavement engineering and management tools.
Today the LTPP database is recognized by the Transportation Research Board (TRB) as LTPP’s principal operational tool, its principal product, and its principal legacy to future highway researchers and practitioners.1 The primary objective of the LTPP database is to serve as a central repository for data collected by the program in a format that is secure, of known quality, easy to disseminate, and compatible with current database software. Successful completion of this objective has required many changes to the database over time. This chapter summarizes the development of the LTPP database and includes an overview of major structural and processing changes, improvements in computer hardware technology, and upgrades in database management and operating system software. Information on the state of the database with references to other information resources are also included. Although some of the procedures protecting data quality are described here, chapter 9 provides a full discussion of LTPP quality control/quality assurance (QC/QA) processes used by the program.
Key Milestones in Storing and Disseminating LTPP Data | |
---|---|
1989 | LTPP database created using Oracle® 5 |
1991 | First data release |
1993 | Switch from DOS-based data entry to Windows® |
1995 | FHWA assumes data distribution function from TRB |
1997 | Database operations, engineering specifications, computer programming, and management merged in one contract |
1997 | FHWA-LTPP Customer Support Service Center and Customer Survey processes started |
1997 | DataPave 1.0 released |
1998 | AIMS data release policy established |
2002 | New policy provides access to all LTPP data regardless of quality status |
2002 | DataPave Online launched |
2003 | First Standard Data Release |
2006 | Customer Support Service Center moves to FHWA’s highway research center |
2008 | IMS moves to FHWA’s highway research center |
2009 | FHWA pledges to continue LTPP operations |
2011 | FHWA moves all LTPP data to FHWA research center |
2011 | Data entry centralized through online LTPP Data Entry Portal |
2012 | AIMS files centralized online with AIMS Data Entry Portal |
2014 | Debut of LTPP InfoPave™ |
The overall system used to manage information intended for LTPP’s public dissemination is called the Information Management System (IMS) (figure 8.1). The system’s major components are LTPP products, the Pavement Performance Database (PPDB, or LTPP database), and the Ancillary Information Management System (AIMS). Products are program results and tools that can be used to improve pavement performance management and are discussed in chapter 10. At the time of this report, the LTPP database contained 330 million data records: pavement-related data, computed parameters, and summary weather and traffic data. The AIMS contains 2.7 million additional files: documents, videos, photos, and raw data files created in the LTPP program. Together these collections occupy a significant amount of electronic storage (over 5 TB).
FIGURE 8.1. The LTPP Information Management System (IMS) includes Products, the Pavement Performance Database (PPDB), and the Ancillary Information Management System (AIMS) |
An introduction to the IMS is not complete without a review of the structure and development of the LTPP database. Most LTPP data are collected and processed by the four LTPP regional support contractors; other data are provided by central sources. Each regional support contractor is responsible for loading and processing data for the region’s test sections. These data are input into the national database, which is operated by the central technical support services contractor (referred to as the “technical assistance contractor” earlier in the program). The technical support services contractor is responsible for managing the IMS, loading data from other central data sources, performing extended central checks on all data, creating some central computed parameters, and creating data releases to the public on a periodic cycle. The LTPP Customer Support Service Center staff is responsible for data dissemination and data user support. The following sections describe how this data processing structure has matured over time.
Over the course of the LTPP program, changes in the program’s sponsorship and contractual relationships and advances in information technology have influenced the development of the program’s information management processes. This section briefly describes how the data were managed, from point of collection through dissemination to data users, during four time periods.
After the national long-term pavement performance database was established under Strategic Highway Research Program (SHRP) management in 1989, the LTPP IMS, which included the LTPP data and its supporting information, consisted of a central node (the national IMS, or NIMS) located at the TRB office in Washington, DC, and the regional nodes (regional IMS, or RIMS), one at each of the four LTPP regional offices.
Figure 8.2 illustrates the initial LTPP database process, dataflow, quality checks, and data releases under central operation of the LTPP database by TRB. The four SHRP-LTPP regional coordination office contractors (under the Federal Highway Administration (FHWA) called “regional support contractors”) had primary responsibility for collection and entry of the data into the RIMS. The data were then transferred into a “shadow database” at TRB where all of the regional databases were combined. The shadow database served as intermediate storage while QC checks were run centrally on the data by central SHRP-LTPP contractor staff. A feedback loop to the regional contractors was used to address issues with data failing a QC check. Data exchange between the RIMS and the NIMS was accomplished by mailing cassette tapes to avoid the high cost of telecommunicating large volumes of data.
The LTPP Information Management System includes LTPP Products, the Pavement Performance Database, and the Ancillary Information Management System.
Information supporting the data, such as distress photographs, laboratory data sheets, and core samples, was retained by the regional contractors for future reference. In the early years of the program, this information, which would evolve into the AIMS, was not stored centrally or made available for release.
Figure 8.2 also illustrates two data release categories. Category 1 was data released back to the participating agency where the test section was located. Category 1 data could be released without passing data quality checks. The category 2 data release was to the general public, and these data had to pass five levels of data quality checks. These data quality checks and their impact on how the LTPP program disseminated the data are discussed in the following Data Release Policy section.
The LTPP database is a relational database optimized for data storage and data entry. The database consists of records with multiple elements. Although one or more elements in a record may be subject to automated review, the record is tagged with the worst outcome of all data elements in the record. Data are released at the record level, not as elements from a record. In the release discussions that follow, data and records should be considered synonymous.
Data Release Policy
In the early years of the LTPP program, data released to the public were required to pass a series of data quality checks. In preparation for release of data to the public, five types of QC checks, labeled from A to E, were performed by the NIMS software as part of the level 1 processing. The checks were applied in series, and data did not proceed to the next check until satisfying the previous one. Not all data elements in a record were checked at every level.
A—Random checks to ensure correct RIMS-NIMS upload exchange.
B—Data dependency checks to ensure that basic section information (location, experiment, etc.) is recorded.
C—Minimum data search for critical elements (e.g., friction data should include skid number).
D—Expanded range checks to identify data elements that fall outside an expected range.
E—Intramodular checks to verify consistency of data within or between records.3
FIGURE 8.2. Overview of the initial SHRP-LTPP database process, data flow, and releases circa 1989 to 1994, with the database of the Strategic Highway Research Program (SHRP) offices residing at the Transportation Research Board (TRB). (Adapted from J. T. Maddock 1991.2) |
Data passing all five level 1 checks, qualified as a level 1, category 2, data release to the general public. Data passing the level 1 checks were also called “level E” data because the field named RECORD_STATUS contained an entry of E to indicate a record had passed.
A level 2 set of data QC checks, tied to what was called an “experiment release,” was planned but not implemented. The plan was for data passing level 1 checks to be subject to the following four types of additional global, cross-modular checks:
F—Intermodular cross checks to verify existence and consistency of data for related categories.
G—Experiment and cell assignment checks based on collected data.
H—Various checks involving frequency distributions and bimodal and variance checks.
I—Statistical checks for outliers, missing data, and completeness of experiment.
Although the full progression of QC checks to level 2 for all data was not realized, the planned level 2 checks have since been applied in a more limited way as part of some of the level 1 checks, other forms of post-upload checks, and formal data studies.
Beginning in January 1991, four data releases were made available to the public, upon request, at 6-month intervals. All were level 1 releases of data from the General Pavement Studies (GPS).4 Details of the QC/QA processing are discussed in chapter 9.
Following the end of SHRP and transfer of the LTPP program to FHWA, management of the LTPP IMS remained with SHRP under a contract between the two parties from 1992 to 1995. In 1995, TRB transferred management of the LTPP IMS to FHWA. Operation of the central LTPP database became the responsibility of the LTPP pavement database contractor, and the central hardware was moved to the contractor’s location in Oak Ridge, Tennessee.
Also circa 1994 to 1995, a major shift of responsibility to the regional support contractors for primary QC processing of LTPP data was being implemented. This change was inspired by the relatively long time lag between the results of central QC checks from the central LTPP contractor and subsequent resolutions/data corrections by regional contractors. To provide automation and central review of QC check results, the central LTPP contractor created a software program named “Browser.” The Browser program allowed the regional contractors to comment on data failing a QC check and provided rudimentary scripts to perform manual upgrades to a record’s QC status. In concept, all manual upgrades to data records failing a QC check would be reviewed by the central LTPP contractor and the comments explaining these manual QC upgrades would be made available to data users. Figure 8.3 illustrates the changes in data processing responsibilities and flow from the initial database model shown in figure 8.2.
In 1998, a new process was introduced to document the outcome of data review and correction processes. The Data Analysis/Operations Feedback Report (DAOFR) became a method by which any user of LTPP data could raise questions about data elements or data processes and initiate review and corrective actions by the LTPP program. The DAOFR became a method of systematically documenting issues identified by researchers and others about completeness and validity of data.
During this time period, supporting data to be associated with AIMS continued to be retained by the regional support contractors.
In 1997, FHWA combined the central technical assistance services for pavement engineering, database management, and traffic engineering into a single contract. This was a significant milestone for the LTPP database: it fostered effective, direct communications among these three technical professions that previously were split into three separate contracts. A true synergy developed among the pavement engineering staff, who understood what the pavement engineering data meant; traffic engineers, who knew what the traffic data meant; and the computer database staff, who knew how best to use available computer technology to store, process, and disseminate the combined pavement and traffic data that comprises the majority of the LTPP database. It was around this time that the program developed formal guidelines for adding new elements to the database, modifying existing elements, and resolving issues. The guidelines provided conventions and specifications to ensure that engineers and software programmers could communicate effectively and efficiently to develop the database.5
FIGURE 8.3. Functional diagram of LTPP data processing flow circa 1995 to 1999, which allowed regional support contractor offices to make manual quality control (QC) upgrades and explain them in the Browser software. |
Data Release Policy
During the 1995 to 1999 time period, the data release policy for the NIMS remained the same as it was during the SHRP-LTPP years: data released to the public had to pass all level 1 QC checks and be at level E. The comments explaining manual upgrades made by the regional support contractors were provided to data users. In 1998, a policy for release of data contained in AIMS was established.
An interesting LTPP database improvement was made in 2001, when the LTPP program began recording pavement structural changes by incrementing the test section construction number each time a maintenance or rehabilitation activity occurred on a test section. The construction number is a critical field in many LTPP database tables that links pavement performance measurements to the physical pavement structure existing at the time. Adding the sequential numbering system to indicate all work activities performed on a test section during LTPP monitoring provided a convenient method to indicate these changes. Implementing this major change to the database required close collaboration between the LTPP program office and its contractor staff to review the technical details of the change and to resolve inconsistencies. This change was reflected in the database and in data releases from November 2001 forward.
During this period, there was explicit recognition of the value of LTPP information that exists outside of the database for re-searchers. Loss of AIMS-eligible data due to media failures led to a transition from floppy disks to CD-ROMs as the primary backup and storage medium in 2001. This change created the foundation of the structure for AIMS and the first submissions for central distribution. In 2005, the types of ancillary data included were expanded, the structures revised, and the storage and distribution medium changed to DVD.
Data Release Policy
A database paradigm shift occurred in 2002 with a change to LTPP’s data release policy. The decision was made to release all LTPP data contained in the database, regardless of its quality, to the public, free of charge.6 Previously, only data that had passed the automated QC checks or had been manually upgraded by LTPP contractor staff to level E (previously referred to as category 2) were generally available to the public. So, those interested in all LTPP data during that time period had to make a special request that needed to be approved by the LTPP program office. This policy created problems of perception over the quality and amount of available LTPP data.
Level E records should not be considered better or worse than records at other levels for various reasons:
By releasing all available LTPP data, the LTPP program gave data users the opportunity to evaluate data quality concerns relative to their intended analysis objective for themselves.
LTPP Standard Data Release
Another major milestone in LTPP database history, concurrent with the change in LTPP database release policy, was the development of the LTPP Standard Data Release (SDR) in Microsoft® Access®. The idea for the LTPP SDR started with a national review of data by the pavement engineers who were part of LTPP’s technical support services contractor staff. Because of the high cost of licenses for Oracle® (the software used for the LTPP database) and the complexity involved in working with it, the LTPP regional support contractor staff sent the data in Microsoft Access format to the technical contractor for review prior to releasing the data to the public. The Microsoft Access format allowed the pavement engineers to simply “look” at the data, sort the data by fields to find outliers, and perform other automated calculations to detect data anomalies without extensive Oracle knowledge.
The concept for the SDR was born from the recognition that pavement engineers performing research are not likely to have easy access to an Oracle license. Since the Microsoft Access database format was already being used to disseminate LTPP data to the program’s pavement engineers, it was a simple step to make this format available to the public as a standard release format. The only drawback to using Access was that the LTPP database had to be divided into a series of smaller databases due to a 2-GB limit on the size of an Access database. The first LTPP SDR was distributed in January 2003 in CD-ROM format. This was LTPP data release 15 and contained data through summer 2002.
Figure 8.4 illustrates the functional LTPP database flow and QC checks that existed in 2011. Notice that the technical support services contractor no longer reviewed data generated by the Browser program or reran the automated QC checks at the national level. Central checks of the data were manual checks performed by the technical support services contractor based on data issues discovered since the last data upload, changes to existing data modules, new data modules, and verification of action taken by regional support contractors in the DAOFR process. AIMS data were submitted directly to the database archive at FHWA’s Turner-Fairbank Highway Research Center in McLean, Virginia (hereafter called “FHWA’s highway research center”) without formal quality data inspections by the technical support services contractor.
The first LTPP Standard Data Release was issued in January 2003 as SDR 15. It contained data collected through summer 2002.
FIGURE 8.4. Functional diagram of LTPP data processing flow circa 2000 to 2011. The central contractor (technical support services contractor) performs secondary quality control (QC) checks before adding data to the Pavement Performance Database (PPDB) and the Central Traffic Database (CTDB) and preparing the Standard Data Release for delivery to the LTPP Customer Support Service Center (CSSC) at the FHWA Turner-Fairbank Highway Research Center (TFHRC) for distribution. The Data Analysis/Operations Feedback Report (DAOFR) form is used to document data issues and their resolution. Ancillary Information Management System (AIMS) data flow directly from the regional support contractors to the central archive. |
In 2009, FHWA developed a strategic plan to maintain and further develop the LTPP database. This internal document provided for continued customer support service to LTPP data users, public access to the LTPP database via the Internet, and use of the Internet for data submissions by the regional support contractors.
Development of a new LTPP Data Entry Portal (LDEP) began in 2010 and was completed in 2011.7 By creating a single central data entry portal accessible over the Internet, the LDEP reduces program costs for purchasing and upgrading software and equipment in the regional offices and allows for secure and efficient transfer of LTPP data from the regional support contractors through the portal. This change also keeps the LTPP database current with computer technology. To convert the LTPP database to an online system, the following migration process was used:
Figure 8.5 illustrates the greater centralization of data processing that currently exists. The shift from regional database servers to a central database server at FHWA’s highway research center allows secondary central data QC functions to be performed continuously as the regional support contractors enter data. From a logistical viewpoint, centralization also simplifies rollout of new database software and central data updates since the need for consistency in software between the central server and four different regional database servers no longer exists. Updates to software and data are now done only on the central operational database server, and processing and QC checks are carried out in a secure Internet zone. Since the introduction to the Web-based LTPP database, operations are continually refined to keep current with computer technology and to improve overall operations.9,10,11
The other significant operational change in LTPP electronic data file management allowed by the migration to a Web-based paradigm was creation of the AIMS Data Entry Portal (ADEP) within the LDEP. AIMS, which contains raw data forms, images, electronic recorded data, and interpreted data sets, is comprised of a set of electronic files organized into a logical file directory storage structure. It is updated over time as new documents are created from continuing data collection and operational activities. To support periodic updates and changes, the ADEP was set up within the LDEP using the TortoiseSVN open source version control system. Use of this file management software structure now allows the LTPP program to add new files as updates to the central archive instead of performing complete replacements.
FIGURE 8.5. Functional diagram of LTPP data processing flow circa 2011 to present created by integration of LTPP regional databases into the LTPP central operational database. Processing and quality control (QC) checks are carried out in the secure Internet zone. The FHWA Turner-Fairbank Highway Research Center (TFHRC) maintains the Information Management System (IMS). |
Changes in LTPP data storage and dissemination were driven by the rapid increase in data collected and by advances in computing technology. The rising capabilities and falling costs of computer hardware, accompanied by advances in database software, made it possible to keep pace with the challenges inherent in a program of this magnitude. This section describes the computer hardware and software used throughout the years to store LTPP data and information.
The history of the LTPP IMS hardware is outlined in table 8.1, and photographs appear in figure 8.6, figure 8.7, figure 8.8, and figure 8.9.
These changes in computer hardware technology are indicative of the technology challenges faced by the LTPP program. Servers that cost more than $120,000 at the start of the program, with very limited capacity, now cost less than $10,000 with capacities and capabilities that were hard to imagine in 1987.
Between 2006 and 2007, FHWA management began plans to consolidate operations of the LTPP Customer Support Service Center and the IMS from Oak Ridge, Tennessee, to FHWA’s highway research center. This shift in operation started with locating a suitable space at the research center to house the new national database server where the pavement performance data would reside. The AIMS data that support the pavement data were also consolidated at the research center—all of the raw data files, images of paper data forms, and video in electronic format. Relocation of the LTPP IMS was completed in spring 2008.12,13 In 2009, both the pavement performance database and AIMS were installed on the newly purchased, state-of-the-art server at the research center.
Software operating systems and database management systems have changed at a pace similar to hardware changes. The LTPP program has continually updated its software in response to these changes. The LTPP database is a relational database originally implemented in Oracle 5 format. As of this writing, the IMS operating system is Windows Server 2008 and the database is implemented in Oracle 11g. Due to its widespread use, Microsoft Access 2000 is used to distribute the SDR, and both Microsoft Access and Excel® can be used to download LTPP data online.
The Oracle relational database management system (RDBMS) was initially selected by SHRP in 1989 because it was the only RDBMS available at the time that supported different computer operating systems. The initial plan for development of the LTPP IMS was for the regional support contractors to operate the RIMS on Microsoft Disk Operating System (MS-DOS®) personal computers and for the NIMS to run on the VMS operating system used on the UNIX®-based computer operated by TRB. VMS® stands for Virtual Memory System, which provides a multiuser, multitasking environment, and was introduced in 1979 by DEC with the first VAX® minicomputer. The Oracle 5 RDBMS product was selected because it could run on both the MS-DOS and VMS operating systems and included Structured Query Language for data manipulation and maintenance, forms management, menu management, and reporting tools. Also, many third-party products were available at the time that interfaced with this software.14
Over the years, the LTPP program migrated the database software from the initial MS-DOS–based computer operating system platform to Microsoft Windows® platforms. One of the first significant migrations occurred in 1993, when, with the conversion from Oracle 5 to 6, the DOS-based manual data input forms were converted to run under Microsoft Windows using a third-party software package. Some of the manual data entry forms programmed early in the program are still based on an MS-DOS sequential function key-based technology to reduce the programming costs associated with point-and-click technology.
LTPP’s technical support services contractor maintains an internal Software Performance Report (SPR) database that documents all changes to LTPP database software performed by the contractor. The SPR database is an excellent tool that was developed to document and track software-related issues. It contains all critical information: problem description, problem resolution, submission and resolution dates, and other details. SPRs can be submitted by the regional support contractors for problems they have experienced using the LTPP database software or by the technical support services contractor for issues requiring correction.
The next upgrade challenge was to adapt the LTPP custom software to the new 64-bit Windows operating system and Oracle version for the new Dell PowerEdge 2900III installed at FHWA’s highway research center in 2009. The LTPP program has developed a systematic approach based on quality management principles to meet the challenges of implementing new computer software, in order to continue to serve the program’s changing software needs.
Year | Purpose | Model | Capacity | Cost* (each) |
---|---|---|---|---|
1989 | RIMS NIMS |
Compaq® 80386-25DX |
25 MHz, 2 MB RAM, 300 MB hard drive; Everex Cartridge Tape Drive |
$12,500 |
1989 | NIMS | Digital Equipment Corp. (DEC) MicroVAX 3900 |
33 MHz, 32 MB internal memory; maximum I/O rate 3.3 MB/sec; 9-track external tape drive; connected to the Compaq® 386-25 via high-speed Ethernet link | $120,000 |
1992 | Additional traffic data storage apacity in the RIMS |
Optical disk drives | 1,000 MB | $5,000 |
1993 | NIMS, to increase storage and computational speed (about 3 times faster than MicroVAX) |
DEC Alpha 3000 AXP 400 S |
96 MB RAM, 1 GB internal SCSI disk drive; 10 GB external storage (hard drive chassiscontaining three 1.6-GB disk drives, Qualstar® 6250 bpi SCSI 9-track tape drive, and Winchester FlashDAT Turbo single-tape backup subsystem with 4 GB capacity 4 mm tape drive) | $160,000 |
1993 | RIMS, for database storage |
Ideal 486DX2-50 | 50 MHz, 512 MB hard drive, 14,400-baud modem | $7,000 |
1995 | RIMS, for traffic data quality processing |
Micron® Pentium® | 90 MHz | $6,700 |
1997 | NIMS, for database server |
Compaq ProLiant 1500 5/166P |
Pentium®, 166 MHz, 4.3 GB hard drive storage | $35,000 |
2001 | NIMS, one each for production database and test database RIMS |
Dell™ PowerEdge™ 4400 |
Dual Intel® Pentium III Xeon®, 1 GB SDRAM, 5 No. 36-GB 10,000 RPM SCSI hard drives in a RAID-5 array, DLT4000 40/80 GB internal tape backup, uninterruptible power supply | $11,000 |
2001 | NIMS RIMS |
Dell Precision 530 Workstation |
Dual Intel Pentium III 1 GHz processor, 786 GB of 800 ECC RDRAM, 40-GB hard drive, 12X.8X/32X CD read-write drive, 16X DVD read drive | $3,200 |
2005 | NIMS | Dell/EMC AX100SC external Storage Area Network Fibre Channel |
1 TB storage | $9,300 |
2007 | NIMS, to replace PowerEdge 4400 |
Dell PowerEdge 2900 | 2 Dual-core Intel Xeon 5120 1.8 GHz processors, 2 GB RAM, internal RAID-5 hard drive array, 876 GB storage, PowerVault™ 110T-LTO2-L tape backup, 2200VA uninterruptible power supply, external 500 GB USB disk drive, 48X IDE CD-RW/DVD-ROM drive |
$8,300 |
2009 | NIMS, for both LTPP database and AIMS |
Dell PowerEdge 2900III | Dual quad-core Intel Xeon 5450, 3.0 GHz processors, 32 GB RAM, internal RAID-5 hard drive array, 8 TB storage, external RD1000 USB drive with removable hard disks for data backup, 2200VA uninterruptible power supply, 16X DVD-ROM | $10,500 |
2011 | Central LDEP Web server |
Dell PowerEdge R510 | Dual 6-core Intel Xeon 5675, 3.06 GHz processors, 32 GB RAM, 1 TB RAID 1 hard drive array (two 1 TB drives) for the OS, 12 TB RAID-5 hard drive array (eight 2TB drives using one as a hot spare) for data, external RD1000 USB drive with removable hard disks for data backup, USB hub | $16,700 |
RIMS = Regional Information Management System; NIMS = National Information Management System; AIMS = Ancillary Information Management System; LDEP = LTPP Data Entry Portal. * Cost shown in dollar value for the year the equipment was purchased. |
FIGURE 8.6. DEC MicroVAX 3900 computer running the UNIX® operating system, used as the first LTPP National Information Management System (NIMS) server from 1989 to 1993. |
FIGURE 8.7. The LTPP DEC Alpha 3000 AXP 400 S computer system running the UNIX® operating system, used for NIMS server functions from 1993 to 1997. |
FIGURE 8.8. Compaq® ProLiant 1500 server running Windows® NT 16-bit operating system, used for the central database server 1997 to 2001. |
FIGURE 8.9. Dell™ PowerEdge™ 2900III installed in May 2009 at FHWA’s Turner-Fairbank Highway Research Center to serve as the secure central repository for LTPP electronic data into the future. The server contains 8 TB disk storage, dual quad core Xeon® 3 GHz processors, 32 GB RAM, and the Windows® Server 2008 64-bit operating system. |
The LTPP program stores the majority of the performance data collected from the LTPP test sections in an electronic relational database format. In addition, the program stores raw data files and other information about the test sections in AIMS.
The pavement performance data are stored in a relational database, meaning that it is composed of separate, but related, tables of data. All data are stored in simple row/column format tables. Rows are referred to as records and columns as fields. Each row of data in a table is uniquely identified by the values in a primary key column or a combination of columns. In addition, relationships exist among the tables of the database that are represented by common data values stored in more than one table. For example, many data tables contain State code and SHRP identification columns, which uniquely identify the test sections and projects. These fields are used to locate or join data for a specific test section from different tables.
Database Modules
The data storage tables in the LTPP database are organized into modules containing similar tables. With the exception of the tables in the Administration module, the first part of the table name identifies the module to which a particular table belongs. In the LTPP SDR, the modules are as follows:
Administration (ADM)—The master test section control table consisting of metadata tables that describe the structure and content of the database, and the general comments tables.
Automated Weather Station (AWS)—Site-specific climatic information measured at automated weather stations installed near almost all Specific Pavement Studies (SPS) -1 (structural factors for flexible pavements), -2 (structural factors for rigid pavements), and -8 (environmental effects in the absence of heavy loads) project sites.
Climate (CLM)—General environmental information from government-operated weather stations located near test sections. Data may be from a single site within 7 mi (11 km) of the section or from a site-specific statistical estimate based on sites within a 50-mi (81-km) radius.
Data Compilation Views (DCV)—Data compiled from other existing tables with the primary intent of reducing the number of tables a user needs to examine for similar types of data elements.
Dynamic Load Response (DLR)—Dynamic load response instrumentation data from SPS test sections located in North Carolina and Ohio.
Ground Penetrating Radar (GPR)—GPR measurements performed on a subset of SPS-1, -2, -5 (rehabilitation of asphalt concrete), and -6 (rehabilitation of jointed Portland cement concrete) sections performed in 2003.
Inventory (INV)—Inventory information for all GPS test sections and for SPS sections originally classified as maintenance and rehabilitation experiments. Tables in this module contain general pavement information on the sections’pavement structure prior to their inclusion in the LTPP program.
Maintenance (MNT) and Rehabilitation (RHB)—Maintenance and rehabilitation data are combined into one module in the SDR because they are closely related. The data tables, however, are identified by MNT or RHB in the table names.
Monitoring (MON)—A series of submodules organized by data type. The submodules contained in the MON module are deflection, photographic distress, manual distress, drainage, friction, longitudinal profile, and transverse profile distortion (rutting).
Deflection (MON_DEFL)—Deflection measurements from falling weight deflectometer (FWD) testing, pavement temperature gradient data measured during FWD testing, and computed parameters based on FWD measurements. The names of all tables in this submodule begin with “MON_DEFL.”
Distress (MON_DIS)—Distress survey data from both manual and film-based surveys that include the amount and severity of cracking, patching, and potholes and the existence of surface deformation, joint defects, and other types of pavement surface defects.
Drainage (MON_DRAIN)—Information on the inspection of subsurface drainage features on selected SPS-1, -2, and -6 test sites.
Friction (MON_FRICTION)—Friction measurements performed by participating highway agencies.
Profile (MON_PROFILE)—Longitudinal profile data collected by automated inertial profiler or by manual Dipstick® measurements.
Rutting (MON_RUT)—Rutting data measured using a 1.2-m (4-ft) straightedge.
Transverse Profile (MON_T_PROF)—Transverse profile data and computed transverse profile distortion indices (rut depth) from manual Dipstick measurements or the optical Pavement Distress Analysis System (PADIAS) method.
Seasonal Monitoring Program (SMP)—SMP-specific data, such as the onsite air temperature and precipitation data, subsurface temperature and moisture content data, and frost-related measurements.
Specific Pavement Studies (SPS)—Construction and general information for SPS test sites. SPS test sites that were newly constructed for the LTPP program are part of the SPS-1, -2, -8, and -9 (Superpave®) experiments. SPS-3 (preventive maintenance of flexible pavements), -4 (preventive maintenance of rigid pavements), -5, -6, -7 (bonded Portland cement concrete (PCC) overlay of PCC pavements), and -9 consist mainly of existing pavements with experimental maintenance or rehabilitation treatments. SPS-9 contains both newly constructed and pre-existing pavements.
Traffic (TRF)—Traffic load, classification, and volume data.
Test (TST)—Field and laboratory materials testing data from LTPP test sections.
Detailed technical information on all tables contained in these LTPP database modules is available in the LTPP Information Management System User Guide.15 Due to the changing nature of the LTPP database, this guide is updated for each data release and is also included in the SDR in the LTPP Reference Library. The IMS User Guide includes tutorials on common questions such as how to find linked materials data on SPS test sites. Prior to the release of SDR 28 in January 2014, the previous versions of this guide were referred to as the LTPP Information Management System, Pavement Performance Database User Reference Guide.16 The name of the guide was changed because information on AIMS and LTAS was added.
Computed Parameters
A primary consideration in the design of the LTPP database was to disseminate data in their most disaggregated “raw” form; however, occasionally computed parameters have been added to the database for the data user’s convenience. Computed parameters are aggregations, computations, summarizations, or interpretations of raw data to derive new data elements. The LTPP program policy on incorporating computed parameters, which at one time were called “computed quantities,” was first established in 1996.17 In 2000, a new program policy changed the name to “computed parameters” and defined the roles of those involved with their creation.18
Computed parameters are aggregations, computations, summarizations, or interpretations of raw data to derive new data elements.
Some computed parameters are standard indices or data concepts with broad acceptance, such as soil classification following the methodology of the American Association of State Highway and Transportation Officials. Others are statistical representations of repeat measurements such as average and standard deviation. Still others are more complex derivations from multiple sources of raw data such as equivalent single-axle load, rut depth from transverse profile measurements, and backcalculated pavement layer moduli from FWD and pavement thickness measurements.
Most of the computed parameters contained in the LTPP database are internally computed. This means the parameters are computed by the database software as part of the normal processing and storage of raw data. Examples of internal LTPP computed parameter include:
External computed parameters contained in the LTPP database are those where data were extracted from the database at some point in time, calculations performed external to the LTPP program, and the resulting computed parameters entered into the database. The primary operational issue with external computed parameters is updating or changing quality labels for the computed parameters when changes are made to the input data. External parameters included in the LTPP database are those where significant engineering expertise and computation resources are needed that are not available to many data users. In concept, provision of these complex computed parameters will promote many types of analysis efforts using LTPP data at lower cost to the sponsoring agency. Examples of the external computed parameters in the LTPP database include:
Like the other tables in the LTPP database modules, detailed technical information on computed parameters is included in the IMS User Guide.19
The LTPP database was intended to disseminate as much raw data as possible, but some raw data containing information on the performance of test sections were not included in the database due to cost and other practical reasons. The objective of AIMS is to provide a central source of information and data that are not available in the pavement performance database, are frequently requested by LTPP data users, or provide a historical record of data reported on paper data forms. Table 8.2 lists the data contained in AIMS.
Data Type | Electronic Files |
---|---|
Falling weight deflectometer data |
|
Longitudinal profile data |
|
Transverse profile data |
|
Pavement distress data |
|
Traffic data |
|
Digitally scanned paper data collection forms |
|
Digitized test section videos |
|
AIMS data are stored in the LTPP IMS at FHWA’s highway research center. The data and images are stored electronically using a defined directory structure and file-naming convention.20 Access to a large portion of these data is now available through the LTPP InfoPave™ Web interface.
In 2011, the Central Traffic Database became a component of AIMS, having been managed separately as a repository of agency-supplied data from the initiation of data collection. The database contains traffic data processed through LTPP software that was used to compute the annual estimates contained in the pavement performance database. Traffic data are reported in daily, hourly, and per-vehicle record formats for traffic volume, vehicle classification, and truck gross vehicle and axle weights.
In a long-term research program, the number of data elements naturally increases over time as new observations are added. The following time-series graphs illustrate changes in some of the significant data elements that help to explain pavement performance.
The time-series graphs illustrate the general trend in increase of data over time; however, some decreases also occurred due to data quality concerns, changes in data collection/measurement technology, and changes in data release policies.
Another interesting point to note in the following graphs is the magnitude of LTPP data. The LTPP database now contains the most extensive source of detailed engineering data and information ever collected on the performance and properties of modern highway pavements.
FIGURE 8.10. Historical changes in the number of FWD data sets contained in LTPP data releases. |
The history of FWD data in the public data release can be traced back to the beginning of the program. The first release of FWD data occurred in July 1991. Figure 8.10 illustrates the growth in LTPP FWD data sets over time based on record counts in the deflection master table. One record exists in this table for each set of FWD measurements performed on a test section during a calendar day. The apparent decrease in the 1992 data release represents a change in LTPP QC processing, since only level-E data were released during this time period. The flat line from 2005 to 2009 represents a reduction in FWD measurement frequency due to budgetary constraints. The increase in number of measurements after 2009 reflects the change in LTPP monitoring policy to renew FWD testing but at a lower intensity on fewer test sections.
To illustrate the large volume of data stored in the LTPP database, figure 8.11 shows the growth in the number of individual deflection measurement data since 2002. At each test point, the LTPP FWD data set contains the measured deflection basins of up to four drops from up to four drop heights. Analyzing the more than 9 million FWD deflection measurements accumulated through 2013 is a significant task.
FIGURE 8.11. Growth in number of FWD basin and load transfer measurements contained in the LTPP database since 2002. |
Measurement of the longitudinal profile of a test section is how the LTPP program computes pavement roughness parameters. Figure 8.12 shows the number of profile measurement data sets contained in the LTPP database. The LTPP measurement protocol requires five repeat profile measurements to be stored in the LTPP database for each measurement data set performed by high-speed road profilers, and one data set for manual measurements performed using the Dipstick® device. The amount of filtered profile elevation data stored in the database depends on the measurement device. A longitudinal profile measurement data set from a high-speed road profiler contains around 2,000 data points using a 6-inch (152.4-mm) or 5.9-inch (150-mm) moving average filter. Dipstick measurements are recorded every 12 inches (304.8 mm), however, so only 1,000 data points are stored in the database for a test section that is 500 ft (152.4 m) long.
FIGURE 8.12. Growth in number of longitudinal pavement profile measurements. |
Three different types of pavement surface distress data are stored in the LTPP database:
Figure 8.13 shows the growth in number of pavement surface distress measurements contained in the LTPP database starting in 1992. The PADIAS 4.2 interpretation process for the 35-mm distress images was introduced in 1997. Over time, the images interpreted using the older PADIAS method were reinterpreted using the 4.2 method. The PADIAS method used a grid coordinate system for plotting and measuring surface distresses and the PADIAS 4.2 used a vector system. Data from the two methods were basically the same, and after a survey had been reinterpreted, the previous PADIAS data were removed from the database. Most of the PADIAS images that have not been reinterpreted are from test sections in the SPS-3 and -4 experiments for the period 1989 to 1992, due to funding limitations.
FIGURE 8.13. History of LTPP pavement surface distress surveys. Decline in PADIAS distress survey data is due to replacement with PADIAS 4.2 reinterpretations of the same images. |
Transverse profile measurements are used to characterize different aspects of the pavement surface, such as rutting and pavement cross slope, on both AC- and PCC-surfaced pavements. As noted in chapter 6, two methods have been used by the LTPP program to measure transverse profile. Because the photographic method was not capable of measuring the cross slope, transverse profiles are stored normalized to the begin- and endpoints in the database.21 However, since the Dipstick does measure the true elevation difference between begin- and endpoints, starting in 2004, this elevation difference was added to the database in the transverse profile cross-slope table. This is why in figure 8.14 there is a spike in cross-slope data starting in 2004.
FIGURE 8.14. Increase in transverse profile measurements since 1996. The collection of cross-slope data began in 2004. Cross-slope data allow for evaluation of water retention, which has the potential to produce hydroplaning at the pavement surface. |
The LTPP program performed direct climate measurements at test sections included in the SMP and at SPS-1, -2, and -8 experiments that were instrumented with automated weather stations (AWS). The LTPP program developed QC software and data edit programs to check this data and make adjustments for daylight saving time shifts. As discussed in chapter 7, data collection for the SMP began in August 1992 and was terminated in October 2004.22 LTPP AWS data collection began in August 1994 and was terminated in December 2008.23 The LTPP program attempted to provide as much data as possible, but the hourly data are not continuous over the collection period due to equipment malfunctions and breakdowns. Figure 8.15 illustrates the massive amount of hourly climate data collected by the LTPP program.
FIGURE 8.15. Growth in number of hourly climate data measurements collected by the LTPP program as part of the Seasonal Monitoring Program and automated weather station data collection efforts. Decreases in the time-series represent the result of quality control checks to remove suspect data. |
Figure 8.16 shows the growth in the total number of records in the materials test data module starting in 1996. The total number of records is a relative indicator in the growth in materials data because during this time period changes were made to some of the internal data tables that did not result in the addition of more data. An example of this is a drop in the number of records in 2004 caused by removal of administrative tables TST_L06 and TST_L07, which were used to track materials samples and did not contain usable material test data. However, the increase in the total number of records in the materials testing module clearly shows the impact of the Materials Action Plan that was implemented to address missing materials data on SPS projects.
The LTPP program invested significant resources in developing a research-quality test on the measurement of the resilient modulus of AC from field samples. (Development of the LTPP resilient modulus protocols is discussed in chapter 10.) Materials test data from the first LTPP P07 test protocol were removed from the database in 2000.24 Version 2 of the P07 protocol had been developed, which in addition to resilient modulus includes creep compliance and indirect tensile strength measurements. Figure 8.17 shows the growth in the amount of P07 version 2 data.
FIGURE 8.16. Increase in total number of records in the materials test module starting in 1996. The decrease in records in 2004 was due to removal of two administrative tables from the test module and not to a decrease in available measurement data. |
Dissemination of information is one of the stated objectives of the LTPP program. The program’s primary information distribution effort is the periodic macro release of “raw” data for use by scientist, engineers, and researchers for engineering-based analysis. The program also publishes and distributes research reports, data collection guidelines, and other documents related to pavement performance data collection and pavement research.
The LTPP program dissemination efforts comply with Federal information dissemination guidelines that were issued by the Office of Management and Budget on January 2, 2002, to implement the Data Quality Act, sometimes referred to as the “Information Quality Act” (title 5, section 515, Treasury and General Government Appropriations Act for Fiscal Year 2001).25,26 The purpose of the Federal guidelines is to ensure and maximize the quality, utility, objectivity, and integrity of information that is disseminated by Federal agencies.
FIGURE 8.17. Growth in materials data for resilient modulus (Mr), creep compliance, and indirect tensile strength (IDT) using the P07 version 2 test protocol. |
The U.S. Department of Transportation consequently established policy on information quality for the department’s agencies. This policy resulted in FHWA developing its Information Quality Initiative (see sidebar).27 In 2008, the LTPP program issued a formal report on compliance with the Federal guidelines (Long-Term Pavement Performance Compliance With Department of Transportation Information Dissemination Quality Guidelines) that includes issues related to publications and disseminated summaries of data, micro data releases, source and accuracy statements, and pre-dissemination reviews.28
This section outlines LTPP data dissemination efforts through periodic releases of data, the development of software tools to aid data users, and, ultimately, online availability. As technology has changed, the program has adapted its methods to provide ease of access and improved functionality to users.
In response to the Data Quality Act, FHWA established the Information Quality Initiative, which promoted the Federal guidelines for dissemination of data and other information to the public. |
|
Release No. | Date | ZIP Size (GB) | Primary Format |
---|---|---|---|
1 | January 1991 (data on 226 test sections) | N/A | N/A |
2 | July 1991 | N/A | N/A |
3 | January 1992 | N/A | N/A |
4 | July 1992 | N/A | N/A |
5 | January 1994 | N/A | N/A |
6 | September 1994 | N/A | N/A |
7 | February 1996 | N/A | N/A |
8 | September 1997 | N/A | N/A |
9 | January 1999 | N/A | N/A |
10 | October 1999 | N/A | N/A |
11 | January 2001 | N/A | N/A |
12 | January 2002 | N/A | N/A |
13 | March 2002 | N/A | N/A |
14 | July 2002 | 1.91 | D |
15 | January 20031 | 2.15 | D |
16 | July 2003 | 2.14 | D |
17 | January 2004 | 2.24 | D |
18 | July 2004 | 2.33 | D |
19 | January 2005 | 2.57 | D |
20 | October 2005 | 2.52 | DVD |
21 | January 2007 | 2.56 | DVD |
22 | January 2008 | 2.58 | DVD |
23 | January 2009 | 2.85 | DVD |
24 | October 20102 | 4.02 | DVD |
25 | January 2011 | 5.28 | DVD |
26 | January 2012 | 4.47 | DVD and thumb drive |
27 | January 2013 | 4.67 | Thumb drive |
28 | January 20143 (data on 2,509 test sections) | 4.87 | Thumb drive |
1 The January 2003 data release was the first Standard Data Release-—the first release in Microsoft® Access® format and the first to contain data at all quality control levels. 2 The October 2010 data release increased in file size due to the addition of traffic tables, which were removed in the January 2012 data release. 3 The January 2014 data release is the first Standard Data Release available on the LTPP InfoPave™ Web site. LTPP InfoPave contains the first public release of the LTPP AIMS data. |
Table 8.3 provides the sequential release numbers assigned to the major LTPP database releases and their release dates. In the early years of the program, data releases contained partial data sets by module. For example, the first data release contained mostly inventory data from GPS test sections. In the mid-1990s, partial database uploads by module, assigned fractional data release numbers, were common. These fractional data release numbers are not shown in table 8.3.
The LTPP data release policy has also changed over the years. In the early years of the program, only data that passed all LTPP data quality checks were made available to the public, and a fee of $77 to $100 was charged for each extraction to partially defray the cost of fulfilling the request. Participating highway agencies could obtain all of the data from test sections in their jurisdiction at no charge. In November 2002, the LTPP program changed the data release policy to provide access to all data regardless of the quality level and to provide data in the standard release format free of charge.29
While data users can still request custom extractions of data from the database in specific formats, these requests have been minimal since the introduction of the SDR in Microsoft Access format.
The following principles currently apply for release of LTPP data and information:
LTPP Standard Data Release
The LTPP SDR is an extraction of all data from the central LTPP database, split up and formatted as a series of Microsoft Access databases (based on the North American software version). In addition to the data, the SDR includes updated software and documentation specific to the contents of the data release, together with the following significant elements:
Since the first SDR was issued in January 2003, the most up-to-date data from the LTPP program are distributed in this format on an annual basis free of charge to data requesters. Data at all quality levels, without restriction, are included in the release.
As computer technology has evolved, the LTPP program has developed new and more efficient ways to make the data available to the pavement community. The program has engaged the State and Provincial agencies, industry, and academia partners in beta testing the software to ensure that users are able to access the pavement data provided in a format useful to them. The LTPP program continues to involve its partners and other users of the LTPP data in developing dissemination tools.
LTPP Data Sampler and Data Request Program
The earliest software developed to aid users of LTPP data was the Data Sampler and Data Request Program, developed by the LTPP program. Before the program started distributing the data, this software allowed pavement engineers, researchers, and others to select and request the data using a standard data request form. The form was submitted to FHWA via the technical support services contractor, who would follow up with the data requestor to make sure the data being prepared to send to the requestor was appropriate for the requestor’s use.
Made available to the public in Version 5 on 5.25-inch floppy disk as early as January 1994, the sampler program helped users view and navigate the summary GPS data and request comprehensive data on selected sections. Version 7, released in early 1997, added features that allowed users to create their own data files using GPS data ordered from the LTPP program. It included a sample of the most up-to-date inventory, climate, traffic, layer material, and deflection data available for GPS sites.30, 31
DataPave
DataPave was a CD-ROM–based product developed by the LTPP program to disseminate LTPP data in a user-friendly format. Its graphical user interface program was designed to help a data user select, view, and extract LTPP data of interest. Development of the DataPave program was based on the LTPP Data Sampler and Data Request Program.
Three versions of DataPave were produced by the LTPP program. Version 1 and 1.1 were released in 1997, Version 2 in 1999, and Version 3 and 3.1 in 2001. Version 3, released in November 2001, was the first to include the new numbering system that reflected maintenance and rehabilitation activities performed at a section. Version 1 required a single CD-ROM; versions 2 and 3 required two CD-ROMs. Due to data storage limitations, the DataPave CD-ROM did not contain all available LTPP data. After production of DataPave 3.1, creation of the CD-ROM version of the program was discontinued due to the development of DataPave Online in 2002 and the LTPP SDR.
DataPave Online
The LTPP DataPave Online program provided access to LTPP data through a user-interactive format. It was designed as a training tool for users of LTPP data who may not have been acquainted with the use of database technology. The online version of DataPave limited a user to simple queries and downloads of a relatively small amount of data at a time. Users desiring access to large amounts of data were encouraged to obtain a copy of the SDR.
LTPP InfoPave™
The newest data dissemination tool, LTPP InfoPave, was released in January 2014 (figure 8.18). LTPP InfoPave is an interactive Web portal to the world of LTPP data, providing on-demand, integrated access to LTPP products and the entire scope of the LTPP IMS—the complete database, ancillary information in AIMS, and the LTPP Reference Library—through an interface that is easy and quick to use. LTPP InfoPave replaces DataPave and LTPP Products Online (discussed in chapter 10) and encompasses the SDR with the added option to obtain data releases for individual States/Provinces.
The system’s software allows users to prepare customized searches, download data in Microsoft Access or Excel, generate customized reports, and personalize the LTPP InfoPave home page to their needs. The maps feature (figure 8.19) shows the LTPP tests sites throughout the United States and Canada and allows users to select data for one or multiple test sites. The contextual search feature connects the user to processed data, raw data, images, video, and reports. In addition, new features will include predefined, ready-to-use data sets that target specific analyses, prepared by expert data users; seamless activation of data analysis tools; and an interactive learning center to familiarize users with the system’s features and use of LTPP data.
Highway agency staff and other pavement researchers participated in the design of LTPP InfoPave through focused Webinars that solicited data users’opinions on the portal’s features and functionality. Refinement of the system with user input will continue during the coming years.
FIGURE 8.18. Home page of the LTPP InfoPave™ Web site. |
Since the LTPP program started disseminating data, customer support has been vital in helping users understand what data are available, in what formats the data can be provided, and how the data can be used to answer their pavement performance questions. The program’s customer support service function has changed over the years. After 1995, when responsibility for the database was transferred from TRB to FHWA, data distribution functions were transferred to the technical support services contractor. In 1997, when the database operation, engineering specifications, computer programming, and management functions were merged into a single contract for central technical support of the program, the synergy of direct interactions among engineers, programmers, and data delivery staff led to rapid improvement in the quality of data delivery and user support functions.
It was not until 2002 that the LTPP customer support service function was formalized and assigned to the technical support services contractor. The purpose of the LTPP Customer Support Service Center is to provide a single point of responsibility for the program in responding to requests for data and technical questions from data users. The traditional customer support function was preparation of the SDR, support documentation, and user aids for release to the public.
In 2006, due to program funding limitations, FHWA management moved the LTPP Customer Support Service Center to its highway research center, where it is operated under supervision from the program staff with support from an onsite contractor. The support center still operates as the single point of contact for LTPP data and information requests. As an onsite activity, the support center can provide reduced response times and access to other FHWA pavement resources.
FIGURE 8.19. LTPP InfoPave’s interactive map feature, showing the locations of LTPP test sections. |
In addition to disseminating the pavement data, the LTPP program makes available a host of documents that were created as part of the program that others can use or reference, such as data collection guidelines and reports from previous LTPP research projects. These documents are physically housed at FHWA’s highway research center. The vision for the LTPP document collection is to have at least one hard copy of all LTPP program documents and publications along with an electronic copy of each. The current LTPP electronic library is distributed as the Reference Library in the SDR package on DVD and is available at the LTPP InfoPave Web site.
Since the beginning of the LTPP program, data security has been a prime issue based on lessons learned from the American Association of State Highway Officials (AASHO) Road Test. Although some loss of LTPP data has occurred due to problems in field data equipment, LTPP data collection protocols contain instructions on data backup procedures to prevent data loss from faulty field data collection equipment. No significant loss has occurred to data entered into the LTPP IMS.
As described earlier, prior to fall 2011, the LTPP program used a distributed data collection structure that culminated in a central production database. The distributed data collection structure was operated by the four regional support contractors, who collected, processed, checked, and entered data into their respective regional databases. The regional databases were uploaded annually into the central, secure LTPP production database operated by the technical support services contractor. Security was maintained by the LTPP technical support services contractor and at the respective LTPP regional support contractor offices. Many of the earlier security measures are documented in Long-Term Pavement Performance, Compliance with Department of Transportation Information Dissemination Quality Guidelines.32 These protections continue.
In 2008, the LTPP program began to centralize the program’s databases—pavement performance and central traffic databases—along with its AIMS data and other electronic and physical documents at FHWA’s highway research center to provide a secure central location for the invaluable information collected since the program began in 1987.
Since September 2011, LDEP, the central data entry Web portal leading to a production database, has been operated by LTPP’s technical support services contractor. LTPP’s regional support contractors are still responsible for collecting, processing, checking, and entering data. The data are now entered, however, through the centralized Web-enabled system and are uploaded on a continual basis instead of annually. This production database is used to update the central national archival IMS periodically at FHWA’s highway research center. Security measures continue at the offices of the regional support and technical support services contractors, and additional security procedures have been established at FHWA’s highway research center.
In 2011, the LTPP program completed the transition to a new state-of-the art server that has adequate storage capacity for the entire IMS—the central production and AIMS databases and the LTPP library—and an electronic archive of the IMS. To secure the system, the following measures are currently enforced:
LTPP compliance with the “Security of Federal Automated Information Resources” circular ensures that the data will be secure from unauthorized data modification, destruction, and loss. No significant loss has occurred to data entered into the LTPP IMS.
The Office of Management and Budget Circular A-130, Appendix III, “Security of Federal Automated Information Resources,”33 requires agencies to perform a review of the security controls within each system and formally approve the system’s operation. The LTPP program has completed the security process and is following the established guidelines. Compliance with these extensive standards means that LTPP data will be secure from unauthorized data modification, destruction, and loss.
Data backup procedures are in place at every level of the LTPP IMS. This section outlines the backup provisions for the program’s central server at FHWA’s highway research center.
The LTPP central server is currently a Dell PowerEdge 2900 server running Windows Server 2008, service pack 2. It has two 3.0 GHz Xeon E5450 dual core processors. It contains one 8-disk RAID 5 array with 8 TB of storage. RAID 5 is able to recover from a single drive failure because parity information is striped across the disks. Therefore, if one, and only one, disk is corrupted, the system will continue to run. The drives are hot-swappable, so a faulty drive can be replaced, and it will be rebuilt automatically using the parity information stored on the other drives. The operating system, the Oracle software, and database instances are stored on this RAID 5 array. It also has two attached 15-disk RAID 5 arrays for a total of 50 TB of additional storage.
The server is protected from power failures by an uninterruptible power supply, Smart UPS 2200, which was purchased with the server. The server is on a circuit that is powered by an emergency generator to support uninterrupted operation.
The LTPP database system does not have critical uptime requirements; however, scheduled down time is minimized by doing the majority of the backup during nonbusiness hours. Daily backups are not deemed necessary due to the low volume of updates to the LTPP database. Major changes to software or the content of the database are received electronically and can be recreated in the case of system failure. Because recovery of every transaction to the point of failure is not necessary, all recovery is performed by restoring all the data files from a cold backup and restarting the database. The server is partitioned to contain different segments of the IMS, and the backup procedures for the segments vary according to the level of activity they experience, as outlined in table 8.4.
Server Segment | Update Cycle | Full Backup | Incremental Backup |
---|---|---|---|
Operating system | Daily | Biweekly | Alternate days |
Working storage; workstation backup | Daily | Biweekly | Alternate days |
Ancillary Information Management System | Quarterly | Quarterly | Not applicable |
Traffic | Daily | Biweekly | Alternate days |
Standard Data Release database | Quarterly | Biweekly | Not applicable |
Production database | Daily | Biweekly | Alternate days |
Test database | Daily | Biweekly | Alternate days |
Recovery | Not applicable | Quarterly | Not applicable |
Archive of historical data/software | Quarterly | Quarterly | Not applicable |
The LTPP database came into being in 1989 and has been successfully adapted to the many changes in computer hardware and software technology over the years. The database represents a significant investment of resources. The quality management features of the LTPP database, implemented before the development of formal quality management standards and mandated Federal quality and security guidelines, have resulted in a well-documented and robust national data archive of pavement research data. The database security procedures implemented by the LTPP program assure the preservation of all LTPP data; there will be no loss of data as occurred with the AASHO Road Test data, where many of the data were lost because they were not converted as technology changed over the years.34
The LTPP program has amassed the largest and most comprehensive engineering data set on the performance of modern pavements in the world. The LTPP database spans the pavement engineering spectrum from time-series distress and roughness measurements to detailed measurements of changes in pavement materials due to climate and response of pavement materials under loading. LTPP InfoPave, launched in 2014, is a great leap forward in providing continuous access to the database, AIMS, pavement research, software, and other LTPP products.
Today, the LTPP database can be described as a complex, rich, research data warehouse that, to be used efficiently, requires some knowledge of the program. The LTPP program can claim successful accomplishment of the sixth major objective for the program listed in the 1986 research plan:35 A national long-term pavement performance database has been established and is improving continually. Maintaining data quality is an important function of the program that is discussed in the next chapter.