The 1R process is the primary process used by KDOT to define and prioritize the set of maintenance activities identified as important that should be considered by each district in two years.

This use case describes the actors and actions that occur when the 1R process is initiated at the beginning of each year.

This use case provides guidance on how the R-PMS system should function at the beginning of the yearly cycle that is defined as 1R.

Interface into the KHUB Planning Network Geometry data

The PMS needs to track when pavement projects are "open to unrestricted traffic".

This is the time when the surface is done and traffic flow is in the nominal configuration.

PMS acquires this information to allow for this decision through completed Rehab Forms from district personnel

How does KDOT know the pavement surface condition data they collect each year is good? They have a Data Quality Management plan .

This plan spells out how data collected early in the collection cycle is compared between the two vehicles used to collect the data and predicted conditions.

The idea is that this check is a reasonable indicator that both vans are functioning consistently and as expected.  

The details are described in the DQMP document - Kansas DQMPver1_4_2SUBMITTED.pdf.

See Kansas DQMP ver 1.4.2 SUBMITTED (note: not official site for this document but provided for easy access and reference)

KDOT is required to collect pavement surface condition data on the State Highway System (KHS) and National Highway System (FHWA) for Federal Highway Performance Monitoring System Reporting. Since we have the data it seems reasonable to share it with our KTA partner.

Purpose: This process generates a printed book called the "FDCL" or the Field Data Collection List specific to each Year. The book lists each PMS segment (taken from GEOM and HPMS) along with key reference location information (from table REF) along with historically contained locations of samples for manual data Collection. The Book is used by field personnel to locate county mileposts for them to "lock on" with the Mandli software. It also includes the predominant pavement type for each segment.

Generation of the Data Collection List is dependent upon a series of necessary activities which are captured in this Use Case

In general this Use Case is related to the activities which Create/Update the data used to generate the routes for the FDCL and involve manual activities which are desired to become more automated in the R-PMS system

Close out the Prior Year activities by reconciling the differences between PMS.GEOM and KHUB.GEOM

As a desired behavior - R-PMS should automatically reconcile the differences between R-PMS.GEOM and KHUB.GEOM

KDOT recognizes the importance of good pavement surface friction for safety. Using a locked-wheel skid testing system, KDOT conducts many tests each year.  To know where to test and how that data will be stretched over the appropriate coverage area, a process is used to generate a book of locations needing testing and corresponding maps to help locate and track the collection sites.

Measuring pavement surfaces really amounts to obtaining two pieces of information about each point on the pavement surface.

1) The intensity (light) from the Lidar

2) The relative elevation (Height)

Fortunately, KDOTs equipment manufacturer and integrator does the hard part of turning the height and light of all points into actual pavement condition data.  So, the vans are driven over the roads to get the height and light data and then processed to turn that data into standardized XML files and images. To further use this data, the integrator has tools to allow users to view the images and run reports on the data.

These tools are primarily in the form of software called Road View Explorer (RVE)

Proposed:

Mandli System will automatically conflate the Scanned Network with that input into the System in Mar01 activities from the PMS Operator derived from KHUB

Transverse cracking is a pavement surface distress that demands attention. It is a driver for many pavement action decisions, but it is not easily reported from the Integrator Software in a manner that works for PMS.

PMS developed a separate procedure to extract the relevant TCR data directly from the XML files and store it in the PMS Oracle database. This data table then becomes the input to other tools to allow PMS to report and incorporate information about TCR into the KDOT management process.

This activity represents the actions of the PMS Operators to start making necessary changes to the Logical Segment ID's based upon the actions that occurred in the previous year.

Manual Use Case in which all the data collection systems of KDOT PMS are used throughout the KHS

This activity does the following:

1)        Acquire KHUB Network and inject into Mandli Workstation

2)        Mandli System stores data for later conflation when data is processed

In this stage of the PMS work, it is necessary to verify that the data collection data analysis processes are progressing as expected and to handle any anomalies that might occur.

Note: The Alternate R-PMS Desired if implemented would replace all of the Mar03 Activities

Loading of the NCV scanned data into the PMS system

This is an alternative viewer to the NCViewer software which is preferred by the PMS Operators

For consistency between prior year projects and current year activities, this constraint places bounds on the minimum and maximum project segment length as defined.

For consistency between prior year projects and current year activities, this constraint places no bounds on the non-maintenance highways