|FHWA > Asset Management > System Management & Monitoring > PMS Data Example > 4. Characteristics of PMS Databases - Ideal and Actual|
Use of PMS Data for Performance Monitoring with Superpave as an Example
4. Characteristics of PMS Databases - Ideal and Actual
Generally PMS databases reflect three levels of data collection: network, project and research. The most general and the most widely used is network level data collection which normally reflects three sublevels:
In most cases state DOTs collect only the minimum required data and in some cases even less than is considered minimally required as discussed below.
The project level involves a much more detailed data collection effort and one, which is not currently collected for inclusion in a PMS. It involves detailed design and as-built data on individual pavement sections including thickness, material strengths, variability, stiffness and ultimately forensics analysis of pavement failures. These data vary with the type of project being considered, but will be presented here at two sublevels:
The third pavement management level involves research and evaluation and in some cases includes forensic information. To be most valuable the research level database will involve several sections or projects where the set of sections or projects combine to form a factorial or set of sections that can be compared for evaluation of material specifications, construction methods and design. All state DOTs have these kinds of data. It is used every time a new method is employed or a new construction procedure is tested. Unfortunately the data seldom get entered electronically into the organized pavement management database. Thus it seldom gets properly tied to the pavement management identification location. It is critical in the Superpave evaluation activities for example to set up this database in electronic format on a permanent basis. The Superpave example can also be expanded to other concepts by state DOTs as discussed later. The exact details of this research/evaluation database will depend on the individual studies.
4.1. Details of a Desirable Network Level Database
Most state DOTs currently maintain an electronic format PMS database. It is necessary to do so if pavement management is to function successfully. In this portion of the report, the desirable characteristics of a network level PMS database are compared to the characteristics of such network level databases found in the five states visited.
In any network level PMS database the roadway network must be divided into sections and subsections. A file is set up for each section or subsection with appropriate location identification information including beginning and end coordinates and mile points, direction, lane, roadway, and any other information which uniquely defines a section of roadway, preferably one lane wide and a finite distance long. Care must be taken to differentiate lanes and roadways, e.g. for interstate highways with frontage roads.
The physical characteristics of each section should be recorded including age of construction and/or subsequent reconstruction or overlay, type of pavement, surface or wearing course as a minimum. It is also desirable to store the thickness of individual layers, their age of construction, and as-constructed properties, including strength and stiffness. However, these last factors are seldom available in a network level database since the database is usually set after most of the pavements were constructed. Nevertheless, space should be provided in the network level database for layer properties, thickness, stiffness, and strength.
For typical network level activities such as ranking, prioritization, and optimization, one or more performance indicators is required. The first priority among these indicators is a serviceability or roughness index defining the quality of service that the pavement section is providing to the user. The history of this serviceability versus time provides a practical performance curve for each individual section.
A yearly record of distress or condition of each section is needed and can be used to define treatment options, projected costs, and predict it's serviceable life. The average surface friction of each section should also be collected to provide safety information. In most instances, surface friction is not collected network wide but is collected and stored in a separate database related to skid resistance.
The performance indicator measurements should be taken annually as a minimum. In some cases, these data should be taken more frequently. For example, when a new overlay is placed, it is desirable to measure the roughness and the distress prior to overlay and the roughness immediately after the overlay. In this way, the benefits of the overlay can be evaluated more effectively. If it's not possible to enter this before and after information in the network level database, it should be included in the project level database.
A measure of behavior, usually deflection measurements, is needed but is not commonly collected at the network level. In those cases where it is collected, it should be recorded electronically and keyed to the PMS database. A separate sub-file will be preferable to a sparsely filled network wide file. With modern, personal computers, it is easy to maintain an appropriate interface to move these data from one place to another as needed.
4.2. Network PMS Databases in Actual Practice
All PMS databases contain at least the following information: location of the pavement section (county, district, road nr., mile post, lane, direction), type of pavement, age, traffic (AADT, CESAL) and performance indicators for ride, cracking, rutting and friction, together with the year of testing. More sophisticated databases have additional data on the existing pavement (last rehab, project number, layer materials and thickness), environmental data (regional factor, climate) and more extensive performance data for patching, flushing and maintenance work. The majority of PMS databases, however, give little or no information on types of materials, layer thicknesses and construction details. Available traffic information is often unreliable. Nearly all databases differ in the way detailed data are recorded. Some agencies record AADT per direction, others take the average of two directions. The way AADT is divided over lanes can also differ. The direction can be recorded as a compass direction (N, S etc), or increasing/decreasing with mile posts (I or D). The distress data are normally converted into a performance index or rating, but the way this is done differs by state. The criteria used by states for judging the indicators also differ widely.
*) See also Section 8 for additional information on distress ratings in the five states.
Having reviewed the required and desirable network level database it is valuable to examine what performance data are actually being collected at the present time, and in what way these performance data are converted into a performance index or rating. In this process we have a sampling of information from five states, Maryland, Indiana, Florida, Arizona and Washington. Table 1 shows the performance indices for Ride, Rutting and Cracking that were reported in visits to these states. Additional information was obtained from their pavement management system and the hard copies of electronic files of data provided to the project team.
It can be seen from Table 1 that there is some diversity in the actual performance indices reported by state DOTs at the present time. The same is true for the definition of the condition limits. It must also be remembered that each state has individual needs within their agency, which will dictate their database characteristics. However, great benefit can accrue nationwide if the minimum desired network level data is recorded by every DOT. States are encouraged to review and modify their data collection efforts in this regard. It is also highly desirable that the data be collected uniformly nationwide. Currently AASHTO is evaluating data collection protocols, which would be very useful for this purpose [FHWA 97].
4.3. Desirable Project Level Database
Ideally, the detailed data from every project should be entered into the database as an individual pavement section, if possible on a subproject level. Individual subsections of the project with changing characteristics such as sub grade strength should be entered into the database. If it is not possible to enter the subsection data then the data should be entered for the entire project or section levels with the mean standard deviation and the number of individual data measurements used in the calculation.
The database should store both the design values and as-constructed values for parameters such as, thickness, strength, and stiffness of each of the individual layers. It is also desirable to enter information on material sources. It may not be feasible to enter details such as source of asphalt and detailed properties of the asphalt aggregate components within the mixture, but it is desirable to do so if possible.
The performance parameters for project level pavements will be obtained from the network level database. However, they should be entered on a subsection basis if possible and should include roughness or serviceability index, detailed condition surveys by distress type, deflection behavior including deflection basins and surface friction or skid resistance. All of these data should be on a subsection basis. Ideally the precise location of each lot should be recorded (mile point, lane#) so that the characteristics of that lot can be properly linked to its performance. Detailed traffic and load information should include vehicle classification, load axles, and axle distributions. It is desirable that all of these data be entered at key points along each section to provide geographical definition of variability within the section so that an analysis of the parameters and the performance variability within the section can be analyzed. A forensic analysis of any pavement failures, major maintenance, rehabilitation and/or reconstruction in the pavement section should be recorded in the project level database. The date when the section was opened to traffic is required mainly to check whether performance measurements during a certain year were done before or after the (re)construction.
It is possible to enter project level data on new sections or on sections that are being reconstructed or rehabilitated. When existing pavement sections are rehabilitated where no prior project level data are available in the pavement management database, then remedial data collection should be carried out for these sections. Representative coring with an adequate number of cores (e.g. a minimum of three cores for a short section and a minimum of three cores per mile for longer sections) should be carried out to obtain pavement thickness. Tests should be run on the cores to obtain pavement and sub grade properties, such as stiffness or strength. In the case of rehabilitation or restoration, detailed deflection data should also be obtained in the outside wheel path as a minimum. In the case of thickness it may be possible to estimate thickness using GPR (Ground Penetrating Radar). However, if GPR is used, then one core per mile should be taken, with a minimum of three cores per section to obtain calibration thicknesses for comparisons with the GPR data. When sections are rehabilitated or reconstructed, they should show historical data on the original construction dates and if possible, original plan details should be found and entered into the database at the time of reconstruction or rehabilitation, to make it available for future detailed analysis.
4.4. Actual Project Level Data Collection in Example States
The way data are collected, stored and analyzed varies from state to state, but in most cases the following four organizational groups are involved:
For the evaluation or monitoring of the performance of materials like Superpave it is imperative to have access to data generated by the four groups mentioned above. There are three main reasons why such data are often difficult to obtain:
There have been attempts by DOT's to develop a databank with project information, based on e.g. a survey questionnaire, but in practice it often appeared difficult to collect the data after the project was completed. There are a few exceptions, ADOT for instance has a reasonably updated project database, but even here not all relevant data needed for a proper evaluation is available.
4.5. Desirable Research Level Database Details
Currently the most neglected part in the pavement management database, is research level data. Each state DOT has many individual projects involving new materials and new concepts. In such cases, a lot of detailed measurements and design information is originally available. Often this information is recorded on laboratory worksheets or in individual project plans, specifications, and construction control records. However, in most cases these data are set aside and remain in these flat files without being transferred to a permanent electronic database. After several years it is seldom feasible to retrieve such information for subsequent analysis. Therefore, the over-riding role of the research database is to encourage everyone in the DOT, particularly in the materials and design sections, to provide detailed data on a project by project level for inclusion in an extension file that is coded directly with the pavement management section. It is recommended that the state DOT adopt a standard operating procedure for entering research data into the database within twelve months of the activity.
Typically, if a variable is being studied in a research project, that variable should be recorded in the research level database. However, any other variable that may have an impact on the project should also be recorded. In general, the research level database is more detailed than the network level or the project level database. For example, if a project is included as a part of a study of concrete properties then cement type, source, fineness, set time, water cement ratio, aggregate type, aggregate gradation, and angularity should be recorded. Both design properties and as-constructed properties and values are essential. It is essential to know what the designer hoped to obtain, but more importantly in every case it is important to know what actually was obtained, since that is what will govern the observed performance.
In this report, Superpave is the example under immediate consideration. The study has shown that the QC/QA module of the Superpave/AASHTOware data set [AASHTO 00], supplemented by information such as actual layer thickness and precise location identification, could be good vehicle to store and disseminate materials and construction data for Superpave applications. Unfortunately, AASHTO has recently decided to temporarily stop the distribution and support of that program. The recent efforts made by The University of Washington, in collaboration with Washington State DOT, where relevant data on Superpave projects, including performance data, is presented on an integrated website, is a most welcome and probably more suitable methodology. Details are given in Appendix F.
4.6. Actual Research Level Databases
Currently most state DOTs do not record research data in their PMS or a PMS related database because of lack of resources. It is not feasible to assume that project or research engineers who work full time in the design, construction and observation of projects or who have already completed those projects and have data available in hard copy, will have time to enter the data in a database. It is necessary to set up a data collection and processing activity, which will make the data available to the electronic database. The activity must include the pavement management section to ensure that the data are compatible in every way.
An important example of data that fit this category but which have never been properly used or entered into most state databases are the LTPP data. In many cases the state DOTs could take the individual LTPP sections and supplement them with measurements in their own state on other sections to make a broader applicable factorial, which could be analyzed for state benefits.
Little effort has been made in most state DOTs to store research level data in a form keyed to the pavement management database. There are many reasons for that, which is not relevant at this point. What is relevant is that state DOTs should be made aware of the benefits of keying such data to the PMS database. The value of research could be doubled if the data could be maintained permanently so that mistakes are not repeated.
Another major benefit of keying these data into the PMS database is that multiple states could share the data with each other. Electronic storage is critical to such databases. For example, if ten states stored their research data for 30 test sections each into their own PMS database, they could exchange data electronically among the states and a much broader database of 300 section could be analyzed. Most engineers do not fully understand the powerful analytical capabilities of large sample statistics. Even in the face of large variability, strong trends can be obtained when data sets can be combined into one large one.
It is important for data entered into the database, to make reasonable estimates of the traffic load history of each section. Even if weight data are not available, it is vital to make a timely estimate of equivalent single axle loads based on a reasonable evaluation of available load, traffic, and classification data. If attempts are made to reconstruct the data five to 15 years later, then the value of the estimates are degraded.
In summary the characteristics of the PMS database are extremely important. Great benefits can accrue to state DOTs if those data sets can be broadened to include project and research level data on a regular basis, and if the data can be combined among states for additional strength. Subsequent sections of this report will deal with Superpave data as a specific example and the importance of gathering these data while they are fresh.