This actor has the responsibility to oversee the KDOT PMS 1R processes throughout the annual 1R lifecycle.

This actor represents the KDOT Van operators whom are tasked with the responsibility of driving and scanning the designated highways and collect data from the Mandli hardware.

This actor represents the activities of the Mandli Road View Explorer (RVE) tool which resides outside the scope of the PMS system but is required for data production of Pavement Surface Data reports (files) for which the PMS system is dependent.

This actor represents the activities of the Mandli Road View Explorer (RVE) tool which resides outside the scope of the PMS system but is required for data production of Pavement Surface Data reports (files) for which the PMS system is dependent.

Interface into the KHUB Planning Network Geometry data

Overall Use Case that is used to generate the 1R priority list for each district

Use to enabling Actor to calculate the Condition of a Road based upon a variety of input elements and constraints.

This stage involves shifting to the modeling activities and to take the Historical Data and any new data from WinCPMS, and use this data to determine the Road Categories of each 1/200th mile segment. Once determined then the Road Category allows modeling activities to properly predict the degradation of the surface of the road segment analytically and/or through statistical processes.

Calculates the Distress State Vector for Federal Highways within the State of Kansas

This Use Case is used for the Calculation of the Estimated Remaining Life of each segment per the current Segment State Vector

This use case creates a "Snapshot" of the State of the KHS for a specified Actor supplied date

Calculation of the Pavement Distress State Vector utilizes the Federal methodology and applies it to the KHS non-Federal highways

This Use Case represents the need for the Scan Data to be normalized such that data from one segment of the KHS can be directly compared to data from another KHS segment.  The normalization process can be built upon other external normalization procedures or can be a singular process.

This Use Case is a primary Use Case in that it formulates the overall actions of the PMS modeling activities but in general utilizes included Use Cases to do the actual work

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.

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

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

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.

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

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

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.

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.

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

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.

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

In this task it is necessary to start the White Pavement Data Collection activities

This stage is dedicated to loading the LCMS Van scanned and interpreted Join Distress Data for the KHS.

This is a continuation of the Mar03 Activities and is here for reference only

This is a continuation of the Mar04 Activities and is here only for reference

This task involved the querying of the existing/historical PMS data set to create a collection of historical data

This step then involves load any newly created data from Planning (WinCPMS) and also load new Traffic estimated data coefficients, Pavement Surface Type definitions (and specifications) as well as any available Shoulder data.

This stage involves shifting to the modeling activities and to take the Historical Data and any new data from WinCPMS, and use this data to determine the Road Categories of each 1/200th mile segment. Once determined then the Road Category allows modeling activities to properly predict the degradation of the surface of the road segment analytically and/or through statistical processes.

This step involves the loading of the 1/200th mile segment data aggregate / metadata regarding IRI, rutting, faulting, and TCR indices

This step is a continuation of the step Apr04 as the LCMS data is multiTerabyte in size and takes a very long period of time to load into the PMS data tables.

This again is a continuation activity as the TCR data requires a significant amount of processing time to extra the TCR values from the Mandli XML data files.

This action is also a continuation action from the Apr01 action by helping to support Planning activities on the non-Interstate related data issues.

This task is to finish the NOS collection processes that was started earlier and get the data processed and reported as data files (CSV and XML)

To prepare data for Planning and for NCViewer application

This Use Case is also used to generate the planning view for the nonState data.into the PMS.LCMSFrameHPMSnon data table

This is a modeling process in which segment data is used to generate segment based IRI, Rutting, Faulting, and TCR Indexes.

This modeling step is used to verify that there is no missing data due to construction work and to convert that data into FILL values in the DB tables.

This stage of modeling does a calculation of the Distress State Vector and the Performance Levels of the KHS.The historical method is defined but the method for the R-PMS system needs updated algorithmic definition.

Determine if there are any necessary PCCP reports to be generated.and complete them during this stage of modeling.

A modeling stage in which the Pavement Condition States are calculated.

This stage determine if there are time widows and/or orphan windows that are available for activities.

For the current year, for every GEOM record there should be a corresponding ROUGH record

For the current year for every GEOM record that is Asphalt pavement type there should be an FDIST record

For the current year for every GEOM record that is Concrete pavement type there should be an RDIST record

...

Also check the other direction that there are not any records in ROUGH that do not have a corresponding GEOM

...

Work with Planning to determine if there are any non-internal issues from prior years data collection that need to be addressed at this time.

Support the initial development of the Government Accounting Standards Boards reports for Prior Year Network

REq: Performance Measures

Start the initial development of the Transportation Asset Management Plan

Start the initial development of the Agency Central Financial Report (ACFR) for the State of Kansas

Start the process of making data available to the KDOT Auditor division for evaluation.

Generate TAMP, PM (KDOT), IKE, and District reports

Do the full modeling activities for the 1R processes.

- See AECOM epmsHelpPart20220119100157200 for more information

Prepare the 1R candidate lists for initial review by the District Managers

        Candidate Project Lists of recommended actions

        Districts Mileage Allotments

Make the Frame Based data available to Planning for further utilization in 3R activities

Start the collection of the SKID data regarding the friction coefficients of the road surfaces under optimum dry conditions.

Start the collection of the FWD data regarding the friction coefficients of the road surfaces under optimum dry conditions.

Work with the Planning WinCPMS system and the candidate lists from the previous year efforts for the current year scheduled work and track the current status of the work and update Planning with the information

Modeling activity in which the Remaining Life of each 1/200th mile segment is calculated for the entire KHS Network.

Calculate the Performance Factors data and send that data to Planning

Determine if there are any changes to the Network due to GIS mapping related problems and/or changes.

Continue KHS data collection activities and load the data into the PMS data systems as it becomes available. - See Business Activities

        Feb03-Run both vans on KTA

        Apr04-Continue loading LCMS data

        Apr05-Continue loading TCR data

        Jun04-Continue loading LCMS data

        Jun05-Continue loading TCR data

        Jul01-Finish NOS collection / processing / reporting

Continue the SKID friction data testing and load the data as it is collected

See Task T08-05

Determine if there are any pavement type changes due to ongoing project work in each District

Determine if there are any changes to the District Alignments due to ongoing projects and GIS changes and record them in the PMS geometry data as well as the KHUB geometry data.

Generate an initial 1R project candidate list with respect to locations and scopes.

Clean the collected data by getting rid of bad data and normalizing any data as necessary.

FIlling in the holes and making sure there is appropriate data for all segments

Send project candidate lists out to the PPDC/Chief C&M/DCs

Acquire the non-State HPMS Samples from Planning and handle appropriately

Generate any Ad Hoc reports and data that might be needed to support the generation of the KDOT Annual Report.

T07-10 GASB Report

Start the process of planning the activities and projects to be started at the beginning of the New Year.

Where should the FWD collection occur for the next year

Do not collect on Concrete, new Pavement, and not in current construction locations