National Academies Press: OpenBook

Analytical Tools for Asset Management (2005)

Chapter: Section 5 - Tool Descriptions

« Previous: Section 4 - Selection of Tools for Development
Page 36
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 36
Page 37
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 37
Page 38
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 38
Page 39
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 39
Page 40
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 40
Page 41
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 41
Page 42
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 42
Page 43
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 43
Page 44
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 44
Page 45
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 45
Page 46
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 46
Page 47
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 47
Page 48
Suggested Citation:"Section 5 - Tool Descriptions." National Academies of Sciences, Engineering, and Medicine. 2005. Analytical Tools for Asset Management. Washington, DC: The National Academies Press. doi: 10.17226/13851.
×
Page 48

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

36 SECTION 5 TOOL DESCRIPTIONS 5.1 OVERVIEW This section provides a description of each tool that was developed and presents requirements that guided the devel- opment process. User guides, provided on the bound-in CD, were devel- oped for AssetManager NT and PT that provide step-by-step instructions on how to install and use the tools. 5.2 ASSETMANAGER NT Tool Overview AssetManager NT is a tool to assist transportation agency executives and program managers in understanding how dif- ferent patterns of investment in transportation assets will affect the performance of the system over the long term. The tool allows a user to explore the implications of different budget levels for a set of investment categories, which can be defined based on asset types (e.g., pavement versus bridge), geographic areas (e.g., districts or regions), or system sub- networks (e.g., NHS, trunk line system, priority truck net- work, primary corridors). AssetManager NT brings together analysis results from the existing management systems in an agency and adds value by providing a quick-response, what- if analysis tool for testing different investment options. It does not replace existing management systems; it builds upon their capabilities and enables a more integrated (cross- stovepipe) view of asset investment tradeoffs. Some examples of questions to be answered by the tool are: • What happens if we make an across-the-board 30-percent decrease in both pavement and bridge investment levels? • What happens if we increase funding for the bridge pro- gram by 20 percent and make a corresponding reduction in the pavement program? • What happens if we spread pavement and bridge fund- ing evenly across different districts? What would be the resulting impact on remaining life or backlog of work? • What happens to the condition of non–National High- way System (NHS) facilities if we focus 75 percent of the resources on the NHS? Although these types of questions can be answered using individual management systems, the process is typically time- consuming. Higher level decision-makers currently do not have a convenient way to quickly explore investment trade- offs across different asset types in a coordinated fashion. AssetManager NT provides a motivation and a framework for running individual management systems in a consistent, coordinated way that supports tradeoff analysis. Over time, it may serve as the catalyst for enhancing management sys- tems to produce performance measures that better allow for comparison of investments across asset types. The overall flow of using AssetManager NT is illustrated in Figure 4. Input Requirements A prerequisite for this tool is one or more functioning man- agement systems with the capability to simulate work and to store simulation results (cost and performance impacts) for different budget scenarios. The current version of the tool is designed to operate with results for up to four asset types. However, the design allows for future expansion beyond this number. The tool requires results from a series of scenario runs at a range of budget levels from each management system. Approximately 5 to 10 runs for each investment category to be analyzed are required to provide sufficient variation in results. Each scenario run needs to produce the following information: • The expenditure level; • The investment category (e.g., interstate highways in District 1); and • Values of performance indicators associated with the simulation resulting from the scenario run (e.g., per- centage of network in acceptable condition, depreciated asset value). The tool can use any performance measure produced by a management system. The sample data sets provide both asset- specific (e.g., pavement condition index) and asset-independent (e.g., user costs, work backlog) examples of measures.

37 Companion Robot Tools Two demonstration robot tools—the pre-processor analy- sis routine and the what-if tool—were developed for this project to show how the process of creating inputs for Asset- Manager NT can be automated. These robot tools work with the AASHTO Pontis bridge management system and with FHWA’s HERS/ST tool. Both robots run the management system (either Pontis or HERS/ST) multiple times and pro- duce input files that can be read directly by AssetManager NT. These tools are described in further detail in the follow- ing subsection. Analysis Capabilities AssetManager NT is an interpolation engine and visual- ization tool that works with management system results. It does not include analytic capabilities typically found in individual asset management systems, such as deterioration modeling, simulation, strategy selection, or optimization. The software includes two components: a pre-processor of the management system run data and a what-if tool. The pre-processor analysis routine is provided to consoli- date information from the various management system runs into a format that the what-if tool can work with. This rou- tine uses an approach similar to that of the FHWA NBIAS, currently in use to analyze national bridge needs. If the pave- ment and bridge management systems produce consistent performance measures (e.g., monetized user benefits or work backlog or remaining asset value), then the analysis routine can aggregate them. The pre-processor analysis routine prepares a four- dimensional (i.e., time period, investment category, perfor- mance measures array, and budget level) matrix of results and creates a scenario file that is used by the what-if tool. The what-if tool provides interactive on-screen views of the relationship between investment levels and performance measures by investment category. Four views are provided for what-if analysis: • The budget view allows the user to explore the relation- ship between the average level of investment over time and the value of a single performance measure for a selected asset and portion of the network. • The targeting view allows the user to determine the average annual expenditure required to reach a target performance measure value over a selected timeframe. • The dashboard view allows the user to look at several different performance indicators at once and to explore their sensitivity to overall budget levels and the alloca- tion of budget across assets, geographic areas, and por- tions of the network. For example, this view could be used to look at future pavement condition in four dif- ferent regions under different geographic distribution assumptions. It also could be used to look at pavement condition, bridge condition, and total backlog of work (or asset value) for a single district under different assump- tions about total budget and allocation of this budget between pavement and bridges. • The allocation view allows the user to define different resource allocation scenarios and to see graphs that compare their performance impacts over time. Like the dashboard view, the displays are configurable to show several different performance measures or a single per- formance measure for different geographic areas or por- tions of the network. Outputs Reports are available for each of the four views described above. These reports show all of the graphics included in the view and are supplemented by information about the sce- nario definition and assumptions underlying the view. Figure 4. AssetManager NT overview.

Selection of the Application Platform The user’s primary interface is to a what-if capability from which on-screen views of the relationships between invest- ment levels and performance measures by investment cate- gory can be explored. This interface needs to be highly inter- active, to allow the user to directly manipulate various model parameters and rapidly get feedback in the form of changes to charts or graphs depicting the effects of those parameter changes. The fundamental value of this tool is linked to its ability to provide a highly interactive graphically based user interface. Therefore, interactive performance is a major requirement: the architecture selected for this tool has to ensure that the system can query the tool’s data set and respond immediately to user interface events. Given the functional requirements of the tool, a roughly 40 MB source data set to support the analysis will need to be kept in memory. Multiuser functionality is not an important requirement for the AssetManager NT tool. The tool supports tradeoff analy- sis, which by nature is a fairly specialized activity limited to a few key individuals in an agency and/or within each district who will be fully aware of the assumptions and limitations of the tool. The data sets for AssetManager NT are static (i.e., they will not be updated via the tool’s interface once they are produced); thus, a capability for multiuser editing is not a requirement and frequent refreshes of the data sets will not be needed. The data sets will be relatively small (under 50 MB); thus, these data sets can be duplicated for use on portable computers (e.g., for presentations to decision-makers). Given these requirements, the research team decided to implement AssetManager NT as a Windows desktop appli- cation (either on a local or a network drive) that works with a binary data set. This approach was selected to provide rapid interactivity and a rich set of user interface controls, such as sliders. Although development of a thin-client, web-based tool was seriously considered, a web application would not deliver a satisfactory level of performance (particularly with respect to rapid updates to multiple two-dimensional graphs in response to changes to model parameters). The key advan- tage provided by a web-based tool—access to a common data set by large numbers of distributed users, thereby elim- inating the need to deploy the application to multiple com- puters—was not considered important, given the relative simplicity of this tool and the anticipated nature of its use. As a stand-alone desktop application, the tool will have no dependencies on browsers or versions of browsers. Determination of Functional Requirements To guide the tool development process, a set of functional requirements were developed. These requirements make up a checklist of capabilities that the tool should have to be useful and usable. They also define parameters needed by the system developers, such as the number of asset types to be accommo- dated. Definition of functional requirements was a three-step process. First, clear definitions of terminology to be used in describing the tool were established. Next, business rules were developed that describe fundamental assumptions about how the tool will be used. These rules define what is and is not allowed for the tool input data and configuration. Finally, the list of requirements was developed that cover the capabilities to be provided by the tools. These three elements—defini- tions, business rules, and functional requirements—are pre- sented in the following subsections for AssetManager NT. Definitions Asset Type. A type of asset whose performance is modeled in an individual management system run. Geographic Category. Categorization of the system accord- ing to a geographically based set of classes (e.g., regions, dis- tricts). Categories are assumed to be mutually exclusive and are assumed to cover the entire system. Investment Level. The average annual expenditure within the defined scope over the scenario time horizon. Network Category. Categorization of the system according to non-geographically based attributes (e.g., functional class, ownership, administrative or funding responsibility). Cate- gories are assumed to be mutually exclusive and are assumed to cover the entire system. Performance Indicator (also referred to as “Indicator”). Raw performance value associated with the given stratifica- tion cell, level of funding, and planning period. Performance Measure. Performance value obtained as an aggregation of indicators across stratification cells or as a sum or difference of other performance measures. The fol- lowing aggregation functions will be allowed: SUM, AVG (weighted average), MIN, and MAX. Planning Period. A time period for which individual invest- ment and performance results are reported in the scenario input file (typically 1 year). Pre-Processor. Piece of analytical software that will process input data in a special way and generate a binary object to be manipulated by what-if analysis. Scenario Input File. Data set (file) with information from simulation runs obtained from individual asset management systems (e.g., Pontis, HERS/ST). Scenario Results File. Binary file generated by the pre- processor and used for what-if analysis. 38

39 Scenario Time Horizon. The number of planning periods selected for analysis in the system configuration file and therefore included in the scenario results file. Simulation Run. An individual simulation run of an asset management system (or other simulation tool) providing input data. The tool can accept the results of up to 10 simu- lation runs for each asset type. Simulation Time Horizon. The number of planning periods simulated in the simulation runs for individual asset types. Stratification Cell. Combination of asset type, network cate- gory, and geographic category (e.g., bridges/NHS/District 1). The tool will limit the number of stratification cells to 480 (4 asset types by 10 network categories by 12 geographic categories). System. The physical transportation system as defined by the set of all assets included in the tool. System Metrics File. File containing essential metrics of the configuration cells (e.g., total deck area of bridges, number of bridges, length of the roads) that will be used by the sys- tem as weighting factors for calculation of the performance measure averages. What-If Engine. Interactive user interface and built-in analy- sis routines to allow a user to conduct asset tradeoff analysis. See Figure 5 for a graphical illustration of the key Asset- Manager NT organizing concepts and terms. Business Rules The following business rules are built into the Asset- Manager NT: 1. Results for each asset type are independent of results for other asset types. The source management systems are assumed to have already accounted for any double- counting of costs or benefits or synergistic effects that might result from combining work on different asset types. 2. A given performance indicator can apply to one or more asset types. 3. Each asset type must have one or more associated per- formance indicators. 4. Each performance indicator may be used for compu- tation of one or more performance measures. 5. Each performance measure must be associated with a single metric defined in the system configuration. 6. Values for all metrics defined in the system configu- ration must be included in the system metrics file for all combinations of the network categories and geo- graphic categories that have been defined in the sys- tem configuration. 7. Each simulation run for an asset type must include results for each combination of the network categories and geographic categories that has been defined in the system configuration. 8. Each simulation run for an asset type must include results for at least two planning periods. 9. Planning periods must be defined consistently across asset types; in most cases, these periods will be calen- dar or fiscal years. If they are defined as multiyear peri- ods, the definitions of these periods (i.e., start and end years) must coincide across the different asset types. 10. Each simulation run must include expenditures and performance measure values for each planning period in the simulation time horizon. 11. Each simulation run for an individual asset type must have the same simulation time horizon. 12. Simulation runs for different asset types do not need to have the same simulation time horizon, but they do need to include some overlap in time. 13. The same number of planning periods must be included in the scenario time horizon for each asset type. 14. All expenditure values are to be reported by the source management systems in current dollars. 15. The what-if engine will interpolate performance measure results between simulation runs, but it will not extrapolate beyond the highest investment level included for a given scope. If a user enters a higher investment level for analysis, results from the simula- tion run with the highest investment level will be reported. Functional Requirements Requirement 1. Accept Investment and Performance Data from Asset Management Systems 1.1 The tool shall accept, in a standard, documented for- mat, expenditure levels and associated performance indicators generated from simulation runs of asset management systems. 1.2 The tool shall allow the user to define multiple sce- narios, each representing a different series of man- agement system runs. For example, an agency might wish to analyze two scenarios that employ different assumptions about changes in future construction costs, asset deterioration rates, user cost assumptions, etc. Each scenario will have a user-defined name. 1.3 The following items shall be configurable by the user for each scenario: • Asset types to be included—up to four;

Scenario Input File (One for each Asset Type) Planning Periods Investment Level 1 Investment Level 2 Investment Level 10 Simulation Runs • Geographic Category • Network Category • Performance IndicatorsSimulation Time Horizon Preprocessor – Create Scenario Planning Periods Scenario Time Horizon Simulation Time Horizon Scenario Input File – Asset Type 1 Scenario Input File – Asset Type 2 Scenario Input File – Asset Type 3 System Metrics File Values of metrics for each combination of Asset, Network Category, and Geographic Category System Configuration Definition of Assets, Network Categories, Geographic Categories, Metrics, Performance Indicators, and Measures Scenario Results File G e o g r a p h i c C a t e g o r y As set Ty pe Network Category Stratification Cell Investment Level Tim e Pe rio d Performance MeasuresS t r a t i f i c a t i o n C e l l s Scenario Input Files Figure 5. AssetManager NT: organizing concepts.

41 • Performance indicators to be included in manage- ment system results—up to 25 total for all assets; • Performance measures (user-defined derivations of the performance indicators)—up to 40 total for all assets; • Metrics by which weighted averages of performance measures are to be calculated; • Network subset classes to be included—up to 10; • Geographic categories to be included—up to 20; • Number of planning periods (typically years) for the analysis—up to 20; • Number of management system simulation runs— up to 10 per asset type for each scenario; and • Scenario name. 1.4 Sample system setup input files and results input files shall be provided with the tool, allowing new users to run the tool with a demonstration data set prior to preparing data for their agencies. These sample setup files will include some standard measures that allow pavement and bridge investments to be compared. 1.5 A functional prototype robot tool to produce a results input file from the Pontis bridge management system shall be provided with the system. 1.6 A functional prototype robot tool to produce a results input file for pavement from an HPMS data set (using HERS/ST) shall be provided with the system. 1.7 The system shall allow users to provide baseline val- ues for performance indicators as part of the scenario input files. Baseline values are defined as the actual values of performance indicators for the year prior to the initial scenario year. Baseline values shall not be required; the tool shall allow users to designate which indicators are to have baseline values. 1.8 The tool shall include the capability to generate and store multiple scenarios. Users shall be able to spec- ify the scenario name, input file(s) for each asset type, and number of years of results to extract. Requirement 2. Provide Capability for Interactive What-If Tradeoff Analysis 2.1 The tool shall allow a user to see how the values of per- formance measures for the network as a whole change as a result of changes to (1) total average annual expen- diture levels, (2) the allocation of resources across asset types, and (3) the allocation of resources across geographic and network subsets. 2.2 The tool shall allow a user to see how the projected value of a selected performance measure for a selected portion of the network changes given a choice of (1) total average annual expenditure levels, (2) the allocation of resources across asset types, and (3) the allocation of resources across geographic and network subsets. 2.3 The tool shall allow users to set a target value for a performance measure for the network as a whole at the end of a selected time horizon and to see what annual expenditure level would be required to meet that performance target. 2.4 The tool shall allow users to set a target value for a performance measure for a selected portion of the net- work at the end of a selected time horizon and to see what annual expenditure level for that portion of the network would be required to meet that performance target. Requirement 3. Display Results in Graphical Views 3.1 The tool shall provide a budget view that shows (on a single screen) how a selected performance measure changes over time for up to six different annual bud- get levels. 3.2 The tool shall provide a targeting view that allows a user to select a target value for a single performance measure and see the annual budget level that would be required to achieve that target value. 3.3 The tool shall provide a dashboard view that allows a user to see (on a single screen) how changes in an annual budget level would affect the values of several different performance measures or a single perfor- mance measure for several different portions of the system. This view shall allow the user to specify allo- cation of resources across assets and, optionally, across network and geographic categories. 3.4 The tool shall provide an allocation view that allows a user to see (on a single screen) how different budget allocations across assets and, optionally, network and geographic categories would affect the values over time of several different performance measures or a single performance measure for several different por- tions of the system. Requirement 4. Produce Standard Reports 4.1 The tool shall produce a report that shows the graph in the currently selected view. 4.2 The tool shall produce a report that shows the current scenario settings, including the name of the scenario; a list of the performance measures, asset types, geo- graphic categories, and network categories; and (where applicable) the current allocation of resources across asset types, network categories, and geographic cate- gories resulting from the user’s selections. 4.3 An option shall be provided to save reports to a file for- mat that allows graphs and tabular information to be imported into Microsoft Office software (e.g., presen- tations and word processing documents) and modified.

Requirement 5. Configuration Options 5.1 The tool shall include a user interface that allows entry of configuration information, including the assets to be included, geographic and network categories to be used, indicators, performance measures, and weight- ing metrics. This user interface eliminates the need for users to edit the configuration text file; however, this text file is still part of the system. 5.2 The tool shall allow the user to maintain an unlimited number of sets of configuration information, each of which can specify different asset classes, network and geographic subsets, weighting factors, and perfor- mance measures. Users shall be able to choose a con- figuration set to be used for creation of a new scenario. 5.3 ASSETMANAGER PT Tool Overview AssetManager PT is a program-level tool for tradeoff decisions. This tool works with a program of projects (and optionally, one or more alternatives to each project) orga- nized into one or more program categories. The tool can work both within an agency where allocations to program categories (e.g., pavement, bridge, safety) are the focal point of the resource allocation process and within an agency where decisions about which packages of projects (including differently scoped options for given locations) should be pro- grammed are the focal point. The tool allows the user to adjust the program and see the impacts on a set of basic indicators of program output and network or systemwide performance. The tool allows pro- gram adjustments to be made in three ways: (1) the user can manually shift projects out of the program or replace them with alternative projects that have been defined; (2) the user can adjust the available budget level for a given program cat- egory and have the system automatically shift projects in or out of the program based on a user-specified ranking; or (3) the user can shift funds from one program category to another and have the system eliminate the lowest ranked projects from the category being cut and add the next high- est-ranked projects on the list for the program category being increased. The system allows different ranking methods for each program category to be defined. On-screen reports show the results of these project selec- tion changes on total costs, program output indicators (e.g., miles of paving, number of bridge rehabilitations), and a set of performance measures (e.g., percentage of network in good condition, number of high-accident locations). This tool is designed to serve related purposes: • Provide a dynamic understanding of how modifications to the program would impact selected systemwide goals (e.g., the percentage of miles meeting a given condition target) and • Provide a centralized organizer for information about projects in the program that emphasizes and facilitates looking at project impacts and benefits in a consistent fashion. The tool could be used at the statewide or the district level. It can accept results from project-level analysis tools, exist- ing program-specific priority tools, and pavement and bridge management systems that produce information on project benefits, impacts, and costs. The tool does not require that every project have a monetized benefit measure. This tool does not include any capabilities to perform benefit/cost analysis calculations, but it can store the necessary inputs to these calculations as an option. Some examples of questions to be answered by the tool are: • What happens to our ability to achieve stated pave- ment condition targets if a new major capacity project is included (or if an existing capacity project’s cost escalates by 20 percent)? • If we include minor capacity and safety improvements with our pavement rehabilitation projects on a given corridor, how many miles of resurfacing would we need to cut from the program? How would indicators of con- gestion, safety, and pavement condition be affected for the state as a whole? • If a delay in a major project results in an additional $500,000 for the program period, what are the best options for spending these funds? • What happens if we shift funds from pavement preser- vation into bridge rehabilitation? The overall flow of using AssetManager PT is illustrated in Figure 6. Input Requirements Two types of data are required for this tool: (1) project- level information, including description/classification, per- formance impacts, and measures of the extent of assets affected by the projects, and (2) summaries of system-level performance information, disaggregated by district or other divisions of the network that are needed to support system- level performance impact calculations. The tool requires the following minimum project-level information: • Unique project identifier; • Alternative identifier (allows multiple options for a given project to be included; the combination of project iden- tifier and alternative identifier must be unique); 42

43 • Project package identifier (used to maintain dependen- cies across individual projects in a program); • Project name; • Several classifications for the project: program cate- gory, asset types (e.g., road, bridge), network category (e.g., functional class, district, on/off NHS, on/off freight network), geographic category (e.g., district or region), project work type (e.g., pavement reconstruction, bridge rehabilitation, signal improvement); • Total project cost; • Transportation system extent or measure before and after the project (e.g., miles, number of lanes, square meters of bridge deck area); and • Indicator(s) before and after the project, which can be a value (e.g., pavement condition index, accident rate) or classification-type indicator (e.g., poor condition pave- ment, posted bridge, does not meet safety standards). In addition, suggested but optional project-level data ele- ments include the following: • Location referencing information (to allow for viewing of projects along a facility and linking to a GIS); • Annual average daily traffic (AADT); • Project year (expected completion date); and • Project benefits and benefit/cost ratio (this information needs to be calculated in an external system). The tool also allows users to include additional informa- tion pertaining to projects that would be helpful for sorting or ranking (e.g., project life, annualized cost, district engi- neer priority ratings). The tool accommodates fixed project line items that have only an identifier, a cost, a name, and classifications, because many items in a program (e.g., inspections) are not amenable to the same type of tradeoff analysis as those projects with direct impacts on condition, mobility, safety, etc. It also allows for inclusion of scheduled projects that are not subject to removal from the program. These projects can be marked as “in the pipeline.” The tool uses the following system-level data: • System measures (e.g., miles, number of bridges) bro- ken down by geographic and network categories used to classify projects; • Current values for indicators (average values or percent- age distribution by categories) broken down by geo- graphic and network categories used to classify projects; • Target values for indicators (optional); and • Work targets—either systemwide or broken down by geographic and/or network categories (optional). This tool requires a combination of automated and manual data preparation steps, which will be highly dependent upon the specific project databases and management systems in place in an agency. Most agencies have some kind of candi- date project listing in electronic format containing a subset of the needed items, which can serve as the starting point of the project data-loading process. Some agencies will have candidate projects in their pavement and bridge management systems with information on impacts and benefits that could be transferred into the system. For agencies that routinely use benefit/cost analysis tools for significant numbers of projects, utility programs could be developed to extract results data. (Agencies that do not have benefit/cost tools in place can Figure 6. AssetManager PT overview.

refer to Appendix C of the AssetManager PT Users Guide for examples of how to calculate a benefit/cost ratio at a level of detail appropriate for prioritization.) Some degree of manual data preparation is necessary. How- ever, this preparation is not necessarily an overwhelming task. The tool is intended to cover a relatively short timeframe (1 to 3 years); thus, the number of distinct projects that would be subject to analysis should be less than 1,000 for most states. The number would be much less if an agency chooses to use this tool for only a particular portion of its program. System-level information may be loaded from existing management or asset inventory systems through a one-time effort to write the necessary data extraction scripts. The scripts can be rerun periodically as the inventory is updated. Analysis Capabilities The tool provides the following capabilities: • An interface for viewing projects by category and sorting/ ranking projects according to a variety of user-specified criteria; • An interface for developing program scenarios, each of which consists of a different overall budget level and/or allocation of resources across budget categories; • Automated selection of projects for the program based on project rankings and established expenditure limits for different budget categories; • An interface that allows users to move projects in and out of a given program scenario, select project alter- natives, and easily view the impacts of these shifts on expenditures by program category and system-level performance measures; and • Calculations of program output and performance impact indicators: – Amount of work by type and network category (where amount of work could be measured in miles, number of bridges, or other user-defined work units); – Expenditures by work type and geographic or net- work category; and – Changes in indicator values (average, sum, or distri- bution) by network category. Outputs AssetManager PT includes the following reports and graphs: • Expenditures by budget category for a budget scenario (in tabular, bar chart, and pie chart form), which allows filtering by geographic and network category; • Before and after performance measure values (compared to targets, if established) for a single budget scenario or comparison across budget scenarios (in tabular form); • Expenditures by project type for a budget scenario (in tabular and bar chart form), which allows filtering by geographic and network category; • Amount of work by type compared to established work targets for a budget scenario or comparison across bud- get scenarios (in tabular form); and • List of projects selected for a given budget scenario, organized by program category (in tabular form). Selection of Application Platform Because of budget limitations and the desire to investigate data requirements before full-scale tool development, devel- opment of this second tool was limited to a functional proof- of-concept prototype. The proof-of-concept tool itself was developed as a Microsoft Excel spreadsheet with supporting Visual Basic functions to perform calculations. This platform was chosen for ease of development, testing, and use. Section 7 of this report recommends that the user interface be more developed in the production version of this tool. This new version would include a highly interactive user interface that encourages and supports the testing of alternatives. In particular, a “drag-and-drop” interface, for moving projects in and out of the program being analyzed and substituting among project alternatives, is a natural user interface choice for this tool. The tool would immediately present the impacts of these changes on system-level performance measures as graphs. A standard, off-the-shelf database (e.g., MS Access, Sybase Adaptive Server Anywhere) could be used to store project information and provide query capabilities. Alterna- tively, the system could be designed to work with several dif- ferent common back-end databases. Determination of Functional Requirements Functional requirements for AssetManager PT were devel- oped using the same three-step process described previously for AssetManager NT. The definitions, business rules, and requirements for AssetManager PT are presented in the fol- lowing paragraphs. Definitions After. The state/value of a system measure or performance measure after completion of selected projects. Before. The state/value of a system measure or performance measure before implementation of any projects. The term “baseline” is used as a synonym. Budget Category. A subdivision of a program that is used to establish budget limits and track planned (and actual) expenditures. 44

45 Budget Limit. A user-specified limit on the available resources within a budget category, used to compare available versus expended funds by budget category and used by the auto- mated project selection algorithm. Asset Type. An optional classification for a project that describes the type of facility on which work is being per- formed and may be used to aggregate program expenditure information. Asset types can be used to complement the set of budget categories that have been defined. For example, if the budget categories are pavement and bridge, asset types might further subdivide these (e.g., flexible pavement, rigid pavement, culvert, concrete bridge). If the budget categories are defined based on work type (e.g., preservation, safety, capacity), then the asset-type categories could be set to broader asset classes (e.g., pavement, bridge, drainage). Geographic Category. Categorization of the system accord- ing to a geographically based set of classes (e.g., regions, dis- tricts). Categories are assumed to be mutually exclusive and are assumed to cover the entire system. One of the geo- graphic categories will always be the entire system (“ALL”). Measurement Unit. Metric used to measure the scale of individual projects and of different portions of the trans- portation system represented in the tool. For example, “lane- miles” is an example of a measurement unit. Network Category. Categorization of the system according to non-geographically based attributes such as functional class, ownership, and administrative or funding responsibil- ity. Categories are assumed to be mutually exclusive and are assumed to cover the entire system. One of the network cat- egories will always be the entire network (“ALL”). Performance Measure. Indicators that describe program outcomes that result from implementation of projects. Exam- ples are total backlog, average pavement condition, and num- ber of restricted bridges. A performance measure is desig- nated as one of the following types: • A SUM-type performance measure adds a straight sum of the change in performance measure value for a proj- ect to the baseline performance measure value for the system subset to calculate the “after” value for the sys- tem subset (e.g., change in backlog). • An AVERAGE-type performance measure uses a weighted average approach to calculate the effects of a project on the performance measure value for a system subset (e.g., average IRI), based on the reported “after” value for the project and the “before” or baseline value reported for the system subset. • A CATEGORY-type performance measure is based on a condition being met (e.g., “bridge posted with load limit” or “pavement in poor condition”). Project impacts for category-type measures are recorded as quantities of a system measure that are in the category (e.g., number of bridges that are posted or miles in poor condition). Program. A set of projects selected for implementation from the program worksheet. Program Worksheet. A set of project candidates that may be funded for implementation. Project. A proposed work activity with a cost and (option- ally) a set of performance impacts. Project Alternative. A project that is part of a set of mutually exclusive options from which decision-makers can choose. For example, several project alternatives with varying costs may exist for a corridor improvement. Project Measure. The scale of the project expressed in one of the types of defined measurement units (e.g., lane-miles, number of bridges). Project Package. A group of projects that must be imple- mented together and cannot be selected individually. For example, a roadway widening project may be dependent on the assumption that another project will widen bridges along the roadway as well. Project Type. An optional classification for a project that describes the type of work being performed, which may be desired for aggregation of program expenditure information. Project types can be used to complement or provide further breakdowns for the set of budget categories that have been defined. Typical examples of project types might be pave- ment resurfacing, bridge preventive maintenance, and inter- section improvements. Each project type is associated with a measurement unit that will be used for purposes of setting work targets. Scenario. A set of defined budget levels for each program category, along with an associated set of project selections. Selected Project. A project that has been selected for inclu- sion in the program, as indicated in its program_status flag. System Measures. Project- and system-level quantities used for developing weighting factors in the performance measure calculation process. Examples of system measures are lane- miles of pavement, square feet of bridge deck area, number of bridges, annual vehicle miles traveled (VMT), and replace- ment value. System Subset. A combination of a geographic category and a network category. Performance measures may be summa- rized for each system subset. One of the system subsets will

always be the entire system (the combination of the “ALL” geographic category and the “ALL” network category). Work Target. A desired level of accomplishment of a given project type to be accomplished within the program period, where work accomplishment is measured in the measure- ment units that are associated with that project type. Business Rules The following business rules are assumed within the tool: 1. A program worksheet must contain at least one project. 2. At least one budget category must be defined for a program worksheet. 3. Up to four different budget scenarios can be defined. 4. A budget category may have a budget limit associated with it for a given scenario. 5. Each project must be associated with a single budget category. 6. Expenditure levels for each budget category will be calculated as the sum of project costs within that bud- get category. 7. The expenditure levels for each budget category will sum to the total expenditure level for the program as a whole. 8. Each project must be associated with a single network category. 9. Each project must be associated with a single geo- graphic category. 10. Each system subset consists of a combination of a sin- gle network category and a single geographic cate- gory. One of the system subsets will always be the entire system (the combination of the “ALL” geo- graphic category and the “ALL” network category). 11. Each project may be associated with a single proj- ect type. 12. Each project may be associated with a single asset type. 13. Each project may be assigned a work package iden- tifier to indicate that all projects in the work package must be treated as a unit: inclusion or exclusion of one member of the package automatically includes/ excludes all of the others. 14. Each project must have an alternative identifier. If more than one project with the same project identifier is included in the program worksheet, the alternative identifiers for projects with that project identifier must be unique. Only one alternative for a project may be included in the program. 15. Each project has a program_status flag, which indi- cates whether the project has been selected for inclu- sion in the program. If this flag is set to IN, the proj- ect’s costs and performance impacts are to be included in the program cost and impact results. 16. Each project has a user_status flag, which indicates whether it is a pipeline project and must be included in the program. If this status is set to IN, then the program_status must be set to IN and will not be modifiable either by the user or by the automated proj- ect selection process. 17. Each project has a generated_status flag, which indi- cates whether the automated project selection process has included the project in the program. 18. Each performance measure must be assigned exactly one type of measurement unit (e.g., miles, VMT, num- ber of bridges) to be used for calculating the impacts of projects on system subsets and on the system as a whole. CATEGORY-type performance measures are always defined based on the quantity of their associ- ated system measure meeting a specified condition. 19. Each project can be associated with zero or more per- formance measure impacts. 20. Each reported performance measure impact for a proj- ect must include the estimated performance measure value after completion of the project. For SUM- and CATEGORY-type performance measures, the per- formance measure value before implementation of the project for the defined project scope also must be reported. 21. Each project that has SUM or AVERAGE perfor- mance measures must include “before” and “after” system measure values for all types of system mea- sures that are associated with these performance mea- sures reported for the project. For many projects (e.g., resurfacing), the system measures will typically be the same before and after the project. However, some proj- ect types will result in a change in system measures (e.g., a lane addition would change the number of lane-miles). 22. Each measure must have a single, defined type of unit that is used consistently wherever information about that measure is used. 23. A master list of performance measures is established by the user prior to loading project data. Project impacts can only include values for performance measures that are on this master list. Similarly, system measures reported for projects must match the system measures associated with the reported performance measures for the projects. 24. “Before” or baseline system-level values for each per- formance measure must be provided for each system subset that has been defined. 25. Target values for each performance measure may be provided optionally for each system subset. 26. Values for each type of system measure must be pro- vided for each system subset that has been defined. 27. “After” values of system measures for system subsets will be calculated as the sum of system subset “before” 46

47 values of system measures and the net change in sys- tem measures associated with the selected projects in those subsets. 28. Each project type may have an associated type of measurement units. 29. Work targets may be set for any combination of net- work category, geographic category, and project type. Functional Requirements Requirement 1. Allow User Definition of Performance Measures and Analysis Categories 1.1 The tool shall allow users to define system measure types and their associated units. 1.2 The tool shall allow users to specify the performance measures to be used in the analysis, along with their associated types of system measures to be used for calculating weighted averages. 1.3 The tool shall allow users to define network categories, geographic categories, and combinations of these (sys- tem subsets), which will define the portions of the sys- tem for which performance is to be summarized. 1.4 The tool shall allow users to define project types and asset types for project classification and reporting. Each project type may be assigned a type of system measure for purposes of tracking work to be accom- plished in the program against established targets. 1.5 The tool shall construct pick lists from the standard performance measures, system measures, network cat- egories, geographic categories, system subsets, project types, and asset types to ensure consistency in data entry of project and system information. Requirement 2. Accept Project Information 2.1 The tool shall accept information about projects, includ- ing their costs, system measures, and predicted per- formance impacts. 2.2 The tool shall provide the flexibility to store user- defined data items pertaining to projects. 2.3 The tool shall accommodate projects that have costs but do not have impacts on performance (e.g., inspections). 2.4 The tool shall support manual entry of project infor- mation and provide pick lists for coded items estab- lished in the setup information. 2.5 (Future) The tool may support automated input of project information via a standard XML data inter- change format. 2.6 (Future) The tool may allow users to click on an indi- vidual project to view detailed supporting informa- tion, including the impacts on performance measures and a user-defined set of items that are useful for understanding the project’s purpose and value. Requirement 3. Accept System-Level Information 3.1 The tool shall accept information on the quantity of each system measure for each system subset. 3.2 The tool shall allow users to define budget categories and input associated budget limits for each category for up to four scenarios. 3.3 The system shall allow the user to enter targets for the amount of work to be accomplished during the pro- gram period. These targets may be entered for any defined project type, for any combinations of geo- graphic and network subset. The amount of work is to be expressed in terms of the system measure type that has been associated with the project type. 3.4 (Future) The system may allow users to define budget limits for individual years of the program. Requirement 4. Calculate Impacts of a Set of Projects on System Performance and Expenditures 4.1 The tool shall calculate and aggregate the performance impacts of a user-selected set of projects on associated system subsets based on the values of user-supplied “before” and “after” performance values and system measures for each project. 4.2 The tool shall accommodate SUM-, AVERAGE-, and CATEGORY-type performance measures (see defini- tions section). 4.3 The tool shall calculate and aggregate the “after” sys- tem measures for system subsets based on changes in system measures associated with programmed projects. 4.4 The tool shall calculate expenditures for each budget category based on the cost of projects selected for inclusion in the program. 4.5 Program performance results shall be calculated for a single point in time, after completion of all projects in the program. The system will not account for any dete- rioration in condition or changes in traffic that may occur in intermediate program years, since the program time horizon is presumed to be short (1 to 3 years). Requirement 5. Provide Interactive Interface for Adjusting Projects in the Program 5.1 If a project is one of a set of alternatives, the tool shall not allow selection of more than one of the alterna- tives for inclusion in the program. 5.2 If a project is designated as part of a package of proj- ects, the tool shall ensure that if one project in the package is selected for the program, then all other members of that package are automatically selected. 5.3 The tool shall allow users to filter projects by budget categories.

5.4 The tool shall allow users to sort projects based on any individual project attribute. 5.5 The tool shall allow users to designate projects as mandatory. Mandatory projects will always be included in the program. 5.6 The tool shall allow users to assign numerical ranks to projects, either manually or based on the current sort order. 5.7 The tool shall include an automated routine that selects projects within each budget category based on their rank, until all available budgets are consumed. 5.8 The tool shall allow users the option of accepting the automatically generated list of projects, which will set the program_status indicator to the value of the generated_status indicator. This feature is needed so that users can begin with an automatically selected list of projects and make further manual adjustments as desired. 5.9 The system shall include the capability to generate and store project selections for up to four scenarios. Requirement 6. Provide Summary Reports and Graphs of Program Performance Impacts 6.1 The tool shall produce a report showing budget limits and budget spent by budget categories. 6.2 The tool shall produce a pie chart showing the distri- bution of program resources by budget category and a bar chart showing the budgeted and allocated program resources by budget category. 6.3 The tool shall produce a report showing the projected versus target values of performance measures for each system subset. 6.4 The tool shall produce a report and bar chart showing resource allocation by asset type within each budget category. 6.5 The tool shall produce a report showing projects selected within each budget category. 6.6 The tool shall produce a report and bar chart showing the cost and quantity of work by project type. Quantity of work is to be shown based on the user-supplied sys- tem measure–type associated with each project type. 6.7 The tool shall produce a work targets report showing the quantity of work for each project type and the work target by system subset. Quantity of work is to be shown based on the user-supplied system measure– type associated with each project type. This report shall include only system subsets for which the user has specified work targets. 6.8 The tool shall include the capability to view results for any selected scenario. For the performance measures and work targets reports, the tool shall include the capability to view results for all four scenarios on a single display. 48

Next: Section 6 - Testing Process »
Analytical Tools for Asset Management Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB’s National Cooperative Highway Research Program (NCHRP) Report 545: Analytical Tools for Asset Management examines two tools developed to support tradeoff analysis for transportation asset management. The software tools and the accompanying documentation are designed to help state departments of transportation and other transportation agencies identify, evaluate, and recommend investment decisions for managing the agency’s infrastructure assets.

The software tools associated with NCHRP Report 545 are available in an ISO format. Links to instructions on buring an .ISO CD-ROM and the download site for the .ISO CD-ROM are below.

Help on Burning an .ISO CD-ROM Image

Download the NCHRP CRP-CD-57.ISO CD-ROM Image

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!