Research, Development, and Technology

Turner-Fairbank Highway Research Center

6300 Georgetown Pike

McLean, VA 22101-2296

PUBLICATION NO. FHWA-HRT-23-071 JULY 2023 

Decision Support Methods and Tools 

for Traffic Management Systems
FOREWORD

New and emerging data sources generated from travelers using mobile devices, vehicles, 

infrastructure, and other sources will provide agencies with opportunities to change how they 

manage traffic and their transportation systems. These data sources offer agencies with traffic 

management systems (TMSs) the challenge of enhancing or developing capabilities to collect, 

compile, save, use, and share this data.

The Federal Highway Administration Office of Safety and Operations Research and 

Development is pleased to present Decision Support Methods and Tools for Traffic Management 

Systems. This report provides support to public agencies in planning, developing, and 

maximizing the benefits of decision-support methods and tools (DSTs) in TMSs. It also

identifies the possible processes and potential issues agencies may want to consider when 

planning, designing, developing, operating, maintaining, and integrating DSTs within a TMS. 

DSTs assist with processing and using data collected or received from connected vehicles, 

connected mobile devices, and other sources to help improve the capabilities and performance of 

TMSs and allow for more information than ever before to be more readily shared with other 

systems, service providers, and the traveling public. Many DSTs can also greatly aid in 

decisionmaking and predict possible outcomes of decisions. This report aims to assist 

transportation agencies in choosing and implementing DSTs to prepare for or build the next 

generation of TMSs and traffic management centers. 

Brian P. Cronin, P.E.

Director, FHWA Office of Safety and Operations

Research and Development

Notice

This document is disseminated under the sponsorship of the U.S. Department of Transportation 

(USDOT) in the interest of information exchange. The U.S. Government assumes no liability for 

the use of the information contained in this document.

The U.S. Government does not endorse products or manufacturers. Trademarks or 

manufacturers’ names appear in this report only because they are considered essential to the 

objective of the document. 

Quality Assurance Statement

The Federal Highway Administration (FHWA) provides high-quality information to serve 

Government, industry, and the public in a manner that promotes public understanding. Standards 

and policies are used to ensure and maximize the quality, objectivity, utility, and integrity of its 

information. FHWA periodically reviews quality issues and adjusts its programs and processes to 

ensure continuous quality improvement. 
TECHNICAL REPORT DOCUMENTATION PAGE

1. Report No.

FHWA-HRT-23-071

2. Government Accession No. 3. Recipient’s Catalog No.

4. Title and Subtitle

Decision Support Methods and Tools for Traffic Management 

Systems

5. Report Date

July 2023

6. Performing Organization Code: 

7. Author(s)

Kevin Miller (ORCID: 0000-0001-9931-8809), John Horner

(ORCID: 0000-0001-7237-0383), Jeff Adler

(ORCID: 0000-0002-3765-8469), and Robert Sanchez

(ORCID: 0000-0002-0763-6146) 

8. Performing Organization Report No.

9. Performing Organization Name and Address 10. Work Unit No. (TRAIS)

Leidos, Inc.

11251 Roger Bacon Drive

Reston, VA 20190

Kapsch TrafficCom USA, Inc.

8201 Greensboro Drive

McLean, VA 22102

11. Contract or Grant No.

DTFH61-16-D00053

12. Sponsoring Agency Name and Address

U.S. Department of Transportation

Federal Highway Administration

1200 New Jersey Avenue, SE

Washington, DC 20590

13. Type of Report and Period Covered

Final report: September 2017–July 2023

14. Sponsoring Agency Code

HRDO-20

15. Supplementary Notes

The task order manager is Jon Obenberger (HRSO-50; ORCID: 0000-0001-9307-847X).

16. Abstract

Traffic management systems (TMSs) and their operating centers, known as traffic management centers (TMCs),

support real-time and offline functions, services, actions, activities, and related tasks or decisions (e.g., 

administrative and operational). In this context, decision-support tools (DSTs) are not generally used as stand-alone 

solutions; rather, DSTs are deployed and integrated with specific subsystems (e.g., software subsystems and data 

subsystems) of a TMS. (Depending on the requirements and how a TMS uses a tool, it may be integrated with the 

software of a specific subsystem, component, or device.) This report supports agencies in planning, developing, 

and improving their use of DSTs and decision-support methods already in use or being considered for the next

generation of TMSs and TMCs. It identifies issues and opportunities for agencies to consider in exploring potential 

opportunities for the use of DSTs in enhancing the capability and performance of TMSs and supporting

information sharing with other systems, agencies, and service providers and the traveling public.

17. Key Words

Decision support, decision-support tool, traffic management 

system, traffic management center

18. Distribution Statement

No restrictions. This document is available to 

the public through the National Technical 

Information Service, Springfield, VA 22161. 

http://www.ntis.gov

19. Security Classif. (of this report)

Unclassified

20. Security Classif. (of this page)

Unclassified

21. No. of Pages

143

22. Price

n/a

Form DOT F 1700.7 (8-72) Reproduction of completed page authorized.
ii

 

 

 

 

 
iii

TABLE OF CONTENTS

CHAPTER 1. INTRODUCTION ................................................................................................ 1

Decisionmaking and Traffic Management Systems ........................................................... 2

What Is a DSS?........................................................................................................................ 4

DSTs .................................................................................................................................. 5

DSSs ................................................................................................................................... 5

DST Integration: Assessing, Planning, and Designing ........................................................ 6

How To Use This Report ........................................................................................................ 7

Report Overview ..................................................................................................................... 7

CHAPTER 2. DECISIONMAKING AND DECISION-SUPPORT TOOLS ....................... 11

Traffic Management Systems .............................................................................................. 11

Factors Influencing Decisionmaking .................................................................................. 12

The Decision Support Concept ......................................................................................... 12

Types of Decision-Support Tools ........................................................................................ 13

Offline DSTs .................................................................................................................... 15

Online DSTs ..................................................................................................................... 20

Look-Up Tables ................................................................................................................ 23

CHAPTER 3. INTEGRATING DECISION-SUPPORT TOOLS INTO TRAFFIC 

MANAGEMENT SYSTEMS .................................................................................................... 25

Key TMS Functions .............................................................................................................. 25

Monitor ............................................................................................................................ 26

Calculate and Predict ........................................................................................................ 27

Propose, Select, and Implement ....................................................................................... 28

DST Incorporation Into Traffic Management Systems ................................................... 30

Data Subsystem ................................................................................................................ 30

Software Subsystem ......................................................................................................... 32

Computing Hardware Subsystem .................................................................................... 36

UIs Specific to a DST ....................................................................................................... 36

Logical Architecture of a TMS ......................................................................................... 39

CHAPTER 4. TRAFFIC MANAGEMENT SYSTEM DECISION-SUPPORT NEEDS ... 43

DST Selection and Use: Issues To Consider Beforehand .................................................. 43

Understanding Needs in the Context of Overall System Planning .................................. 44

Steps To Identify Needs for a DST ...................................................................................... 46

Step 1—Identify Stakeholders and DST Goals ............................................................... 46

Step 2—Elicit and Document User and System Needs .................................................... 47

Step 3—Reconcile, Validate, and Prioritize Needs .......................................................... 47

Step 4—Verify System Is Feasible and Necessary ........................................................... 47

Step 5—Define Project Scope ......................................................................................... 47

Needs Assessment Strategies ................................................................................................ 47

Determining the Need for a DST ...................................................................................... 48

Identifying Gaps and Opportunities To Improve Decisionmaking .................................. 48

Developing and Using System Requirements for DST and TMS Assessments .............. 54

Additional Resources ............................................................................................................ 55
iv

Types of Requirements for DSTs .................................................................................... 56

How Requirements May Vary Within a System .............................................................. 58

Determining How to Verify and Validate a Requirement ................................................ 61

Priority or Importance of Requirements ........................................................................... 62

Finalizing Requirements and Beginning the Design Phase .............................................. 62

Tracing Requirements .......................................................................................................... 62

CHAPTER 5. ASSESSING CURRENT AND FUTURE DECISION-SUPPORT 

TOOLS ......................................................................................................................................... 65

Key Issues To Consider ........................................................................................................ 65

Steps to Identify Existing Decision-Support Resources ................................................... 66

Step 1—Identify Resources .............................................................................................. 66

Step 2—Identify Existing DST-Related Items ................................................................ 66

Step 3—Identify DST Conversion Candidates ................................................................. 66

Step 4—Identify Integration Strategies ........................................................................... 67

Organizational Resources ................................................................................................... 67

Project Champions ............................................................................................................ 67

Subject Matter Experts ..................................................................................................... 68

Readiness for DSTs in TMS Operations .......................................................................... 68

Existing Processes, Procedures, and Tools Already Available in the TMS .................... 69

Planning Considerations for Specific DST Types .............................................................. 69

Knowledge-Driven DSTs ................................................................................................. 69

Data-Driven DSTs ........................................................................................................... 70

Model-Driven DSTs ......................................................................................................... 71

DST Assessment Example .................................................................................................... 72

Issues To Review for DST and Existing Resource Evaluations ........................................ 74

CHAPTER 6. SELECTING A DST FOR A TMS .................................................................. 75

Key Issues To Consider ....................................................................................................... 75

Steps For Selecting and Designing a DST ........................................................................... 75

Step 1—Verify Reuse Options ......................................................................................... 76

Step 2—Make Build/Buy/Reuse Decisions ...................................................................... 77

Step 3—Communicate Build/Buy/Reuse Recommendation ............................................ 77

Step 4—High-Level Design of a New DST .................................................................... 78

Step 5—Detailed Design for the Integration of the DST With a TMS ............................ 78

Identify Existing Decision-Support Tools .......................................................................... 78

Verify Reuse Options ....................................................................................................... 78

Build Option ..................................................................................................................... 78

High-Level Design ................................................................................................................. 79

Data Subsystem Design .................................................................................................... 79

DST Type Selection ......................................................................................................... 81

Integration Strategy .......................................................................................................... 83

Workflow Design ............................................................................................................. 83

UI Design .......................................................................................................................... 83

Response Design .............................................................................................................. 83

Computing Hardware Design .......................................................................................... 84

Detailed Design ..................................................................................................................... 84

Example of Selecting a DST ................................................................................................. 86
v 

Issues To Review: The Options for Selecting a DST ........................................................ 86

CHAPTER 7. PROCURING AND IMPLEMENTING DECISION-SUPPORT 

TOOLS ........................................................................................................................................ 87

Key Issues To Consider ....................................................................................................... 87

Steps to Procuring and Implementing a DST..................................................................... 87

Step 1—Understand Available Procurement Options ...................................................... 88

Step 2—Select Appropriate Procurement and Development Method .............................. 88

Step 3—Develop Procurement Documents ...................................................................... 88

Step 4—Evaluate Proposals and Select a Vendor or Developer ...................................... 88

Procurement Options ........................................................................................................... 89

Hardware Subsystem Options .......................................................................................... 89

Preprocurement Checklist ................................................................................................... 91

Potential Issues ...................................................................................................................... 91

Example of Procuring a DST ............................................................................................... 92

Additional Resources ............................................................................................................ 92

Checklist: Issues to Review When Procuring a DST ......................................................... 94

CHAPTER 8. INITIATING THE USE OF DECISION-SUPPORT TOOLS ...................... 95

Key Issues To Consider ........................................................................................................ 95

Steps To Prepare for Operating a DST .............................................................................. 96

Step 1—Verification of Requirements ............................................................................. 97

Step 2—Deployment of System ....................................................................................... 97

Step 3—System Validation .............................................................................................. 97

Step 4—Transition to Operations ..................................................................................... 98

Verification ............................................................................................................................ 99

Verification of Knowledge-Driven DSTs ....................................................................... 100

Verification of Data-Driven DSTs ................................................................................. 100

Verification of Model-Driven DSTs ............................................................................... 101

System Deployment and Validation .................................................................................. 102

Verification and Validation of a DST................................................................................ 103

Example of a Regional DST for ICM ............................................................................. 103

Checklist for Preparing for Operations ........................................................................... 104

CHAPTER 9. MONITORING, EVALUATING, AND USING A DST .............................. 105

Key Issues To Consider ..................................................................................................... 105

Steps for Monitoring, Evaluating, and Adjusting a DST ................................................ 105

Step 1—Select Performance Measures and KPIs ........................................................... 106

Step 2—Obtain Existing Data ........................................................................................ 106

Step 3—Develop Data Manipulation Procedures .......................................................... 107

Step 4—Understand Available Data .............................................................................. 107

Step 5—Collect Supplemental Data ............................................................................... 107

Step 6—Create Performance Measures and Develop Reports ...................................... 108

Step 7—Develop Corrective Actions ............................................................................. 108

Selecting Appropriate Performance Measures ................................................................ 108

Knowledge-Driven DSTs ............................................................................................... 109

Data-Driven DSTs ......................................................................................................... 111

Model-Driven DSTs ....................................................................................................... 113
vi 

DST Performance Measure Checklist ............................................................................ 114

Obtaining the Data Needed for Measuring Performance ............................................... 114

Performance Reporting ...................................................................................................... 114

Corrective Actions ............................................................................................................. 115

Additional Resources .......................................................................................................... 115

Example of Monitoring and Evaluating a DST ................................................................ 116

Checklist: Monitoring, Evaluating, and Adjusting a DST .............................................. 117

CHAPTER 10. USING AND MAINTAINING DECISION-SUPPORT TOOLS ............. 119

Key Issues To Consider ...................................................................................................... 119

Maintenance Processes ....................................................................................................... 119

Steps for Maintaining a DST ............................................................................................ 120

Step 1—Monitor and Maintain the DST ......................................................................... 120

Step 2—Identify When Changes Are Needed ................................................................ 121

Step 3—Update and Replace the DST ............................................................................ 121

Key Maintenance Concepts ................................................................................................ 121

Managing and Improving DST Operation ...................................................................... 121

Assessment Approaches and Evaluation Methods ........................................................ 122

Computing Hardware Updates ....................................................................................... 123

Data Updates ................................................................................................................... 123

Software Updates ............................................................................................................ 123

Framework for Determining When Maintenance Is Needed ........................................ 125

Computing Hardware Updates ....................................................................................... 125

Software and API Updates .............................................................................................. 125

Data Updates ................................................................................................................... 126

Using and Maintaining a DST: Case Study ...................................................................... 126

Additional Resources .......................................................................................................... 127

DST Maintenance Checklist .............................................................................................. 128

REFERENCES ......................................................................................................................... 129
vii 

LIST OF FIGURES

Figure 1. Diagram. TMS structure with examples. ........................................................................ 3

Figure 2. Diagram. Traffic management decisionmaking. ............................................................. 4

Figure 3. Diagram. Taxonomy of decision support. ....................................................................... 5

Figure 4. Illustration. Overview of a major incident response plan. ............................................ 16

Figure 5. Screenshot. Agency actions in a response plan for a major incident. ........................... 17

Figure 6. Screenshot. Top 1,000 ranked bottleneck locations in Maryland, District of 

Columbia, and Virginia between October 1 and October 31, 2019. ................................... 20

Figure 7. Screenshot. Quick Streets add-in interface. .................................................................. 23

Figure 8. Diagram. Key functions of a TMS with DSTs. ............................................................. 26

Figure 9. Diagram. Sample data subsystem. ................................................................................. 31

Figure 10. Diagram. ETL process. ................................................................................................ 32

Figure 11. Diagram. Software subsystem and installed software. ................................................ 33

Figure 12. Screenshot. Dallas ICM project operator UI. .............................................................. 37

Figure 13. Screenshot. Dallas ICM project business rules component UI. .................................. 38

Figure 14. Screenshot. Dallas ICM project prediction component UI. ....................................... 39

Figure 15. Diagram. VicRoads TMS decision-support subsystems architecture. ........................ 40

Figure 16. Diagram. VicRoads TMS mapped to the four key subsystems of TMCs. .................. 41

Figure 17. Diagram. Needs gathering for a DST. ......................................................................... 46

Figure 18. Diagram. Steps to identify existing DST resources. ................................................... 66

Figure 19. Equation. Total system cost over a 10-yr period. ........................................................ 73

Figure 20. Equation. Relative benefits to cost ratio. ..................................................................... 74

Figure 21. Equation. Estimated benefits. ...................................................................................... 74

Figure 22. Diagram. Steps to define the design of a DST. ........................................................... 76

Figure 23. Diagram. Steps to procure a DST. ............................................................................... 88

Figure 24. Diagram. Hardware models for the build scenario versus the procure scenario. ........ 90

Figure 25. Diagram. Steps to prepare for operation of a DST. ..................................................... 97

Figure 26. Diagram. Model calibration process. ........................................................................ 102

Figure 27. Diagram. Evaluating DST performance. ................................................................... 106

Figure 28. Equation. GEH statistic. ............................................................................................ 113

Figure 29. Diagram. Maintaining a DST. ................................................................................... 120

Figure 30. Diagram. Change management process. .................................................................. 122
viii

LIST OF TABLES

Table 1. DSTs mapped to decision-support classifications. ......................................................... 13

Table 2. Maryland CHART incident duration decision tree. ....................................................... 18

Table 3. Descriptions of variables in an incident duration decision tree. ..................................... 19

Table 4. Input variables within a look-up table. ........................................................................... 24

Table 5. Software for different types of DSTs. ............................................................................ 33

Table 6. Agency-related questions and considerations for determining decision-support 

needs. ................................................................................................................................... 50

Table 7. DST-related questions and considerations for determining decision-support needs. ..... 51

Table 8. Existing infrastructure, interface, and integration questions and considerations for 

determining decision-support needs. ................................................................................... 52

Table 9. Questions and considerations related to organizational and stakeholder support for 

determining decision-support needs. ................................................................................... 53

Table 10. Implementation-related questions and considerations for determining 

decision-support needs. ....................................................................................................... 54

Table 11. Example decision-support subsystem needs. ................................................................ 57

Table 12. Example system-level requirements for an ICM system. ............................................. 59

Table 13. Example subsystem requirements. ............................................................................... 60

Table 14. Example ERE requirements. ........................................................................................ 61

Table 15. Example RTM. ............................................................................................................. 63

Table 16. Integration strategies and procurement options. ........................................................... 77

Table 17. Example incident management timeline. ................................................................... 110
ix

LIST OF ABBREVIATIONS

ACP20 Transportation Research Board Committee on Freeway Operations

API application programming interface

CHART Coordinated Highways Action Response Team

ConOps concept of operations

CV connected vehicle

DMS dynamic message sign

DOT department of transportation

DSS decision-support system

DST decision-support tool

DTA dynamic traffic assignment

ERE expert rules engine

ETL extract, transform, and load

FDOT Florida Department of Transportation

FHWA Federal Highway Administration

GEH Geoffrey E. Havers

GUI graphical user interface

HCM Highway Capacity Manual

HCS Highway Capacity SoftwareTM

IaaS infrastructure-as-a-service

IEC International Electrotechnical Commission

ICM integrated corridor management

INCOSE International Council on Systems Engineering

ISO International Organization for Standardization

IT information technology

ITB invitation to bid

ITN invitation to negotiate

ITS intelligent transportation systems

KPI key performance indicator

LOS level of service

ML machine learning

NCHRP National Cooperative Highway Research Program

NOAA National Oceanic and Atmospheric Administration

PaaS platform-as-a-service

RFP request for proposal

R–ICMS regional integrated corridor management system

RMSE root mean square error

RTM requirements traceability matrix

SaaS software-as-a-service

SME subject matter expert

TMC traffic management center

TMS traffic management system

TRB Transportation Research Board

TxDOT Texas Department of Transportation

UI user interface

USDOT U.S. Department of Transportation

1 

CHAPTER 1. INTRODUCTION

Traffic management systems (TMSs) are complex operational systems. They combine field 

equipment, advanced information technology (IT) and communications, and software tools. They

collect and synthesize traffic data, integrate external systems, and enable command and control 

of intelligent transportation system (ITS) field devices. They enable human operators to perform 

functions that support improving the efficiency, safety, and predictability of travel on the surface 

transportation network. 

The ever-increasing availability of traffic data and the expanding operational strategies available 

to agencies are increasing the complexity of making operations-related decisions in realtime. 

Decision-support tools (DSTs), including computer-based and noncomputer-based tools, support 

a range of decisions. Examples of noncomputer-based DSTs are paper-based decision trees and 

decision tables that can be printed and collated into reference information. Computer-based 

DSTs can potentially play a key role in improving the real-time decisionmaking of traffic 

operations personnel by complementing and enhancing the operational capabilities of TMSs. 

For the purpose of this report, computer-based DSTs are tools that process vast amounts of data, 

capture the operational processes of an agency, and potentially mimic the real-time 

decisionmaking of traffic management center (TMC) or TMS operators. DSTs can aid operations 

personnel in monitoring and assessing conditions (e.g., environment, facility, and network), 

detecting and verifying adverse conditions, and identifying and evaluating appropriate response 

strategies to planned and unplanned events. DSTs can also help agencies achieve more consistent 

and understandable decisionmaking across their transportation management staff. 

This report explores implementing DSTs and processes to improve TMSs. State departments of 

transportation (DOTs) and local agencies may use the concepts and processes discussed for 

developing practices to plan, design, operate, monitor, evaluate, and report on the performance of 

decisionmaking with a TMC. Additionally, this report seeks to do the following:

• Examine current practices and trends among agencies using or planning to implement 

DSTs to improve the capabilities and performance of staff and TMSs. 

• Discuss types of available DSTs, how they might benefit operational personnel, and how 

they can be integrated into a TMS to support or carry out real-time decisionmaking. 

The objectives of this report are as follows: 

• To present types of available DSTs, thus facilitating and improving agencies’ 

management and operation of their TMSs. 

• To identify issues for consideration when assessing the decision-support needs and 

capabilities of a TMS. 

• To frame issues of consideration when incorporating different types of DSTs into the 

management and operation of a TMS. 
2 

• To identify opportunities for the potential use of DSTs during any phase of the TMS 

lifecycle (e.g., planning, design, maintenance, and operation).

DECISIONMAKING AND TRAFFIC MANAGEMENT SYSTEMS

Improving the timeliness and effectiveness of decisionmaking is a focus for agencies exploring 

opportunities to improve how they manage and operate TMSs. Traffic management relies on

timely decisionmaking for monitoring traffic conditions, detecting and managing unplanned 

events, scheduling and managing planned events, improving signal timing, assessing and 

planning for adverse weather, and managing critical infrastructure. Decisionmaking relies on the 

real-time management and operation of a TMS, which involves unique knowledge, skills, and 

experience. These capabilities include the following five aspects:

1. Possessing knowledge of the transportation system. 

2. Understanding agency policies and operational procedures. 

3. Applying policies and procedures in realtime based on changing conditions and different 

events.

4. Processing wide ranges of data and information and assimilating them.

5. Anticipating implications of implementing or changing the operation of different 

operational strategies or control plans.

TMSs provide the software platforms or subsystems that agencies and TMCs rely on to support 

operations. Figure 1 illustrates the physical and logical components of a TMS and examples of 

these components. Operational decisionmaking is associated with the logical elements of the 

TMS structure—operational strategies the TMS is designed to support, functions supported by 

the TMS, control plans that may be used, and actions to be executed. 
3 

Source: FHWA.

API = application programming interface; CCTV = closed-circuit television; DMS = dynamic message sign; 

RWIS = road weather information system.

Figure 1. Diagram. TMS structure with examples (Miller et al. 2021). 

The decisionmaking framework associated with traffic management, shown in figure 2, involves 

four stages:

• Monitor: Collect and process data from various field devices, third-party data sources, 

and partners to evaluate the current conditions of the transportation network.
4 

• Calculate and predict: Apply advanced data processing that combines current and 

historical information to predict the future state of the network and increased risk of 

impactful events. This phase also involves detecting/predicting events that will adversely 

impact traffic performance and warrant an operational response.

• Propose: Generate one or more response plans (i.e., sets of operational strategies, 

functions, and actions) to mitigate the effects of the traffic event.

• Select and implement: Select and execute the response plan most likely to best improve 

performance. 

Early generations of TMSs typically relied on users to manually perform the activities associated 

with the four decision stages. Today, the availability of computer-based DSTs can reduce the 

burden on operations staff. DSTs can facilitate data processing, automating forecasting, and 

prediction. They can provide visualization tools to improve how TMSs monitor current 

conditions and predict future conditions. They can also make recommendations to maximize the 

use of operational strategies, functions, and actions. As such, they can be integrated with TMSs 

to fully or partially automate processing and decisionmaking activities that may occur across 

these four stages. 

Source: FHWA.

Figure 2. Diagram. Traffic management decisionmaking (Miller et al. 2021). 

WHAT IS A DSS? 

Decision support is an overarching concept that embraces all the processes and tools that enable 

better, faster, and more consistent decisionmaking. Computer-based decision-support systems 

(DSSs) are used in several industries to improve business operations. Figure 3 depicts the 

taxonomy of DSTs adopted for this report. The report focuses on the “TMS Decision Support 

Tools” box within the diagram. 
5 

Source: FHWA.

Figure 3. Diagram. Taxonomy of decision support (Miller et al. 2021). 

DSTs

DSTs include online computer-based tools and offline noncomputer-based tools. Examples of 

offline tools are paper-based decision trees and decision tables that can be printed and collated 

into reference information. 

DSSs 

DSSs are computer-based tools that support business or operational decisionmaking. They 

encompass technologies and solutions used for online or offline decisionmaking as follows: 

• Online DSS are real-time, computer-based DSSs that support real-time traffic 

management and operational decisionmaking. 

• Offline DSSs are typically used to support both short-term and long-term planning. 

Examples of online tools that support real-time management and operation of TMSs include the 

following:

• Real-time traffic analysis tools have the potential to analyze data such as traffic 

conditions, weather, and transit system performance. The data can be integrated into the 

decisionmaking of how a TMS is managed and operated. For example, these tools can 

analyze data to enable improved decisionmaking for traffic signal timing.

• Look-up tables for traffic operational strategies and control plans simplify selecting 

operational strategies (e.g., ramp metering and lane control), control plans (e.g., time of 

day or demand responsive, open or closed), and actions to be implemented (e.g., incident 

response plans) based on conditions detected or projected to occur. While incident 
6 

response plans may be offline tools, look-up tables enable a simplified real-time process 

for selecting the appropriate plans.

Examples of offline tools for TMSs include the following:

• Maintenance DSSs and pavement management DSSs are examples of offline systems that 

agencies use to support maintenance activities.

• Incident response plans provide instructions for preestablished responses (e.g., plans and 

procedures) to different types of incidents, including processes for coordinating efforts 

among agencies and service providers. Agencies typically have plans developed to 

respond to a wide range of potential incidents, where the actions taken will vary based on 

location, time of day, severity, and conditions (e.g., traffic demand and weather). These 

plans enable consistent, rapid decisions, and they define how agencies and service 

providers respond to different types of incidents. 

• Decision trees allow an operator to complete a structured process to reach a decision 

consistent with the organization’s policies and accepted procedures. Through a series of 

questions, which usually have a few limited answers, operators can arrive at a decision 

regarding a specific issue.

• Performance monitoring, measuring, and reporting tools (e.g., spreadsheets and 

algorithms) generate individual measures of performance or summaries of overall 

performance based on current observed conditions and historical data. Examples of 

individual measures include travel time and travel delay indices. Examples of summaries 

include dashboards and reports that provide a snapshot of how the operation is 

performing based on industry-recognized measures. These summaries are typically 

generated by TMSs in realtime or on a daily, monthly, or annual basis. Such information 

enables policy makers and agency leaders to make better long-term decisions and helps 

the public understand how the system is performing. 

DST INTEGRATION: ASSESSING, PLANNING, AND DESIGNING

As agencies continue to plan for next-generation TMSs, they are considering what enhancements 

may be needed and what may be reasonable and feasible to implement to improve TMS 

performance and decisionmaking and enable the automation of decisions (e.g., tasks, functions). 

As many existing subsystems and components can be modified to support TMS integration, 

agencies may want to evaluate whether their current TMSs can be modified to enhance 

functionality. Based on this evaluation, an agency can decide whether it will reuse and modify an 

existing TMS or design and build a new TMS. The following questions can be examined during 

such evaluations: 

• What technologies may be appropriate to select? 

• What may be needed to support the integration and use of these new technologies? 

• What data may be needed for different functions or services? 
7 

• What translations (e.g., format changes) may be needed to enable data to be used for 

different functions or services? 

• What tools and accompanying software, if any, can be stand-alone or can be integrated 

into the software subsystem of the TMS? 

• What commercial off-the-shelf or open-source software products are acceptable, or 

would a commercial or proprietary product would be more appropriate? 

Once the requirements and capabilities of an existing TMS have been established and compared 

to desired requirements and capabilities, an agency can evaluate available products and 

technologies. If the agency concludes that no commercial off-the-shelf products or internal 

reusable product components are suitable, the agency can consider building its own TMS. Staff 

can identify and assess the potential build/buy/reuse decision alternatives (e.g., commercial 

off-the-shelf, open source, or proprietary) for each component of the TMS that may need to be 

revised. After staff conduct an analysis and reach decisions, staff can document recommended 

selections for technologies and products for each component. This process can be considered part 

of the system design. 

These issues and technologies are just some of the factors that agencies may consider. These 

decisions are further discussed in chapter 5, which includes details on the specific evaluations 

and decisions some agencies have made when integrating DSTs into their TMSs as examples. 

HOW TO USE THIS REPORT

This report explores the application of DSTs and processes for improving TMSs. State DOTs 

and local agencies may use the concepts and processes in this report to develop practices to plan, 

design, operate, monitor, evaluate, and report on the performance of decisionmaking with a 

TMC. Each chapter discusses key concepts of DSTs, lessons learned from case studies from the 

state of practice for DSTs, and the three common types of DSTs useful for traffic management: 

knowledge-driven DSTs, data-driven DSTs, and model-driven DSTs. 

The intended audience for this report is public agency staff, academia, and contractors involved 

in planning, designing, implementing, maintaining, managing, and operating TMSs. This report 

aims to help readers understand different types of tools that have the potential to improve the 

decisionmaking capabilities and performance of a TMS. Readers are assumed to have a general 

awareness of ITS technologies and TMSs. 

REPORT OVERVIEW

This report provides an overview of practices to consider when integrating DSTs into the 

real-time management and operation of a TMS. Additionally, it outlines issues to plan for when 

integrating DSTs into existing or new systems, requirements of DSTs and TMSs, and what to 

consider when integrating a DST with a TMS.

For this report, the study team conducted literature searches on existing research, TMS 

deployments, DSTs used in the transportation industry, and other resources for transportation 
8 

agencies (e.g., the Federal Highway Administration (FHWA) ITS program (FHWA 2021)). 

Information was also provided to the study team by individuals and agencies, as follows:

• During the 2018 Transportation Research Board (TRB) Workshop on DSTs for the NextGeneration of TMS (National Operations Center of Excellence 2018). 

• During the associated sessions and meetings of the TRB Committee on Freeway 

Operations (ACP20) (ACP20 2018). 

• From National Cooperative Highway Research Program (NCHRP) reports (Horowitz et 

al. 2014; Margiotta et al 2007). 

This report is organized as follows: 

• Chapter 1: Introduction—Introduces the concepts of TMSs and DSTs and provides an 

overview. 

• Chapter 2: Overview of DSTs—Discusses some of the DSTs used within a TMC for 

operations and planning. 

• Chapter 3: Decision Support and TMSs—Discusses the real-time decision-support 

subsystems used within a TMS.

• Chapter 4: TMS Decision-Support Needs—Describes the process of identifying agency 

needs a DST can meet. This process can be done early in the planning stages. The agency 

defines what the project will accomplish, establishes that the project is necessary, and 

provides the means to validate the success of the project.

• Chapter 5: Using DSTs—Describes the process of assessing an agency’s capabilities and 

existing DSTs (e.g., processes, procedures, business rules, noncomputer-based tools, 

datasets). Gathering this information allows an agency to identify DSTs that meet its

needs. Additionally, agencies can use this process to identify how to improve TMS 

management, operations, and capabilities. This identification will form the basis for the 

new DST to be implemented. Agencies may decide how and when to reuse existing 

DSTs, what modifications may be needed to create a new DST, and when and how to 

retire existing DSTs.

• Chapter 6: Selecting a DST for Traffic Management—Outlines the requirement and 

design phases, which take the project from understanding system and user needs to 

beginning system development. Major decisions about strategy and the integration

approach are made during these phases. Begins with a discussion of the set of stages that 

encompass these phases. 

• Chapter 7: Procuring and Implementing DSTs—Introduces issues agencies may consider 

when procuring a DST. Discusses how integration strategies influence procurement 

options, the procurement options best suited to meet an agency’s goals, and what types of 

products are compatible with agency policies and procedures. 
9 

• Chapter 8: Initiating the Use of DSTs—Provides an overview of the steps for preparing to 

operate and evaluate a DST once it has been developed, configured, deployed, and 

integrated into the TMS.

• Chapter 9: Monitoring, Evaluating, and Using a DST—Presents a discussion of effective 

practices and provides recommendations to agencies for validating and calibrating DSTs 

once they are deployed and operational. Discusses the process of continually monitoring

and evaluating DSTs to ensure they are meeting the goals, objectives, and performance 

metrics established by the agency.

• Chapter 10: Using and Maintaining DSTs—Provides an overview of the ongoing 

operations, monitoring, and maintenance of a DST once it has become operational. 

Outlines routine maintenance activities for each type of DST technology.

11 

CHAPTER 2. DECISIONMAKING AND DECISION-SUPPORT TOOLS

This chapter introduces the range of different types of DSTs agencies may use to sustain their 

traffic operations programs, including planning for day-to-day traffic operations, planning traffic 

management, and managing and operating TMSs. It summarizes the key factors that influence

decisionmaking, describes the concept of decision support, and highlights the types of DSTs 

typically used by agencies. Additionally, it examines how DSTs are used offline and online and 

how operational policies and procedures may affect the design and use of a DST by a TMS. 

This report focuses on the use of online DSTs to support the management and operation of a 

TMS. However, understanding the more general concepts associated with decision support and 

the range of tools at an agency’s disposal provides the reader with a clearer context of the 

potential benefits to enhance the next generation of TMSs.

The objectives of this chapter are to describe the following: 

• What factors influence decisionmaking. 

• How operations-related policies and procedures affect an agency’s decisions about the 

design or operation of a TMS. 

• How different types of DSTs can be used for various types of decisions, tasks, or 

functions carried out within a TMS. 

• What types of offline and online DSTs can be used within TMSs. 

This chapter helps the reader understand the concept of decision support and the tools used to 

assist in making operations-related decisions. Additionally, it discusses the types of tools that 

may be appropriate to integrate into the day-to-day operation of a TMS and provides examples of 

how these tools have been integrated and used by TMSs. Subsequently, chapter 3 will discuss

how these tools and processes are integrated and used to automate or improve specific tasks, 

functions, and operations of a TMS. 

TRAFFIC MANAGEMENT SYSTEMS

TMSs are the tool that agencies use to improve the management and operation of the surface 

transportation system. TMSs also share information with and support other traffic systems 

management and operations programs or initiatives. TMSs provide the functions, services, and 

capabilities for agencies to manage traffic, control ITS field devices, manage incidents and 

planned events, coordinate with stakeholders in response to these events, and provide 

information on travel conditions. 

A key feature of TMSs is helping operators make faster and more effective decisions in response 

to current and projected conditions (e.g., traffic, roadway infrastructure, weather, and events).

Decision-support capabilities have expanded to support or automate functions, decisions, and 

actions that TMS operators carry out or implement (e.g., ramp metering and identifying travel 

times). Recently designed TMSs can provide responses to multiple events. With increased focus 
12 

on integrated corridor management (ICM), newer TMSs have also begun the transition from 

managing, controlling, or coordinating travel on one type of facility to supporting several 

facilities (e.g., freeways, surface streets, and traffic signals).

FACTORS INFLUENCING DECISIONMAKING

Decisionmaking is often inherently complex. The challenges of decisionmaking may be 

compounded by decisionmakers’ experience levels, societal pressures, cultural norms, fatigue,

and inherent biases. These factors also impact the quality of the policies, procedures, programs, 

actions, services, and operational performances that result from the decisions. The effects of 

these limitations can become even more pronounced as systems grow in complexity, when 

decisions need to be made quickly, or when there is insufficient data or insufficient time to 

assess an incomprehensible amount of data. DSTs are designed to address these limitations, and 

over the years, these tools and associated processes have demonstrated their effectiveness across 

a variety of fields (e.g., medical diagnoses and emergency response). 

As transportation networks have grown more complex and congested, decision support has 

played a greater role in optimizing the efficiency and safety of the movement of people and 

goods. As the amount of information available for these networks continues to grow, DSTs can 

help process data and improve the quality of the decisions made, which will influence the 

performance of these complex systems.

The use of established processes and logical aids can offset some of the typical biases that arise 

when making decisions. Robinson et al. (2017) found that DSTs can minimize the influence of 

biases (e.g., confirmation bias) on decisions, ensure consideration of alternatives, and encourage 

quantitative assessment of options. However, the same study also found potential disadvantages 

to overly relying on DSTs, such as discounting intuition and experience. Despite these pitfalls, 

properly designed and implemented DSTs can be valuable assets to an operator in a TMS. 

Lukasik et al. (2011) found that the use of DSTs in transportation can leverage and improve on 

several recent advances in realtime traffic management and operation.

The Decision Support Concept

The concept of decision support emerged from theoretical studies of organizational 

decisionmaking. Initially, decision support generally focused on higher-level strategic decisions, 

and then expanded to include tools for supporting all types of decisions. The following three key 

computer-based DSSs eventually emerged, accompanied by an evolution from single-user to 

multiple-user approaches:

• Executive information systems—Ran on mainframe computers to package a company’s 

data and provide sales performance or market research statistics for decisionmakers. The 

intent was to develop computer applications that highlighted information to satisfy the

company’s strategic and program-planning needs. Typically, an executive information 

system would only provide high-level data that supported these decisions.
13 

• Group DSSs—Evolved from single-user to multiple-user computer-based systems. Group 

DSSs were designed to use inputs from numerous users simultaneously interacting with 

the system to arrive at a decision as a group.

• Organizational DSSs—Focused on coordinating and disseminating decisionmaking 

across functional areas and hierarchical layers. A key goal was to ensure that decisions 

were congruent with the organization’s goals and with management’s shared 

interpretation of the competitive environment.

Since decision support’s continued evolution as a field of study and practice during the 1980s, 

computing hardware has become more powerful—and, as more data have become available, 

DSSs have continued to evolve and improve. Today, many commercial products are available to 

build DSTs and provide decision-support functions across multiple industries. For example, 

many systems in the financial and medical industries have evolved since the early research. 

These systems assist decisionmakers across numerous topics, including loan processes, which 

financial instruments to purchase, and which medicines to prescribe.

TYPES OF DECISION-SUPPORT TOOLS

DSTs used within a TMS may be classified across two dimensions: the type of interaction and 

the approach used in the tool. The type of interaction refers to the level of human interaction with 

the DST—how decisions are made (manual or automated) and the degree to which the DST 

involves the decisionmaker (interactive or automated). Table 1 shows common approaches used 

in DSTs for traffic management.

Table 1. DSTs mapped to decision-support classifications. 

Approach

Incident 

Response 

Plans 

(Offline)

Decision 

Trees 

(Offline)

Performance 

Measurement 

Tools 

(Offline)

Real-Time 

Traffic 

Analysis Tools 

(Online)

Look-Up 

Tables 

(Online)

Knowledge-driven Yes Yes No Yes Yes

Data-driven No Yes Yes Yes Yes

Model-driven No No Yes Yes No

Three common approaches are used in DSTs for traffic management, as follows: 

• Knowledge-driven DSTs provide specialized problem-solving expertise based on the 

processing of stored facts, rules, procedures, and similar forms of knowledge. They 

attempt to emulate human reasoning but with more consistent results. Expert systems are 

the best-known type. They use databases of knowledge generated by previous expert 

users and a system’s business rules to emulate the decisionmaking capabilities of an 

expert user of the system. Based on this knowledge, such tools recommend actions to 

traffic operators. Knowledge-driven tools are different from table-based tools (e.g., 

decision tables) in the way knowledge is extracted, processed, and presented. The 

knowledge-driven DST attempts to emulate human reasoning; the table-based tool 

responds to all events in a predefined manner. The following are primary characteristics 

of knowledge-driven DSTs:
14 

o Provide recommendations based on human knowledge. 

o Apply a heuristic (i.e., practical, rule-of-thumb) technique for problem solving. 

• Data-driven DSTs use data to aid in the decisionmaking process. Data-driven DSTs use 

data from databases that can be queried and enable the processing and analysis of data to 

develop insights that support decisionmaking. One example is statistical analysis 

software, which is one of the most common types of DSTs. The effectiveness of a 

data-driven DST depends on the quality of the data gathered and the effectiveness of the 

decisionmaker’s analysis and interpretation. With many of the data analysis tools in use 

by the industry, transportation agencies can customize dashboards to display the data they 

want to see and run custom reports. Ongoing advances in how data can be accessed, 

analyzed, and visualized enable agency staff who do not have a technology background 

to work with analytical tools, analyze data, and make more informed decisions. The 

following are primary characteristics of data-driven DSTs:

o Summarize data into usable information. 

o Use large amounts of data and query and visualize the results of the analyses 

conducted in well-organized ways.

o Offer flexible reporting and analytical capabilities. 

• Model-driven DSTs use mathematical models and simulation tools that express the 

theoretical relationships among data elements or key variables of interest for an analysis 

being conducted. These tools can be used (online or offline) to simulate the behavior of a 

transportation system (or parts of the system) using different values for certain 

parameters. Model-driven DSTs use different types of analysis tools (e.g., statistical 

software and traffic analysis software) to assess the available data, evaluate the data, and 

report on conditions. Traffic analysis tools that use data captured by a TMS can be used 

offline or online to assess how the transportation network will perform based on various 

potential actions. Model-driven DSTs can be used in realtime as part of a TMS to predict 

the possible outcomes of actions a TMS is considering implementing, thereby allowing 

agencies to assess impacts on key metrics like travel time, environmental impacts, and 

person and vehicle throughput. The following are primary characteristics of model-driven 

DSTs:

o Provide what-if analysis based on historical and assumed (e.g., scenario-based) data. 

o Leverage algorithms and simulation and optimization tools to provide decision 

support. 

o Use data and parameters provided by decisionmakers to help analyze situations 

without the need for intense amounts of data input. 

DSSs are computer-based tools that support business or operational decisionmaking activities. 

This term encompasses a wide range of technologies and solutions used for online or offline 

decisionmaking. Within the framework of knowledge-driven, data-driven, and model-driven, 

TMSs commonly use a number of DSTs. These DSTs can be offline or online. 
15 

Offline DSTs 

Offline DSTs are typically used to support short-term and long-term activities related to 

transportation system management and operation planning, programming, and policy. 

Maintenance DSSs and pavement management DSSs are examples of offline systems that 

agencies use to support maintenance activities. The following sections describe examples of 

offline DSTs used in TMSs.

Incident Response Plans

An incident response plan is a predefined set of actions an agency performs based on the 

location, type, and expected impact of an incident (e.g., vehicle on shoulder and one or two lanes 

blocked). Within a TMS, the use of these plans as an offline tool may involve an operator 

viewing a plan from a printed document and implementing actions within a TMS. Many TMSs 

have incident response plan books that are developed based on experience. These plans provide 

operators with a playbook for how to respond to a particular incident. The responses will 

prescribe appropriate actions (e.g., temporary detours and traffic signal changes) and identify 

resources needed. Incident response plans are usually selected using a process in which operators 

monitor data from the TMS and manually select the response plan based on variables such as 

incident location, time of day, level of congestion (e.g., length of queue), and availability of 

detour routes; some TMSs have converted these offline tools into online tools. Either way, these 

incident response plans are static documents, either electronic or printed, that the operator uses to 

respond to an event. 

Within some TMSs, the software recommends to an operator which incident response to use 

based on business rules. Response plans might be based on the location, time of day, and severity 

of an incident. These plans are usually not integrated into the TMS, but a reference to the 

incident response plan is provided within the software. The TMS has basic business rules 

integrated into the software, which then selects the appropriate incident response plan based on 

the rules. Figure 4 shows a sample response for a major incident, including various field 

infrastructure and a suggested diversion route. 
16 

© 2010 Dallas Area Rapid Transit.

DART = Dallas Area Rapid Transit; EB = eastbound; LBJ Express = Lyndon Baines Johnson Expressway; 

NTTA = North Texas Tollway Authority; SB = southbound; TxDOT = Texas Department of Transportation; 

WB = westbound.

Figure 4. Illustration. Overview of a major incident response plan (Miller et al. 2021).

Based on the incident in figure 4, the incident response plan further defines the overall response 

plan and suggests individual agency actions (figure 5). 
17 

© 2010 Dallas Area Rapid Transit.

Rd = road.

Figure 5. Screenshot. Agency actions in a response plan for a major incident (Miller et 

al. 2021).

Decision Trees

A decision tree is an offline tool that enables an operator to work through a formalized process to 

reach a decision consistent with an agency’s accepted procedures and policies. Users answer 

questions that usually have a few limited answers to arrive at a decision about a specific issue. 

Decision trees are mostly used for planning, selecting additional equipment, and deploying 

Dallas 

• Frontage road : activate signal timing signal plan #32 and monitor every 15 min. 

Native Signal ID Name SmartNet Signal ID DIRECT Signal ID 

3455 CENTRAL@ UNIVERSITY 1010139110 2053 

3449 CENTRAL@ MOCKINGBIRD 1010139040 2061 

3453 CENTRAL@ SMU 1010139090 2081 

3468 CENTRAL@ SOUTHWESTERN 1010139240 2112 

3465 CENTRAL@ LOVERS 1010139210 2113 

3473 CARUTH HAVEN @ CENTRAL 1010139290 2126 

3496 CENTRAL SBFR@ WALNUT HILL 1010139520 2159 

3491 CENTRAL SBFR @ PARK LN 1010139470 2160 

3489 CENTRAL SBFR@ NORTH PARK S.C. 1010139450 2167 

3501 CENTRAL SBFR @ MEADOW 1010139570 2178 

5634 Central SB @ Churchill 1010142330 3141 

3766 FOREST LN @ CENTRAL SBSR 1010142280 3166 

3505 ROYALLN@CENTRALSBSR 1010139610 583 

• CCTV: monitor traffic conditions on Southbound US 75 Frontage Rd . every 15 min. 

TxDOT • DMS: 

Message ID Name SmartNet ID 

2 75_5B Meadow 5074420 

LBJ Express 

• DMS: 

Message ID Name SmartNet ID 

2 HOV 635_EB_Park Central 5074220 

DART • DMS: 

Message ID Name SmartNet ID 

2 HOV 75_SB Midpark 5074900 
18 

specific technologies. Some decision trees are developed to assist operators in consistently 

predicting incident durations. These decision trees provide a process with decision points and 

options; the operator then works through each decision point to reach a conclusion or action at 

the end. The decision tree is basically a series of questions with potential answers that are linked 

together to create a decision once the questions have been answered. 

For example, for a decision tree used in the Maryland Coordinated Highways Action Response 

Team (CHART) system, when a TMS operator is notified of an incident, the DST asks the 

operator a series of questions to help determine an approximate incident duration. The DST then 

provides the operator with an expected duration, which is entered into traffic management 

software. Table 2 and table 3 show the variables and outputs of part of the decision tree and the 

relations between incident clearance times and their associated factors. These relations and 

factors were derived from experience and historical data. 

Table 2. Maryland CHART incident duration decision tree.

No. Description of Classifier

Clearance 

Time (Min)

1 IF (road=I895 & incident_type=disabled) or (noTT=0 & 

noSDsh=0 & incident_type=disabled) or (noTT=0 & 

road=US50 & incident_type=disabled)

THEN Minor 

(<30)

2 ELSE-IF (OC=TOC3 & noLane=13 & county=MO & 

incident_type=cpd) or (noTT=0 & road=I495 & 

incident_type=disabled & pavement=dry) or (chart=1 & 

noLane=12 & road=I95 & incident_type=disabled)

THEN Minor 

(<30)

3 ELSE-IF (OC=TOC3 & SDBmain=minor & pavement=unspecified) 

or (OC=AOC_South & noLane=12 & road=US50) or 

(weekday & incident_type=disabled & detection=CHART)

THEN Minor 

(<30)

4 ELSE-IF (totalveh=2 & incident_type=fatality) or (night=0 & 

road=other & incident_type=fatality)

THEN Major 

(>120)

5 ELSE-IF (noTT=0 & county=3 & incident_type=disabled) or 

(OC=TOC3 & noSDBmain=0 & incident_type=cpd)

THEN Minor 

(<30)

6 ELSE-IF (noSUT=0 & non-holiday & exit=22 on I495, I270, I695, 

and US50) or (SDBmain=minor & county=MO & 

detection=CHART) or (noSDsh=2 & noSDBmain=0 & 

noODBsh=0 & incident_type=disabled)

THEN Minor 

(<30)

7 ELSE-IF (night=0 & noODBsh=0 & exit=31 on I495, I270, I695, 

and I83) or (noODmain=3 & SDBmain=minor & 

county=Anne Arundel) or (chart=1 & noLane=13 & 

noSDBmain=0 & peakhr=PMpk)

THEN Minor 

(<30)

8 ELSE-IF (noLane=12 & SDBmain=minor & road=I495 & 

incident_type=cpd) or (totalveh=2 & noSDBmain=0 & 

county=Frederick & incident_type=cpd) or (noLane=12 & 

noSDBsh=1 & incident_type=cpd & peakhr=PMpk)

THEN Minor 

(<30)

9 ELSE-IF (region=Baltimore & incident_type=cpi & 

detection=CCTV) or (county=BC & incident_type=cpi & 

pavement=unspecified & detection =MDTA) or 

(OC=AOC_Central & totalveh=3 & incident_type=cpi & 

non-holiday)

THEN Intermediate 

(30−120)

BC = Baltimore City; MDTA = Maryland Transportation Authority; MO = Montgomery; PG = Prince George’s. 
19 

Table 3. Descriptions of variables in an incident duration decision tree.

Variable Description

Incident_type Type of incidents:

• Disabled: disabled vehicles.

• Cpi: collision with personal injury.

• Cpd: collision with property damage.

• Fatality: collision with fatality.

• Fire: vehicle on fire.

• Unknown: no specific information available.

noTT Number of tractor trailers involved with incident

noPVS Number of pickup trucks, vans, and sports utility vehicles involved with incident

noSUT Number of single-unit trucks involved with incident

Totalveh Total number of vehicles involved with incident

noLane Number of lanes on both directions (including shoulders and medians)

noSDASH Number of shoulder lanes on the same direction as where an incident occurred

noSDBsh Number of blocked shoulder lanes on the same direction as where an incident occurred

noODsh Number of shoulder lanes on the opposite direction as where an incident occurred

noODBsh Number of blocked shoulder lanes on the opposite direction from where an incident 

occurred

noSDmain Number of main lanes on the same direction as where an incident occurred

noSDBmain Number of blocked main lanes on the same direction as where an incident occurred

SDBmain Ratio of number of blocked lanes to total number of lanes on the same direction as 

where an incident occurred

noODmain Number of main lanes on the opposite direction as where an incident occurred

noODBmain Number of blocked main lanes on the opposite direction as where an incident occurred

ODBmain Ratio of number of blocked lanes to total number of lanes on the opposite direction from

where an incident occurred

OC Responsible operation center

Pavement Pavement conditions: dry, wet, snow/ice, chemical wet, and unspecified

Chart If CHART is involved in the clearance, 1; otherwise, 0

Detection Incident detection sources

Night If an incident occurs between 8 p.m. and 6 a.m., 1.

Peakhr • AMpk: a.m. peak periods (7–9:30 a.m.)

• PMpk: p.m. peak periods (4–6:30 p.m.)

• Non-pk: off-peak periods

Region • Washington: Fredrick, Montgomery, Prince George’s, District of Columbia.

• Baltimore: Anne Arundel, Baltimore City, Baltimore, Carroll, Harford, 

Howard.

• Eastern: Caroline, Cecil, Dorchester, Kent, Queen Anne’s, Somerset, Talbot, 

Wicomico, Worcester.

• Southern: Calvert, Charles, Saint Mary’s.

• Western: Allegany, Garrett, Washington.

AM = morning; PM = evening.

Through the combination of these variables and associated questions, the decision tree provides 

the operator with an expected duration after answering questions provided by the DST. 
20 

Performance Measurement Tools

Performance measurement tools (e.g., monitoring and reports) provide regularly scheduled 

performance indicators for various aspects of the surface transportation system. Performance 

monitoring tools generate individual measures of performance or summaries of overall 

performance based on the monitoring of current conditions and historical data. Performance 

measures or reports (e.g., dashboard summaries) can be used by TMSs as an offline DST, as 

shown in figure 6. They can assist operators in identifying bottlenecks and areas of recurring 

incidents that may need further investigation for mitigation strategies (e.g., signing, marking, and 

roadway cross-section changes). 

© 2019 University of Maryland Center for Advanced Transportation Technology Laboratory (CATT Lab).

Note: Screenshot created by CATT Lab using the Bottleneck Ranking Tool from the Regional Integrated 

Transportation Information System Probe Data Analytics Suite. 

Figure 6. Screenshot. Top 1,000 ranked bottleneck locations in Maryland, District of 

Columbia, and Virginia between October 1 and October 31, 2019 (Miller et al. 2021).

Online DSTs 

Online DSTs are real-time computer-based tools that support real-time traffic management and 

operational decisionmaking. These tools can be separate from or fully integrated with a TMS. 

The following are examples of online DSTs that are used in TMSs and can be fully integrated 

into the real-time operation of a TMS. 
21 

Real-Time Traffic Analysis Tools

As stated in Traffic Analysis Toolbox Volume I: Traffic Analysis Tools Primer, “Traffic analysis 

tools are designed to assist transportation professionals in evaluating the strategies that best 

address the transportation needs of their jurisdiction” (Alexiadis et al. 2004, 5). 

Traffic analysis tools are designed to help evaluate the strategies used to address the 

transportation needs of a jurisdiction. The term is collective and describes both software-based 

analytical procedures and methodologies that support aspects of traffic and transportation 

analyses. Methodologies include sketch planning, travel demand modeling, traffic signal 

optimization, and traffic simulation. Collectively, traffic analysis tools can help practitioners do 

the following: 

• Improve process of decisionmaking and help practitioners arrive at better planning and 

engineering decisions for complex transportation problems. They can estimate the impact 

of traffic management and other strategies after deployment and help to set priorities 

among competing projects. They can also provide a consistent approach for comparing 

potential improvements or alternatives.

• Improve outcomes of decisionmaking. They can estimate the impacts of various 

strategies and help decisionmakers set priorities among competing projects. Traffic 

analysis tools can also provide a consistent approach for comparing potential 

improvements or alternatives.

• Reduce disruptions to traffic. Traffic management and control strategies come in many 

forms and options. Analytical tools provide a way to estimate the effects prior to full 

deployment of the management strategy. They may be used to initially test new TMS 

concepts without the inconvenience of a field experiment. 

• Facilitate evaluations to prioritize planning and operational alternatives. This aspect

typically involves comparing no-build conditions with alternatives that include various 

types of potential improvements. The impacts are reported as performance measures and 

are defined as the difference between the no-build and alternative scenarios. The results 

can be used to select the best alternative or prioritize improvements, with the goal of 

increasing the odds of a successful deployment. 

• Make improvements in design and evaluation time and cost. Traffic analysis tools are 

relatively less costly when compared to pilot studies, field experiments, or full 

implementation costs. Furthermore, analytical tools can be used to assess multiple 

deployment combinations or other complex scenarios in a relatively short time.

• Illustrate strategies to stakeholders and the public. Some traffic analysis tools have 

graphic and animation displays that can be used as tools to show what-if scenarios to 

stakeholders and the public. 
22 

• Support operation and management of existing roadway capacity. Some tools provide 

optimization capabilities, recommending the best design or control strategies to maximize 

the performance of a transportation facility.

• Monitor performance of existing transportation facilities. Analytical tools can also be 

used to evaluate and monitor performance. In the future, it is hoped that monitoring 

systems can be directly linked to analytical tools for a more direct and real-time analysis 

process.

Highway Capacity SoftwareTM (HCSTM) is a common traffic analysis tool that agencies and 

transportation professionals use (McTrans Center 2022). HCS is the software version of the 

Highway Capacity Manual (HCM) (TRB 2016). The HCM contains concepts, information, and 

procedures for computing the capacity and quality of service of various highway facilities and 

the effects of mass transit, pedestrians, and bicycles on the performance of these systems. HCS 

implements the procedures defined in the HCM to enable users to analyze various types of 

transportation infrastructure. With known traffic volumes and many other inputs, HCS can 

determine the current and projected level of service (LOS) and allows agencies to analyze 

various transportation data and explore possible improvements to their transportation networks. 

The following are key characteristics of the HCM: 

• Closed form—The practitioner inputs the data and parameters. After a sequence of 

analytical steps, the HCM procedures produce a single answer. 

• Macroscopic—Inputs and outputs produce average performance during a 15-min or 1-h 

analysis period. 

• Deterministic—Any given set of inputs yields the same answer every time.

• Static—They predict average operating conditions over a fixed period, and they do not 

deal with transitions in operations from one system state to another. 

The tools in the HCM quickly predict capacity, density, speed, delay, and queuing on a variety of 

transportation facilities and are validated with field data, laboratory test beds, and small-scale 

experiments. Quick Streets (figure 7) is a spreadsheet add-in that converts traffic input data to an 

HCS Streets file (McTrans Center 2022). Users can import traffic count data from any source for 

the spreadsheet to use with HCS Streets. Quick Streets populates an HCS Streets file with 

multiple intersections, multiple periods, or both. It allows the user to save the input data to an 

HCS Streets file and launches the data directly, provided that HCS is installed on the user’s 

computer. 
23 

© McTrans Center. Original spreadsheet: HCS Streets. 

Figure 7. Screenshot. Quick Streets add-in interface (Miller et al. 2021). 

Look-Up Tables

A look-up table is a DST that provides a table or matrix of conditions and responses to assist 

operators with consistent responses to events. While incident response plans may be offline 

tools, look-up tables integrated into a software program or routines coded into a software 

program will enable a real-time process for automating the selection of the appropriate plans. 

Look-up tables provide an online tool where operators enter a few values. The DST then uses 

algorithms embedded in a software program to calculate the desired output (e.g., plan, action) for 

a TMS operator to implement. The decision tree example shown in table 2 can be converted to an 

online DST, where an operator enters several variables (e.g., location, event type, and number of 

lanes blocked) into a single screen, and the duration is then calculated. The difference is that the 

decision tree asks one question at a time, but the look-up table asks several things 

simultaneously. 

As an example, look-up tables are currently used in TMSs for traffic signal timing as part of an 

incident response plan. When an operator enters an incident’s information into the TMS, certain 

basic information is collected through an event management screen. The DST uses the 

information provided by the operator, the current time of day, the congestion levels or LOS of an 

intersection, and the direction of a detour route to select a specific timing plan in response to the 

event. A look-up table can be thought of as a multivariable matrix coded into the TMS software. 

Table 4 shows the input variables the TMS’s DST uses to select an existing traffic signal timing 

plan as part of a response plan. The intersection number is the signalized intersection that is part 

of the response plan. The time of day is based on local operations and typical rush hour times. 

The day of the week can be a weekday, weekend day, or specific day of the week. The current 

LOS is an indication of how much congestion the intersection is currently experiencing, based on 

traffic engineering principles. Lastly, the detour direction is the direction the traffic signal timing 
24 

plan is trying to optimize for the detour. A look-up table provides the TMS with the output of a 

timing plan number for each combination of variables shown. 

Table 4. Input variables within a look-up table.

Intersection 

Number Time of Day Day of Week Current LOS

Detour 

Direction

A-1 Morning peak Weekday A, B, C Northbound

A-2 Evening peak Weekend day D Southbound

A-3 Off peak — E Eastbound

A-4 — — F Westbound

—No data.

Creating the look-up table would require creating multivariable data within the data subsystem 

used by the DST software subsystem to look up the signal timing plan number for a specific 

traffic signal when all other variables are known. 
25 

CHAPTER 3. INTEGRATING DECISION-SUPPORT TOOLS INTO TRAFFIC 

MANAGEMENT SYSTEMS

This chapter provides an overview of the subsystems used to assist in making decisions within 

TMSs and those systems with an operations center. As described in chapter 1, decision support 

enables better, faster, and more consistent decisionmaking. DSTs include all the different 

resources (e.g., look-up tables and analysis models) that can be used to improve decisions. The 

use of DSTs online or in the real-time management and operation of a TMS requires integration 

with the software and data subsystems. 

The objectives of this chapter are to describe the following: 

• Key functions of TMSs. 

• Considerations for integrating DSTs into TMSs. 

• Capability ranges for DSTs when integrated into the real-time operation of a TMS. 

This chapter details the functions of DSTs, how they support decisionmaking and can be 

integrated for this purpose, and the types of data that are used and shared with various TMS 

subsystems. It seeks to increase readers’ understanding of the capabilities of DSTs and their 

utility in managing and operating a TMS. 

KEY TMS FUNCTIONS

Traffic operational strategies are functions and actions to improve the management and operation 

of roadway networks, optimize performance, and improve safety. Agency goals, policies, 

procedures, and performance metrics inform the deployment and use of operational strategies. 

In the early days, operational strategies performed by freeway-based TMSs focused on basic 

functions such as monitoring traffic conditions and collecting traffic data. As time went on, 

agencies started using traffic data to enhance their operational strategies. Functions evolved from 

basic monitoring and data collection to regulating access, managing incidents, and providing 

traveler information.

As technology continues to evolve, the functionality to collect and manage more complex forms 

of data has also evolved. This evolution of functionality shapes the way agencies implement 

operational strategies, as they can leverage more data to make informed decisions. As agencies 

upgrade their components and software, the timeframe for decisionmaking and responding to 

changing conditions has improved. 

As discussed in the second section of chapter 1, the decisionmaking framework associated with 

traffic management involves four decision stages, which have the following functions: 

• Monitor. 

• Calculate and predict. 

• Propose. 

• Select and implement. 
26 

Operational strategies are enabled by specific functions and actions. Functions that can be 

implemented to support operational strategies include the following:

• Monitor roadway conditions. 

• Collect weather information. 

• Perform roadway maintenance during weather incidents. 

• Analyze collected data. 

• Disseminate traveler information. 

• Deploy speed limit reductions or speed advisories. 

• Use predictive decision-support software to assist operators in system adjustments and 

overrides. 

• Provide traffic detection and surveillance. 

• Manage incidents and special events. 

• Manage freeway ramps. 

• Manage preferential and priced lanes. 

• Coordinate among agencies. 

• Monitor and evaluate system performance. 

Figure 8 breaks down these functions into subfunctions. The following three sections in this 

chapter discuss the functions in more detail. 

Source: FHWA.

Figure 8. Diagram. Key functions of a TMS with DSTs (Miller et al. 2021). 

Monitor 

The monitor function includes many subfunctions focused on data and information review. 

During the monitoring process, DSTs monitor data and information available to TMSs to detect 

changes. When changes occur, DSTs move to the next function, calculate and predict. The 

following subsections outline types of data and information reviewed during the monitor 

function. 
27 

Transportation Network Data 

Depending on the field devices used to collect data and the facilities or services being monitored, 

this subfunction may include monitoring a range of various types of data (e.g., speed, volume, 

occupancy, travel time, transit vehicle location, and transit service schedule adherence) stored on 

the data subsystem. New data sources—including connected vehicle (CV) data—will provide a 

tremendous amount of other data (e.g., hard braking, windshield wiper activation). CV data will 

provide TMSs with additional information on the conditions of the transportation network. 

Travel Patterns

This subfunction includes monitoring vehicle trips throughout a network based on origins and 

destinations using data including transit routes, turning movements at intersections, and 

transportation flow patterns. Monitoring routes allows the system to calculate travel times, assess 

schedule adherence for transit vehicles, and use these data to determine where congestion is 

occurring. 

Device Status

This subfunction includes monitoring the state and status of devices (e.g., dynamic message 

signs (DMSs) and traffic signals) and assets (e.g., transit buses, pumping stations, and air quality 

sensors). 

Weather and Roadway Conditions 

This subfunction includes monitoring travel conditions on roadways, occupancy levels on transit 

vehicles, and queues at intersections. Its process also looks at weather and environmental 

variables (e.g., moisture or water on roads, wind, precipitation, pavement temperature, and air 

quality). 

Events

This subfunction includes monitoring incidents, construction, and special events within a 

transportation network (e.g., vehicle crashes, transit bus breakdowns, and construction projects). 

Calculate and Predict

The calculate and predict function uses a variety of DSTs, which can include algorithms, rules 

engines, and models. (See chapter 5 for a more detailed discussion.) These DSTs are integrated 

into the software subsystem and can use data in the data subsystem to assess current conditions, 

identify when actions may be needed, and make predictions based on assessments of data from 

the monitor function. The DSTs used can be for a specific function or action or can be more 

advanced and perform multiple different calculations in support of the functions or actions they 

are designed to support. The following sections outline conditions that can be predicted during 

the calculate and predict function. 
28 

Traffic Conditions

Algorithms and models assess and report on current and predicted future travel conditions (e.g., 

LOS, congestion levels, and weather), with and without potential actions, on roadways being 

monitored. These calculations are usually based on historical information from similar times of 

day and accepted engineering formulas, and they have the potential to predict the timing and 

location of weather conditions and crashes (e.g., location, type, and severity) by using models. 

Travel Times

Algorithms and software applications (e.g., traffic simulation models) integrated into a software 

subsystem predict travel times in the future with and without potential actions (i.e., the results of 

using a specific response compared to no action). Similar to predicting traffic, this prediction 

function estimates travel times based on current conditions or a future period. These predictions 

are usually based on historical information from similar times of day, weather conditions, and 

congestion levels. 

Weather

Weather forecasting models (or services) predict current and future conditions for specific 

locations. The weather models use current and predicted weather conditions (e.g., wind, 

precipitation, and storm direction and speed) to determine conditions on a roadway on a 

link-by-link basis. This feature allows DSTs to consider the weather on a specific route. 

Events

Algorithms and software applications on a software subsystem predict the probability of 

occurrences of unplanned events (e.g., crashes) and the likely impacts of events. This function 

typically uses historical crash data to predict probable potential locations for crashes. These 

predictions are based on current traffic and weather conditions, day of week, severity of any 

conditions, and time of day. Agencies can use this information to deploy response vehicles 

preemptively across networks. Additionally, this information can be used to select response plans 

for unplanned and planned events (e.g., incidents, construction, and special events). 

Roadway Surface Conditions 

Weather forecasting models (or services), road weather information system sensors, and 

historical data predict roadway surface conditions. Roadway maintenance providers use this 

information to predict weather and roadway conditions and optimize road surface treatments. 

Treatments can then be timed appropriately, and treatment locations and frequencies can be 

ranked based on where the effects of weather events are most severe. 

Propose, Select, and Implement

The propose, select, and implement functions involve actions that an agency can take or 

implement based on information generated during the calculate and predict function—if an 

acceptance is needed prior to implementation. Some agencies are able to automate the select and 

implement function as their TMSs mature and confidence grows in their response calculations, 
29 

which provide the basis for making these selections. However, the number of agencies using this 

functionality remains small. The automation of these functions can be based on the established 

policies, procedures, expertise, and experience of an agency’s operations staff and on the 

capabilities of a TMS. By applying calibration techniques used in the transportation modeling 

industry, agencies can develop and calibrate their prediction models and algorithms. These 

models and algorithms need agencies to routinely monitor, evaluate, test, and make changes as 

more data are collected and TMSs are operated. The following sections outline primary 

subfunctions for the propose, select, and implement functions. 

Operational Responses 

Operational responses use predefined and dynamic response plans that suggest actions an agency 

can use to respond to changes in the transportation network. These response plans usually consist 

of changing the operation of devices, such as traffic signal timings, DMS messages, ramp 

metering rates, and lane control indicators. Responses also include deploying specific assets to 

the field, such as safety service patrols and temporary DMSs. This subfunction selects predefined 

response plans agencies have previously developed or use rules and algorithms to create a 

response plan based on its calculations. 

Traveler Information

The traveler information subfunction disseminates information to the public about transportation 

network changes and recommended responses. Dissemination can include messages on DMSs, 

information within agency 511 systems, highway advisory radio messages, and various social 

media messages. This subfunction also provides special response plans for America's Missing: 

Broadcast Emergency Response (AMBER) Alerts, Silver Alerts, and other special events. 

Maintenance Activities

The maintenance activity subfunction uses outputs from the weather and road surface condition 

subfunctions (in the calculate and predict function) to implement specific maintenance activities 

related to weather, such as snow removal, salt applications, and road closures. It also implements 

actions for other environmental incidents, such as alerts for poor air quality or high water levels. 

For some systems, this subfunction can also identify other required maintenance activities, such 

as preventative or emergency maintenance for devices, roads, and transit vehicles. 

Services

The services subfunction uses output from the calculate and predict functions to request services 

from entities outside of a TMS. The services requested may include wrecker services, emergency 

services, and other services needed to fully respond to an event managed by a TMS. 

Stakeholder Communication 

The stakeholder communication subfunction informs stakeholders about TMS actions. 

Communication mechanisms include stakeholder requests for TMSs to perform actions as part of 

ICM programs. 
30 

DST INCORPORATION INTO TRAFFIC MANAGEMENT SYSTEMS

Objectives for incorporating DSTs into TMSs may include automating or supporting 

decisionmaking required by operators and actively managing and operating the surface 

transportation network. Any DST integrated into a TMS may require an interface, and there are 

generally certain procedures that must be followed for an operator or analyst to integrate and use 

a DST. The DST (and/or its software) may need to be integrated with a software subsystem, data 

subsystem, computing hardware, and DST-generated data users or decisions (data can be 

translated into appropriate formats, if needed). This integration process enables sharing and using 

the data generated by the tool. The following sections discuss issues to consider with these key 

interfaces. 

Data Subsystem

The core functions of a data subsystem are to provide data processing and storage for the TMS 

and support access to the data by other subsystems and external users. The data subsystem uses 

application programming interfaces (APIs) to interface with other subsystems or components 

that extract, send, and enable the data to be transformed and loaded into the database in the TMS. 

An API specifies how software programs may interact, the data they exchange, and how the data 

are exchanged (i.e., format and type). 

The data subsystem also receives data from external sources by using APIs or interfaces to 

receive the data, translate them into the appropriate formats, and save them. Once the data are 

received, the data subsystem uses tools to check and manage within the subsystem so that data 

use is efficient, timely, and easy to maintain. The data subsystem needs to have the following

functionalities to support any DST integrated into the operation of a TMS: 

• Retrieve data from all sources available to the TMS in a timely fashion, as they become 

available, including real-time data streams and data that are updated less frequently (or 

even manually).

• Catalog data received in an electronically accessible data catalog. 

• Transform data received into a format suitable for storage, processing, and retrieval by 

users and other applications. 

• Secure data so that they are only accessible according to the usage policy and 

authorization parameters of the agency. 

• Manage user and application accounts, authentication, and authorization for accessing the 

data subsystem. 

• Encrypt communications and data between the data subsystem and its users. 

• Provide access to all data appropriate for the user making the request. 

• Provide data to authenticated and authorized users in a timely fashion, including data in 

storage and real-time data streams. 
31 

• Sustain the level of availability and performance necessary to support the operations of 

the TMS. 

• Produce and provide status and diagnostic information to support the operation, 

maintenance, and management of the data subsystem. 

Interfaces With Software for DSTs 

The TMS data subsystem uses APIs to integrate the data and functions of software programs 

installed on this subsystem or to share data with other subsystems. There are two types of APIs 

or interfaces typically developed and integrated into the software subsystem:

• Data providers (provide data to the TMS): The provider usually dictates the interfaces 

and the process, protocols, and requirements (e.g., formats) for receiving and using data 

from their system. The provider may furnish the associated API documentation (e.g., data 

dictionary, release notes, configuration guide, and user guide) to follow. 

• Data subscribers (receive data from the TMS): The TMS typically dictates the data 

interfaces, and the subscribers develop their interfaces to meet the TMS requirements 

specified for the appropriate processes, protocols, and formats. The TMS provides the 

subscriber with an associated schema or data definition.

Figure 9 shows an example of a data subsystem that includes multiple databases with various 

sources generating and submitting data, which are extracted, transformed, and loaded into 

databases within the data subsystem.

© 2017 Florida Department of Transportation (FDOT). 

GIS = geographic information system.

Figure 9. Diagram. Sample data subsystem (Miller et al. 2021). 
32 

An API is developed for each data source, as each source will have data in different formats and 

will potentially use different protocols to send or receive data. Each API communicates with the 

data source, extracts the data, translates the data from the data source to the TMS system format, 

and then stores the data in the TMS database. For the TMS to provide data to other systems, an 

API interfaces with each TMS subsystem or other systems external to the TMS, where these 

systems may be subscribers and providers of data. For instance, the data subsystem may have a 

database specifically for storing traveler information that a statewide 511 system wants to use. 

The 511 system will then use the API to connect to the data subsystem and extract that 

information. Within the 511 system, an API will also be needed and will be integrated with its 

software to translate the data from the TMS database format to the format of the database the 511 

system uses.

Figure 9 includes neither the use of the data nor the potential to control the field devices; rather, 

it is an example of the process within a TMS for carrying out functions supported by the 

software for a DST integrated into the software subsystem. The analytics and reporting functions 

shown are typically separate software that interface to the database to use and analyze the data 

for various reports and dashboards. 

APIs are developed and installed between the DST and TMS subsystems or field devices to 

exchange data, issue commands, and integrate the operation of each system. Figure 10 illustrates 

the process to extract, transform, and load (ETL) data from external sources into a specific 

database on the data subsystem. The source systems provide APIs to developers who develop the 

tools, processes, and other information that use or incorporate the data. 

Source: FHWA.

Figure 10. Diagram. ETL process (Miller et al. 2021). 

Software Subsystem

The software subsystem includes the programs that support the functions and services of the 

TMS. This subsystem will share some software products with the entire TMS and specific 

software programs installed for other subsystems or DSTs. The various engines are shown in 

figure 11. 
33 

Source: FHWA.

Figure 11. Diagram. Software subsystem and installed software (Miller et al. 2021). 

Assorted software programs and APIs are integrated into this overall software subsystem to carry 

out all management and operating requirements of the system. A software subsystem can include 

multiple different software programs (e.g., commercial off-the-shelf software and proprietary), as 

shown in table 5. 

Table 5. Software for different types of DSTs.

Software Products Knowledge-Driven Data-Driven Model-Driven

Rules engine Yes Yes Yes

Algorithm Yes Yes Yes

Simulation software No Yes Yes

Machine learning Yes Yes Yes

These software products can be divided into two main categories: software products that will be 

part of any TMS and software products unique to DSTs. 
34 

Software Products Typically Used in TMSs

The primary types of software used in any TMS include the software needed to host the TMS on 

the computing hardware and some specialized functions, described as follows: 

• ETL tools—Provide the functions for extracting data from the data interfaces, 

transforming the data into a specified format, then loading the data into a database to save 

for future use. Many ETL tools were originally developed to make it easier to save, 

access, and use data. ETL tools replace handwriting Structured Query Language code 

with drag-and-drop functionality to develop or make changes to a database when new 

data sources are introduced.

• Operating system software—Manages computer hardware, subsystems, and software 

programs installed on the software subsystem and provides common services to support 

managing, maintaining, and operating the software subsystem. 

• Database software—Forms the database management system, which is a tool that makes 

it possible to organize data within a database. Several commercial off-the-shelf and 

open-source database software products are generally used in TMSs today. 

• Security—Uses software that manages user profiles and access to the TMS. Security 

software is sometimes a part of the operating system or an agency’s larger network (i.e., 

active directory). In other instances, a TMS will have its own security and user 

permissions. A DST may need separate dedicated security software to manage users and 

access to other software components.

• User interface (UI)—Provides users with a way to interact with the TMS and DST. UIs 

display information on the status of the transportation network, events, recommended 

responses, and the expected performance of the transportation network with and without 

the recommended response.

Software Products Unique to DSTs

Four types of software are typically used when integrating a DST or its associated software 

program. Table 5 shows the software that may be used in the three classifications of DSTs 

described in chapter 2. These software systems may have the ability to allow agencies to easily 

add or make changes when needed. The ability to easily make changes helps ensure the agency 

can continue to modify and evolve the capabilities of its system as the demands and needs of the 

system change. These four types of software are described in the following four sections.

Rules Engine 

A rules engine is a software program or code integrated into or via an API to execute business 

rules used to make decisions in a DST. The rules might originate from external laws and 

regulations, agency policies, or other sources. Rules are configured and integrated into the rules 

engine software program to execute required functions or prepare information needed to support 

decisions. System developers or agencies can use several commercial products to develop a 
35 

rules-based DST without having to completely develop custom code; these tools still need 

configuration and integration into agency systems to provide the desired functionality by 

operating agencies.

• A rules engine can be used when the following four conditions occur: 

o An agency has developed complex scenarios with simple rules. 

o An agency has not identified an algorithmic solution. 

o A TMS has endured ever-changing scenarios. 

o An agency has needed to make decisions quickly, usually based on partial data. 

• A rules engine generally is not used when the following three conditions occur: 

o The project involves very few self-contained rules. 

o The business logic rarely changes.

o The application demands rigid control of the execution flow. 

Algorithms 

Algorithms and software may use logical and mathematical formulas to calculate outputs 

(e.g., data, recommended actions) needed by a DST. The algorithms are usually based on 

specific formulas and may include engineering (e.g., traffic flow and environmental 

calculations), statistical (e.g., averages and means), and financial (e.g., cost and benefit) 

calculations. For example, HCS uses industry-recognized formulas and logic to process data and 

calculate results used for operations. Some agencies have integrated HCS into their TMSs for 

various traffic engineering analyses in realtime and nonrealtime (e.g., signal timing analysis). 

Using an API, the HCS receives data from a TMS requesting the HCS calculate a specific 

formula. Once the HCS calculates the result using an API, HCS provides the TMS with the 

result.

Simulation Software 

Simulation software uses calibrated models to determine how a transportation network will 

perform based on various potential actions. Simulation can be used in realtime to determine 

effects on travel time, various environmental impacts, and person and vehicle throughput. 

Simulation tools integrated into a TMS as part of a DST can enhance an agency’s ability to 

analyze strategies and perform complex data calculation in realtime. In certain cases, simulations 

can also offer predictive capabilities. Online modeling tools can be an effective way to predict 

future traffic conditions and thus are desirable—although not strictly required. Simulation 

software may be expensive to purchase, set up, and maintain; however, if used correctly, it can 

provide benefits. As confidence increases in the simulation software’s results and agencies 

become more comfortable with its recommendations, a higher level of automation among TMS 

functions can be considered. 

Machine Learning 

Machine learning (ML) is based on the idea that data can be analyzed to identify patterns, and 

software can learn to make decisions based on these patterns with minimal human intervention. 
36 

ML software uses formulas that software developers and data scientists integrate into the 

software. The software uses the formulas to recognize patterns and learns how to optimize the 

ML software based on historical data and patterns. As more data become available, the quality 

and accuracy of the recommended or automated actions that use the formulas also improve. ML 

software may be challenging to set up and maintain due to the amount of data required to 

calibrate the learning algorithms. However, if calibrated correctly and monitored, it may provide 

benefits and lead to a higher level of automation among TMS functions. 

Computing Hardware Subsystem

The computing hardware subsystem can vary depending on its purpose and location. A DST and 

its accompanying software program may be a part of a field device, traffic controller, TMS, or 

TMC. The computing hardware subsystem for a TMS is usually shared to provide economies of 

scale and reduce the overall cost. Most agencies use standard IT servers to host the software and 

database subsystems. The computing hardware includes servers with necessary processors and 

memory, network communication equipment (e.g., routers and switches) to enable data 

exchange, and data storage systems (e.g., storage area networks and hard drives), which are used 

for storing the software and data within the subsystem. 

The capacity and performance requirements of the computing hardware are directly related to the 

functionality of the TMS, the processing power needed, and the amount of data involved. When 

considering computing hardware, agencies usually find they need to determine the requirements 

of the TMS and any specific DST, including processing and memory needs. This report does not 

offer information on how to select the appropriate computing hardware components; rather, 

agencies should use their IT department standards and sizing methodologies to select from 

existing options. 

UIs Specific to a DST

A UI provides a visual means of interacting with a TMS using elements such as windows, icons, 

and menus. These elements are also used by most modern operating systems. Various UIs may 

need to be developed, either separately or by modifying the TMS to integrate the interface into it. 

The method of development depends on the function the DST is performing, how the software or 

algorithms are managed, and the tools used within the TMS. 

For example, the Dallas ICM project consisted of three UIs, because three separate pieces of 

software were developed by three different companies. The primary interface was the operator

UI, which was a modification to the existing TMS that allowed operators from all the agencies in 

the region to view its transportation data and manage events cooperatively through a 

recommended response plan. The TMS also had two administrative interfaces—one to manage 

the rules and algorithms for selecting response plans and another to manage the predictive 

model. However, ideally, a TMS will be modified to provide a single UI. 

A graphical user interface (GUI), shown in figure 12, provides stakeholder agencies with a 

web-based information exchange tool. A GUI enables agencies to share information and manage

incidents, construction, and special event information. A GUI is the presentation layer for the 

TMS. The Dallas ICM GUI enabled agency users to manage and monitor the status of their 
37 

transportation networks, giving them a full event management capability and allowing them to 

make informed decisions about the management of their transportation infrastructure

(FHWA 2015). 

© 2015 Dallas Area Rapid Transit. 

Figure 12. Screenshot. Dallas ICM project operator UI (Miller et al. 2021). 

The main functionalities of a TMS’s GUI software program are to do the following: 

• Provide stakeholders with the ability to exchange data regarding incidents, construction, 

and special events in an interactive manner. 

• Include an event management module that allows stakeholders and partner agencies to 

create incident or planned event trackers within the system and manage these events from 

detection to resolution. 

• Provide the current status of devices and roadway and transit networks within the 

corridor on a map and through lists. 

• Provide incident response plan information to corridor stakeholders. 

• Monitor the status of recommended and implemented response plans from plan 

recommendation to incident resolution. 

Figure 13 shows two rules engine administration interfaces for the Dallas ICM TMS. The 

administrator used these interfaces to view the current events and data received by the system 
38 

(top left screenshot) and determine whether they match the rules within the rules engine (lower

right screenshot).

© 2015 Dallas Area Rapid Transit.

Figure 13. Screenshot. Dallas ICM project business rules component UI (Miller et al. 2021). 

The data input screen provides a time-stamped list of the event data received by the rules engine, 

the evaluation performed by the engine, and the actions the rules engine recommended. The rules 

evaluation screen shows a list of the active events within the TMS and which rules within the 

rules engine can be applied. This list shows the location of the event (Rule ID translated from the 

actual roadway link), number of lanes affected (percentage of lanes affected based on the total 

number of lanes), queue length (miles of backup from incident location), average speed on the 

roadway and potential diversion routes, transit and park and ride utilization (percentage full), and 

response status (if the event and rules were met and a recommendation was made). The DST 

administrator uses the information provided in these interfaces to troubleshoot errors and analyze 

why the DST selected a response to ensure the DST is operating correctly. The Dallas-area 

agencies used this information at their monthly operations meetings to decide if changes to the 

rules were needed and provide metrics on the use of the DST (e.g., number of events where it 

was used) (FHWA 2015). 

The Dallas ICM TMS also used simulation software to predict the performance of the 

recommended response plan from the rules engine versus a do-nothing response. Figure 14
39 

shows the interface for the simulation software to assess two such scenarios. Once the simulation 

software modeled the do-nothing and recommended responses, it provided a performance 

measure for both the recommended response plan and the do-nothing response option. If the 

recommended response plan improved the average travel time through the corridor for an 

individual vehicle by more than 2 percent, the response plan was recommended; otherwise, a 

do-nothing response was recommended. 

© 2015 Dallas Area Rapid Transit.

Figure 14. Screenshot. Dallas ICM project prediction component UI (Miller et al. 2021). 

Logical Architecture of a TMS

Fully integrating a DST into a TMS provides a single software program to support all the 

functions of the tool. An advantage of integrating a DST into the software subsystem of the TMS 

is that a smaller computing hardware footprint can be used, maintained, and managed. Upgrading 

and changing the software program or API for a DST may only be needed in one location, 

depending on how the TMS is structured or designed. If a DST is not located in the software 

subsystem, any upgrade may need revisions to the software. Additionally, both the APIs and the 

TMS’s UI may need to be upgraded as well. 

One example of a fully integrated system is the Maryland CHART TMS. The goal of the 

CHART system is to manage freeway and arterial traffic flows more efficiently and safely. 

When freeways and other primary routes are unexpectedly congested, the TMS recommends 

response plans based on business rules. These response plans include changes in DMS messages, 

detour routes, and traffic signal timing plans. Arterial signal systems provide remote and 

adaptive traffic signal control and coordinated signal timing. Traffic signal technicians and 
40 

CHART system operators can better balance demand and capacity by adjusting traffic signal 

timing remotely through the TMS. An advantage of this system is that operators of different 

experience levels are likely to respond to incidents in a consistent manner—a new operator can

respond with the same response plan as an operator who has years of experience. By integrating 

the DST with the CHART TMS, the Maryland State Highway Administration can reduce the 

computing hardware needed, only employ a single systems developer, and more easily make 

system updates to the TMS (Chart.maryland.gov n.d.; FHWA 2015). 

An example of a fully integrated software subsystem is the Australian VicRoads TMS

(figure 15). The Australian VicRoads TMS implements a feature called dynamic plan selection. 

Depending on the density of traffic and the dominant direction of traffic (e.g., inbound, 

outbound, or bidirectional) on a road, nearby signalized intersections are operated using several 

predefined traffic plans. A user sets up the signal timing and picks the traffic density levels and 

direction that apply. The system then automatically selects the appropriate signal timing. When a 

time-based traffic plan schedule is inappropriate due to varying traffic levels, the system

automatically adapts the signal timing plan. The Australian VicRoads TMS uses many of the 

same functions as the CHART system, but it uses a real-time model to calculate congestion, 

travel times, and other measures used to manage and operate the transportation network 

(FHWA 2015). 

© 2018 Adam Myers.

Figure 15. Diagram. VicRoads TMS decision-support subsystems architecture

(Myers 2018). 

The Australian VicRoads is fully integrated and provides a shared data subsystem, computing 

hardware, and UI. The software is integrated into the TMS so that VicRoads uses a single fully 

integrated TMS. Similar to the CHART system, an advantage of the Australian VicRoads is the

reduced costs for the computing hardware, data subsystem, and ongoing operations and 

maintenance of the TMS. The Australian VicRoads software provides each of the four functions 

discussed earlier in this chapter, as follows (FHWA 2015): 
41 

• Monitor: The Australian VicRoads TMS collects and processes data from various 

systems, including devices and other traffic systems (left side of figure 15). It analyzes 

this information to determine when the data have changed and compares them to the data 

in the historical data server.

• Calculate and predict: The Australian VicRoads DST uses traffic signal algorithms and 

models to make traffic signal timing calculations and recommendations. 

• Propose: The Australian VicRoads DST provides recommendations to the TMS operator 

to improve the performance of the transportation network based on the output of the 

traffic signal timing plans that are selected or created within the calculate and predict 

function. 

• Select and implement: The Australian VicRoads TMS automatically changes the signal 

timing plans in the affected traffic signal controllers, deploys messages on DMSs, and 

provides traveler information through various media when the TMS operator approves 

proposed actions. 

The architecture shown in figure 15 is mapped directly to the Australian VicRoads subsystems, 

as shown in figure 16. 

Source: FHWA.

Figure 16. Diagram. VicRoads TMS mapped to the four key subsystems of TMCs (Miller et

al. 2021). 
42 

The data subsystem includes APIs to receive data from external systems and field devices and 

provides data to those systems through the Gateway, business intelligence, and public traffic data 

components shown in figure 15. The software subsystem consists of the application and the 

experimental algorithms. The application comprises the TMS capabilities, while the 

experimental algorithms provide additional decision-support software functions. The computing 

hardware consists of the application server and the data server. The data server provides some of 

the computing hardware for the data, and the application server provides the computing hardware 

for the TMS. The UI provides a map-based interface for the operators to monitor, control, and 

manage traffic on the streets and highways. The subsystem UI is called Explorer.
43 

CHAPTER 4. TRAFFIC MANAGEMENT SYSTEM DECISION-SUPPORT NEEDS

This chapter describes the process of planning for and integrating DSTs into a TMS. It examines 

the needs, requirements, benefits, and issues to consider when integrating a DST into a TMS and 

its TMC.

The objectives of this chapter are as follows: 

• To describe the issues agencies should consider before making an investment in a DST. 

• To frame the needs for decisionmaking in the context of overall TMS system planning. 

• To describe the strategies that can be used to assess the decision-support needs of a TMS. 

• To present a process for evaluating and developing needs for DSTs.

This chapter introduces the issues an agency might consider as it evaluates its TMS capabilities, 

plans to improve the system, and considers its decisionmaking needs. It also identifies 

institutional issues to consider in these processes and in making decisions involving TMSs. After 

reading this chapter, the reader should better understand the needs and implications of integrating 

a DST into a TMS. 

DST SELECTION AND USE: ISSUES TO CONSIDER BEFOREHAND

As stated in the Systems Engineering Guidebook for Intelligent Transportation Systems 3.0: 

Needs assessment is an activity accomplished early in system development to ensure that 

the system meets the most important needs of the project’s stakeholders. The goal is to 

ensure that their needs are well understood before starting development. In many cases, 

there will be more needs than can be met, even conflicting needs (California Department 

of Transportation and FHWA 2009, 39). 

When considering a DST, agency practitioners can judge whether they are trying to solve issues 

the agency’s existing TMS does not address. The following questions should be considered prior 

to pursuing a DST: 

• What needs or issues does the agency seek to solve? 

• What constraints does the agency face in implementing a solution?

• What decisionmaking process is presently in place? 

• What information and performance data are currently considered and can be used as 

starting points for framing other alternatives?

An agency may want to assess situations where decision support can possibly be beneficial or 

steps in the existing process that have bottlenecks or potential for human error. It may identify 

and assess how decisions are currently made and evaluated and the information and tools used to 

support decisionmaking. These steps can lead an agency to identify where in its decisionmaking 

process support tools, including a DST, may potentially assist users in their task flows.
44 

UNDERSTANDING NEEDS IN THE CONTEXT OF OVERALL SYSTEM PLANNING

The processes for determining needs; assessing feasibility; and planning, designing, and 

implementing a DST may seem complex. However, following the systems engineering process 

and answering questions at each step may be an option for designing, pursuing or procuring, and 

implementing a DST. Systems engineering is an organized approach to developing and 

implementing a system. The International Council on Systems Engineering (INCOSE) defines 

systems engineering as follows: 

[Systems engineering is] an interdisciplinary approach and means to enable the 

realization of successful systems. It focuses on defining customer needs and functionality 

early in the development cycle, documenting requirements, then proceeding with design 

synthesis and system validation while considering the complete problem (INCOSE 2011). 

It is valuable to use the systems engineering approach in designing ITS infrastructure so that the 

technology effectively supports the management and operation of the transportation system. In 

addition, applying the systems engineering approach is consistent with 23 Code of Federal 

Regulation (CFR) Section (§) 940.11(a), which states that all “ITS projects funded with highway 

trust funds shall be based on a systems engineering analysis” (National Archives eCFR 2022). 

Assessing Traffic System Needs

A project team should consider assessing needs as a part of the overall planning, design, and 

implementation process for a DST. The key steps are as follows: 

• Assess the current capabilities and performance: This assessment usually begins with 

gathering information about the overall landscape of the traffic system being managed. 

Identify existing capabilities, available data sources, and desires for enhanced 

capabilities. Gather input from stakeholders, who can often be identified by examining 

complaints or concerns about certain decision points that indicate problems. 

• Identify the user needs, evaluate them, and analyze gaps: Build on information gathered 

in the first step to conduct a more detailed stakeholder needs assessment and gap 

analysis. Identify shortcomings and elicit stakeholders’ needs, desires, and constraints. 

Needs assessments can help the project team and agency set aside preconceived notions 

of what the DST may accomplish. 

• Develop a concept of operations (ConOps): The ConOps frames the overall system, 

including specifying the problems to be addressed by the DST on the basis of user needs. 

The ConOps identifies the stakeholders, elements, and capabilities of the planned DST. It 

may also establish relationships among the stakeholders and system elements, including 

the flow of information and processes to be performed. 
45 

The project team should consider the following high-level issues in determining the 

appropriateness of a DST:

• A DST is often well-suited to environments requiring structured and quick 

decisionmaking, particularly multitiered decisionmaking across a range of transportation 

modes and agencies.

• A DST offers a mechanism for managing, harnessing, and optimizing the power of 

information as ever-growing volumes and varieties of data with increasing complexity 

become available to transportation practitioners.

• A DST potentially facilitates fast, structured, objective decisionmaking that builds on the 

experience of experts and promotes collaboration across multiple agencies, transportation 

modes, and stakeholder groups.

• A DST possibly lessens the risk of unintended operator bias in actions and 

decisionmaking because it relies on empirical data and structured rulemaking. 

• A DST potentially assists with predicting adverse transportation conditions and 

identifying corresponding mitigation strategies if it is suitably designed and implemented. 

Once a project team determines a DST may be an option to meet its needs, the team can conduct 

a more in-depth evaluation of circumstances and conditions, examining the following issues: 

• At what level of implementation will the DST function? 

o Implementation levels may correspond to offline strategic uses for long-term 

decisionmaking. Historically, DSSs that might not have included data from a TMS 

(e.g., asset management and traffic analysis) were used for this purpose. 

o A TMS, device, or TMS operator may make online, real-time traffic management 

decisions that can be used as an integrated tool within the TMS. 

• What roles and responsibilities might system users undertake, including agency personnel 

(operators, managers, etc.) and those at partner or stakeholder organizations? 

• What modality will present information to operators and other users? Will information be 

presented using visual displays, through alerts, or by other means? 

• What timeline will decisionmaking follow? What time demands will system users have? 

How much time is available to implement recommended actions? Are there gaps between 

the time it currently takes to make decisions and the timeframe when those decisions are 

actually needed? 

• What types of data, information, and requirements will the DST need to achieve the 

desired functions and performance? How detailed will the recommended actions 

communicated to users need to be?
46 

• What is the expected benefit of the selected DST, given the data required and 

improvements in performance, versus other types of DSTs that can be used?

• What is the return on investment for the expense of development, implementation, 

management, and use of different types of data? Is the DST worth the added expense?

STEPS TO IDENTIFY NEEDS FOR A DST

The purpose of the needs-gathering process is to move a project from the phase of considering a 

DST as a concept to the phase of designing a DST. The goal is to create a clear enough vision of 

the project to support the system design and subsequent verification. 

Understanding stakeholder needs is key; without a clear understanding of stakeholder needs, a 

DST may drift and lose value to the organization. Needs gathering for a DST can be complicated 

by the fact that the project often introduces changes into how operators perform tasks or 

functions. It is important that the needs-gathering process asks people what they need to do their 

jobs in the future rather than what they need to do their jobs today. 

Gathering needs and requirements is a structured, but not rigid, process. This distinction can be 

important because stakeholders will often learn about DSTs as the process unfolds and may want 

to revise their needs statements as they learn more about what DSTs can do for them. It is helpful 

for stakeholders to be open to this kind of iterative process to develop or refine DST needs and 

requirements. Figure 17 shows the five steps in the needs assessment process for a DST.

Source: FHWA.

Figure 17. Diagram. Needs gathering for a DST. 

Step 1—Identify Stakeholders and DST Goals 

Clearly state what the project hopes to accomplish and identify all stakeholders who may be 

affected by or use a DST. Ensure the list of stakeholders is comprehensive and looks beyond the 
47 

end users of the new system. Stakeholders are not limited to system users. The list can include 

anyone with a stake in the system from an institutional, operational, or technical perspective.

Step 2—Elicit and Document User and System Needs

Engage with all stakeholders to learn about and document what they need to accomplish project 

goals. This process has multiple stages, which may include workshops, interviews, and data 

analysis. Project sponsors may need to educate stakeholders about DSTs, as many of them may 

not understand the potential. 

Step 3—Reconcile, Validate, and Prioritize Needs

The input from stakeholders may have conflicts and gaps. Consolidate the input, resolve any 

conflicts, and fill in any gaps. Present a unified vision of all the DST needs back to the 

stakeholders. Confirm the result holds value for everyone. Prioritize needs, as the project may 

not have the resources to address them all.

Step 4—Verify System Is Feasible and Necessary

At this point, a clear, coherent picture emerges of what needs the DST will and will not address. 

Confirm with stakeholders the resulting vision is feasible and necessary.

Step 5—Define Project Scope

Budget and time constraints may make it infeasible to build the entire DST at once. Review the 

complete requirements and partition them into subprojects that can be completed as time and 

resources allow if necessary.

NEEDS ASSESSMENT STRATEGIES

Once needs gathering is completed, a needs assessment is appropriate to pursue. A needs 

assessment is a systematic process for understanding and evaluating underlying gaps between 

desired and actual conditions. It can be used to plan for evaluating the options to change the 

system or process and to improve current processes and activities. This section discusses some 

generic approaches to performing a needs assessment. While it is beyond the scope of this 

chapter to provide complete instructions for performing a needs assessment, examples and 

additional information are provided in the following sections. For instance, the National Oceanic 

and Atmospheric Administration (NOAA) uses the following 12-step needs assessment process 

(NOAA 2018): 

1. Confirm the issue and audiences.

2. Establish the planning team. 

3. Establish the goals and objectives. 

4. Characterize the audience. 

5. Conduct an information and literature search. 

6. Select the data-collection methods. 

7. Determine the sampling scheme. 

8. Design and pilot the collection instrument. 
48 

9. Gather and report the data. 

10. Analyze the data. 

11. Manage the data. 

12. Synthesize the data and create a report. 

The following two sections summarize the generalized techniques for identifying and 

understanding needs—strengths, weaknesses, opportunities, threat analysis, and gap analysis. For 

information about needs assessment approaches and models, see Needs Assessment: An 

Overview (Altschuld 2010). 

Determining the Need for a DST

The five steps identified in the previous section can be tailored for gathering and assessing 

decisionmaking needs among transportation system management and operations staff and agency 

executives. A needs assessment for a DST can be adjusted to use different methodologies and 

focus on specific areas. The following five processes can be used for eliciting needs for decision 

support: 

• Structured interviews—Uses questionnaires and interviews with operators and agencies 

to document current problems and issues the DST may help solve. 

• Decision analysis—Reviews operator actions and TMS decisions from previous incidents 

and events. 

• Data analysis—Analyzes data from the TMS to identify issues, bottlenecks, and missing 

functionality that can be improved through the DST. 

• Technical analysis—Reviews the computing hardware and software to identify issues that 

can be reduced or eliminated with updates to the system. 

• Decision-support orientation—Provides a list of expectations from project stakeholders 

and ensures commitment of resources. 

Additional information and examples of DST needs assessments can be found in Tavasszy, 

Smeenk, and Ruijgrok’s (1998) journal article titled “A DSS for Modelling Logistic Chains in 

Freight Transportation.” Additionally, Robinson et al (2017) discussed this topic in their report 

titled Elements of Business Rules and Decision Support Systems Within Integrated Corridor 

Management: Understanding the Intersection of These Three Components. 

Identifying Gaps and Opportunities To Improve Decisionmaking

A gap analysis assesses existing systems and processes. Additionally, it identifies needs that are 

not currently being met by the tools and processes that are already in use to assist with making 

decisions within a TMS. A gap analysis is a process for comparing actual performance with 

desired or potential performance. A gap analysis is a process that involves many issues and 

considerations; therefore, this report provides only a summary and then suggests additional 

sources for further reading. Following is a high-level overview of the process for identifying 

gaps, especially for DSTs: 
49 

• Identify current processes used for making key decisions and managing software, APIs, 

and DSTs.

• Identify current outcomes impacted by these domains. 

• Compare the current outcomes to the desired outcomes (i.e., how might decisions and 

DSTs operate in an ideal environment?). 

• Document each gap specifically and in detail.

• Identify the process for closing each gap (i.e., current situation to desired outcome). 

• Focus resources on eliminating the gap (e.g., restructuring or changing processes 

involved in decisions or implementing DST improvements). 

Table 6 through table 10 provide a summary of possible questions and issues to consider in 

support of assessing the needs for a DST.
50 

Table 6. Agency-related questions and considerations for determining decision-support 

needs.

Question

Area of 

Consideration Consideration

How is the agency 

currently managing 

decisionmaking?

Big picture and 

overall motivations

• Document current decisionmaking process.

• Specify what works well and what is deficient.

• Identify gaps between current decisionmaking 

processes and what is needed.

What issues is the agency 

trying to solve?

Big picture and 

overall motivations

• Determine clear performance goals and 

priorities.

• Devote sufficient time and effort to fully 

defining the problem before considering 

solutions.

What overall constraints 

does the agency face?

Big picture and 

overall motivations

• Be mindful of trade-offs, not only in DST 

design but also in agency goals, when 

diverting resources to DST implementation.

• Look for both obvious and subtle boundaries 

in the decisionmaking process, making certain 

that identified decisionmaking is appropriate 

(e.g., TMS-level); also, distinguish between 

operator and manager decisions.

• Identify the range of situations and accessible 

data.

Who are the users and at 

what level will they operate 

the DST?

Users and expertise • Consider user backgrounds and changing 

workforce skills.

• Consider user reactions, including acceptance 

and feedback.

Who will administer the 

DST?

Command and 

control

• Have clearly designated roles been defined?

• What is the skill base and experience of the 

staff administering the DST?

• How is the DST going to be administered, 

monitored, and updated?

Will there be a direct line 

of command? Will

responsibility be given to a 

sole office, or will there be 

joint responsibility?

Command and 

control

• Clearly outline responsibility across various 

situations (if joint responsibility). 

• Clearly outline priority across various 

situations.
51 

Table 7. DST-related questions and considerations for determining decision-support needs.

Question

Area of 

Consideration Consideration

What are the lifecycle

expectations of the DST?

Lifecycle • Consider all elements of the project lifecycle, 

including the development process.

• Consider not only immediate integration issues, 

but also the simplicity of integrating with newer 

subsystems and components in the future.

Will the DST have the 

ability to be updated 

modularly, or will a new 

system have to be 

installed each time?

Updating and 

maintenance

Evaluate this question in coordination with the 

lifecycle expectations.

How much skill will be 

needed to update it, and 

who will do the 

updating?

Updating and 

maintenance

• Consider making minor changes in-house so the 

system can be adaptable to constantly changing 

demands.

• Develop maintenance and updating plans early on.

How will the system be 

maintained, and will 

resources be allocated for 

maintenance?

Updating and 

maintenance

The cost of maintenance and updating can often 

get overlooked (to the detriment of long-term 

viability of the DST).

Who will pay for the 

DST, and how will it be 

funded?

Funding Investigate nontraditional avenues such as 

public-private partnerships; this aspect will tie 

into administration and responsibility.

What DST solutions 

already exist?

Existing solutions 

and subsystems

Do not limit the search to transportation; also look 

at DSTs in other fields.

Are there subsystem 

considerations in 

deciding on a new DST?

Existing solutions 

and subsystems

The best DST still has to work well in the 

environment it is being integrated into.

What are the differences 

between open source and

commercial 

off-the-shelf?

Existing solutions 

and subsystems

• Consider a combination, with some proprietary 

components and some open-source add-ons or 

vice versa.

• Assess any limitations on allowable functionality, 

the sharing of data among partners, etc. carefully 

when proprietary components will be in the 

system. 
52 

Table 8. Existing infrastructure, interface, and integration questions and considerations for 

determining decision-support needs.

Question

Area of 

Consideration Consideration

Can an older DST be 

modified and borrowed 

from to meet the current 

needs?

Existing 

solutions and 

subsystems

Borrow lessons and steps from earlier uses of a 

DST even if the entire system cannot address 

current needs.

What is the maturity of the 

system infrastructure that 

will support the 

implementation of the 

DST?

Existing 

infrastructure 

Even if the design process for the DST 

coordinates with infrastructure early on, it is 

imperative to determine its boundaries; it is easier 

to change a developing DST than to change a 

well-established system already in place.

What systems are in place 

the DST can build from?

Existing 

infrastructure 

Check for existing components that can be reused 

in the DST or data that are already useful to a 

DST as they are.

What will be the constraints 

on interfacing the TMS to 

the DST so that the two can 

work together seamlessly?

Interface and 

integration

• Clearly map out potential barriers to interfacing.

• Keep in mind the importance of user acceptance 

and usability in the DST interface. (The DST may 

provide accurate recommendations, but they will 

not matter if the operator does not understand 

them.)

Can the DST and TMS 

share components, and is 

the DST partially integrated 

into the TMS?

Interface and 

integration

Investigate the amount of sharing that will occur 

between the DST and the overall TMS, which can 

be both advantageous and problematic.

What are the issues and 

considerations to consider 

for a completely integrated 

DST and TMS 

combination?

Interface and 

integration

Weigh the benefits and costs of completely 

integrating the DST and TMS.

What are the considerations 

for choosing a distributed 

DST that combines

interfacing with the TMS 

and being integrated?

Interface and 

integration

Outline the pros and cons of a distributed DST 

and determine agency needs.

How will information 

exchanges occur, especially 

between different agency 

systems?

Interface and 

integration

Finding clear ways to communicate across legacy 

systems is challenging but try to minimize the 

workload needs for this task. 
53 

Table 9. Questions and considerations related to organizational and stakeholder support 

for determining decision-support needs.

Question

Area of 

Consideration Consideration

How can the impact and 

success of a DST be 

evaluated and assessed?

Evaluation and 

performance

• Evaluate the performance of the DST in 

comparison to similar systems or to no system at 

all (all-human decisionmaking). 

• Expect that performance will become increasingly 

important as DSTs become more capable of 

iteratively updating and adapting due to real-time 

feedback. Performance assessment is often 

overlooked in DST deployment (even outside of 

transportation). 

How can organizational 

buy-in and support 

(especially at the most 

senior levels) be secured?

Business case 

for a DST

Develop the case for direct benefits in performance 

and the cost for senior management.

What is the business case 

for implementing a DST?

Business case 

for a DST

Look beyond just economic benefits; consider 

overall efficiency and stakeholder satisfaction.

Are stakeholders aware 

of the need for a DST, 

and are they involved in 

the process early on?

Business case 

for a DST

• Hold discussions with stakeholders from the 

beginning to understand their concerns, fears, and 

misconceptions about what DSTs can and cannot 

do; stakeholders and users are often omitted in 

early design planning (only to be brought in when 

things go wrong).

• Present business cases to stakeholders so that they 

are aware of potential benefits.

• Engage stakeholders in the process early in the 

planning and encourage their ongoing involvement 

throughout DST development and implementation; 

secure stakeholder buy-in.

What are some strategies 

for engaging stakeholders 

and incorporating their 

needs and insights into 

the DST development

and planning process?

Business case 

for a DST

Map out stakeholder needs and the goals and 

benefits they seek from using a DST (even if it is

not what was originally planned) based on the

discussions with them. 
54 

Table 10. Implementation-related questions and considerations for determining 

decision-support needs.

Question

Area of 

Consideration Consideration

What operational or 

procedural challenges 

can impact successful 

implementation of the 

DST?

Business case 

for a DST

• Work with leadership and stakeholders to identify 

both internal and external sources of resistance (and 

potential strategies to lessen resistance). 

• Look for ways to fit DST operations and 

recommendations within cross-agency realities, as 

DSTs often provide recommendations in a 

political/procedural vacuum (e.g., ICM). 

• Define objectives to consider the context of the 

network, traffic demand, network configuration, 

user/mode mixture, land use, and time of day; based 

on the context, the DST can be implemented to 

identify the most appropriate objective and 

performance measure.

Programmatic 

considerations

Business case 

for a DST

Ensure the planned DST will be capable of 

responding to the range of operational objectives 

appropriate for the subject network.

What programmatic 

challenges may impede 

DST implementation 

and success?

Business case 

for a DST

Identify areas where overall program processes may 

run counter to the idealized DST implementation and 

find room for compromise (while focusing on the 

long-term goals).

What are the workforce 

challenges to the design 

and implementation of a 

DST?

Business case 

for a DST

Tie the workforce changes and challenges back to the 

user assessment noted earlier, because it is important 

that the user workforce buys into the system if it is to 

succeed.

What are the potential 

system procurement 

approaches and 

avenues?

Business case 

for a DST

• Tie this question to the earlier funding sources 

sections and coordinate.

• Choose contract mechanisms and approaches likely 

to accelerate system planning and development, 

optimize innovation, and minimize risk to the 

procuring entity.

DEVELOPING AND USING SYSTEM REQUIREMENTS FOR DST AND TMS 

ASSESSMENTS

Requirements are the foundation for building TMSs or ITSs. They determine what the system 

does and drive system development. Requirements are used to determine if the project team had 

built the system correctly. The requirements development process identifies the activities for

producing a set of complete and verifiable requirements. This process is central to defining the 

key functions and performance requirements of the system. 
55 

The requirements development process is also important for defining and describing functions 

and requirements to a sufficient level of detail such that a TMS or system can be designed, 

procured, and implemented. A system and subsystems requirements document organizes 

information about the system, including overall system functionality, internal and external 

interfaces, constraints, performance, reliability, maintainability, availability, safety, and security. 

A system requirements specification can provide stakeholders with an opportunity to verify that 

aspects of the system have been adequately captured and the project is ready for software and 

hardware development and implementation (i.e., build and test). 

ADDITIONAL RESOURCES

The following resources can assist with developing and understanding system requirements:

• California Department of Transportation and FHWA’s (2009) Systems Engineering 

Guidebook for Intelligent Transportation Systems 3.0 provides an overview of system 

requirements development and a template for documenting requirements. It also provides 

recommendations on defining needs and using them to develop requirements.

• International Organization for Standardization’s (ISO) (2011) Guidance for the 

Development of the Set of Requirements, System Requirements Specification (SyRS) is a 

standard that can be used to develop the system requirements specifications.

• Florida Department of Transportation’s (FDOT) (2005) Statewide Systems Engineering 

Management Plan for Intelligent Transportation Systems explains requirements 

development and provides a template for documenting system and subsystem 

requirements.

In the initial stages of requirements development, stakeholders make decisions by consensus to 

initiate and finalize the system needs, which are used to develop requirements. The requirements 

development process may be difficult, especially with many stakeholders. One way to begin is to 

create questions about the proposed DST requirements and then answer the questions with the 

consensus of the stakeholders. The requirements development step enables agencies to 

communicate what the system can do to meet the needs stakeholders have identified. 

An agency can also establish environmental and nonfunctional requirements that define under 

what conditions the system may function to meet performance goals. Identifying system 

requirements can be at the discrete component level or at a higher level that can encompass 

certain systems, such as virtual TMSs, active TMSs, temporary TMSs, and testing programs and 

procedures. 

Following is a list of possible questions about DST requirements to start from; these questions

may need to be revisited multiple times during the requirements development process: 

• What operational decisions and tasks can ideally be performed more rapidly and with 

greater consistency?
56 

• What operational decisions and tasks may heavily rely on the individual operator’s 

experience and knowledge? 

• What operational decisions and tasks may be so complicated or cumbersome that they are 

overly burdensome to some operators? 

• What operational tasks should be prioritized for improvement? 

• What constraints will exist for the DST (e.g., IT requirements, existing systems to be 

used, data interfaces)?

• What methods will be used to measure the DST’s actual operational performance against 

its expected performance (e.g., providing responses in a specific amount of time, 

providing the correct responses)?

• What outcomes are desired?

• What performance measures will be used to measure success?

• What requirements can be derived from those measures?

These questions may need to be answered for each identified function rather than answered only 

once for the entire system.

Types of Requirements for DSTs 

Requirements development is an iterative process. Developing requirements for a DST begins by 

analyzing needs to develop high-level requirements to meet those needs, decomposing the 

high-level requirements into system requirements, and then further decomposing down to several 

levels of software requirements. The requirements document answers the following questions: 

• What is the software intended to do? What functions can it perform?

• How does the software interact with people, the system’s hardware, other hardware, and 

other software? What interfaces does it need?

• What information and data does the system need? What data can the system store, use, 

and provide? 

• What speed, availability, response time, and recovery time do various software functions

require? What is the expected performance?

• What, if any, standards are in effect? What implementation language, policies, resource 

limits, and operation environments are necessary? What are the design constraints?
57 

These questions can be answered by classifying requirements into the following five types: 

• F = functional. 

• I = interface (interface between the TMS and external systems). 

• D = data (internally store, send, and receive data within the TMS). 

• C = constraint. 

• P = performance. 

In software engineering, many other requirement types are used depending on a software team’s 

methodology and expertise. However, these five types of requirements are sufficient for most 

TMSs, DSTs, and projects looking to explore DSTs. 

For example, the FDOT District 5 ICM project had more than 20 needs related to the TMS and 

DST, two of which are provided in table 11. After several project briefings, questionnaires, and 

stakeholder interviews, FDOT developed a set of user needs. After reviewing and discussing the 

user needs at a workshop, stakeholders reached a consensus on which needs were truly necessary 

(FDOT 2022). 

Table 11. Example decision-support subsystem needs.

No. Need Need Description

9 Need to store pre-agreed 

incident response plans 

Corridor agencies need a means to collect and store 

pre-agreed response plans to allow corridor agencies 

to understand collective roles and responsibilities, 

communicate effectively, and improve response 

times in reacting to events within the corridor.

16 Need to assess the impact of 

an enacted response plan on 

the transportation network 

During the response to an event in the corridor, 

agencies need to be able to determine if the 

preplanned response is effective and if the response 

is having the intended effect. This process includes 

verifying what conditions exist after implementing 

the response. If the operators of the systems 

determine their response is not effective, they may

be able to change components within their response 

plans or implement a new response plan.

In table 11, user need number nine is not a direct DST user need, but it identifies some of the 

functionality the system can have to support the DST functionality. The system requirements 

may include the need to store the pre-agreed incident response plans used by the DST to inform 

stakeholders about which response plan to enact or follow. This need implies several functions 

the system must provide to support the operation of the TMS—for example, response plans must

be stored, accessed by users, and understood before the rules engine can be involved in selecting 

the appropriate response. Another example is an administrative function to enable staff to add, 

modify, and delete plans.

Stakeholders for the FDOT ICM project wanted functionality that evaluated the impact a 

proposed response plan had on the transportation network; specifically, they wanted the calculate 
58 

and predict and propose functions. The DST they envisioned provided a real-time integrated 

model that could predict the impact of the various proposed response plans within a few minutes

(FDOT 2022). User need number 16 in table 11 identifies this need and provides additional 

requirements in the need description. Needs are not solution-specific; thus, although it could be 

argued that a specific technology will be used to assess the impact of an enacted response plan 

on the transportation network, many technologies may potentially meet this need. 

When developing requirements for software-based systems, a well-written requirements 

document will: 

• Establish the basis for an agreement between agencies and suppliers on what TMS and 

DST products will do. 

• Reduce the development effort. 

• Provide a basis for estimating costs and schedules. 

• Provide a baseline for validation and verification. 

• Become a basis for later enhancements (especially if an agency does not have the funds 

to do the entire project at once). 

As described in the Institute of Electrical and Electronics Engineers (IEEE) (1998) standard 

IEEE 830-1998 IEEE Recommended Practice for Software Requirements Specifications, 

agencies should consider several basic categories when developing software requirements 

documents. These categories include type of requirement, expected verification method, and 

importance of requirement. 

How Requirements May Vary Within a System 

The relationships among requirements can be well-defined to show how the requirements form a 

complete system. Each requirement can be uniquely identified (i.e., have a specific number or 

name). This identification can reflect the linkages and relationships between requirements. 

Agencies can show this hierarchy in many ways, but the hierarchy agencies select should trace 

back to the need statements developed during the planning process. As an example, the FDOT 

District 5 Regional ICM System (R–ICMS) requirements used a numbering scheme to indicate 

the following hierarchy (FDOT 2022): 

• Level 0—High-level system requirements = 1. 

• Level 1—TMS software system level = 1.X. 

• Level 2—TMS software subsystems = 1.X.Y. 

• Level 3—TMS software subsystem components = 1.X.Y.Z. 

• Level 4—Functions and data elements within a component = 1.X.Y.Z-A. 

Once needs have been converted to high-level business requirements (level 0 requirements), 

those requirements are decomposed to system-level requirements (level 1 requirements). 
59 

Agencies should consider how these organizing requirements are accomplished and documented 

so that developers will optimally understand the requirement structure.

For example, the first step in the requirements development process in the FDOT project was to 

translate the needs and develop system-level business requirements. The next step was to

decompose the requirements to software system-level requirements, which were numbered based 

on the level within the system. The requirements covered several types, including functional, 

performance, interface, data, and hardware requirements. These requirements also covered 

nonfunctional and enabling requirements and constraints (FDOT 2022). For the requirements in 

table 12, the requirement identifier provides the level within the system for the requirement.

Table 12. Example system-level requirements for an ICM system.

Requirement

No.

Requirement 

Description Type Need Verification Critical System

1.9 The ICM system will

store pre-agreed 

incident response 

plans.

D 9 Demonstrate H DSS

1.16 The ICM system will

evaluate the impact of 

enacted response plans 

on the transportation 

network.

F 16 Demonstrate H DSS

H = high.

The software system-level requirements are further decomposed to subsystem-level 

requirements, as shown in table 13. The system column of the table indicates which subsystem 

the requirement refers to—in this case, the DST—and the method for testing is shown in the 

verification column to indicate the method to verify that the requirement is met during the testing 

phase.
60 

Table 13. Example subsystem requirements.

Requirement

No. Requirement Text Type

Parent 

Requirement System Verification

1.9.1 The DST will store 

pre-agreed incident 

response plans as defined 

in the data dictionary.

F 1.9 DST Demonstrate

1.9.2 The DST will provide the 

ICM manager the 

capability to add 

pre-agreed incident 

response plans for a 

specified incident.

F 1.9 DST Demonstrate

1.9.3 The DST will provide the 

ICM manager the 

capability to query 

pre-agreed incident 

response plans.

F 1.9 DST Demonstrate

1.9.4 The DST will provide the 

ICM manager the 

capability to edit 

pre-agreed incident 

response plans for a 

specified incident.

F 1.9 DST Demonstrate

1.9.5 The DST will provide the 

ICM manager the 

capability to delete 

pre-agreed incident 

response plans for 

specified events.

F 1.9 DST Demonstrate
61 

In table 14, the expert rules engine (ERE) shows how DST requirement 1.9.1 (table 13) is further 

decomposed into requirements for the ERE component. 

Table 14. Example ERE requirements.

Requirement

No. Requirement Text Type

Parent 

Requirement System Verification

1.9.1.1 The ERE will store 

pre-agreed response 

plans in a 

network-accessible 

location.

F 1.9.1 ERE Demonstrate

1.9.1.2 The ERE will provide 

the prediction engine 

with pre-agreed 

response plans.

F 1.9.1 ERE Demonstrate

1.9.1.3 The ERE will provide 

the evaluation engine 

with pre-agreed 

response plans.

F 1.9.1 ERE Demonstrate

This process shows the importance of iteration—moving from needs to increasingly detailed 

requirements and repeatedly consulting with stakeholders and the technical team at every stage.

Determining How to Verify and Validate a Requirement

Each requirement can indicate how the agency expects the requirement to be verified and 

validated. Software verification and validation performed after the DST has been completed will 

help an agency determine whether the software requirements have been implemented correctly 

and if the requirements meet the needs as intended.

The following types of verification and validation are typically seen in requirements documents 

for TMSs: 

• Analyze: Use established technical or mathematical models or simulations, algorithms, 

and other scientific principles and procedures to provide evidence the item meets its 

stated requirements.

• Inspect: Use one or more of the five senses to observe and simple physical manipulation 

and mechanical and electrical gauging and measurement to verify the item conforms to 

its specified requirements.

• Demonstrate: Operate an item to provide evidence it accomplishes functions under 

specific scenarios.

• Test: Apply scientific principles and procedures to determine the properties or functional 

capabilities of items.
62 

Priority or Importance of Requirements

Agencies can identify the priority or importance of each requirement through the 

consensus-building process. A scale, such as 1–10 or a simpler scheme, can identify the priority 

of each requirement.

In the majority of TMS and DST projects reviewed, a simpler scheme is used in the requirements 

document, typically as follows: 

• H = high. 

• M = medium. 

• L = low. 

Finalizing Requirements and Beginning the Design Phase

There are many ways to develop a requirements document for the design and implementation of 

a DST; the examples in the previous sections are one approach. Well-written, well-defined, and 

properly organized requirements should consider the specific needs that were identified during 

the planning phase. A DST requirements document has two primary audiences—the agency and 

the technical implementers of the DST—and details an agreement between them. 

TRACING REQUIREMENTS

Tracing requirements throughout the system lifecycle provides visibility into the activities that 

have been completed for each requirement. A requirements traceability matrix (RTM) is a tool 

that agencies can use to trace requirements through each project phase. Project teams may use an 

RTM to track requirements against the deliverables of each project phase. Many tools on the 

market support performing requirements tracing during each project phase. Requirements may be 

traced during the design phase to ensure that all requirements are accounted for and allocated to 

each component of the overall TMS and DST design. 

For the verification and validation phase, requirements traceability is used to show that each test

performed by the project team is allocated to the various test procedures for verification and 

validation of the DST and TMS. As stated by the Project Management Institute: 

Testing plans can be developed considering how to prove the solution features and 

functions, taking into consideration the way that the customer can perceive the test, and 

the way the test will be documented. The RTM will be of help in the testing plan 

development. The main objective of the test is to show the customer how the solution 

resolves each of all the requirements on the left RTM column. Information on the design 

and building RTM columns will help identify what features and functions can be tested, 

and you can use this information to define specific testing data and procedures 

(Marone 2000).

Table 15 provides an example of an RTM that shows user need information, requirements, 

documentation references, verification testing, and comments and approval. The contents of an 

RTM will assist agencies and developers with monitoring and managing the various needs and 

requirements for a DST.
63 

Table 15. Example RTM.

User 

Need 

ID

User Need 

Summary

Detailed 

Req. ID

Detailed 

Req. 

Summary Doc. Sec.

DR Source 

Doc.

Ver. 

Test

Case 

ID

Compliance: 

Yes,

No,

Partial,

or N/A

Notes,

Comments, 

Date

Reviewer

Initial

UN009 Continuous 

electrical power 

and 

communications

DR001 Install power 

service 

assembly

639-3 FDOT 

standard 

specs

TC015 Yes APL 

products 

used

HAS

UN019 Performance 

measures and 

system 

validation

DR002 Send traffic 

MOEs to 

RTMC 

master server 

and save for 

MOE report

Testing RFP TC007 Partial APL 

products 

used

HAS

APL = approved product list; doc = document; DR = detailed requirement; ID = identifier; MOE = measure of effectiveness; N/A = not applicable; RTMC = 

regional TMC; RFP = request for proposal; req. = requirement; sec = section; specs = specifications; ver. = verification.
64 
65 

CHAPTER 5. ASSESSING CURRENT AND FUTURE DECISION-SUPPORT TOOLS

Chapters 2 and 3 provided background information on DSTs and how they fit into an agency’s 

TMS, and chapter 4 discussed identifying the needs for DSTs for a TMS. Chapter 5 focuses on 

assessing an agency’s capabilities and existing DSTs (e.g., processes, procedures, business rules, 

noncomputer-based tools, datasets, and current DSTs). This assessment may support identifying 

potential DSTs to improve how agencies manage and operate their systems or capabilities of 

their TMSs. Identifying potential DSTs to consider using provides the basis for a new DST to be 

considered. Agencies decide how and when to reuse existing DSTs, what modifications may be 

needed, if a new DST is needed, whether a new DST should be developed or procured, and when 

and how to retire existing DSTs. 

The objectives of this chapter are to understand the following: 

• How to use existing DSTs during DST design and development. 

• How to accommodate the need to adapt business processes once a DST is deployed. 

• How to determine when existing DSTs may no longer meet an agency’s needs. 

After reading this chapter, the reader should better understand the processes to assess the current 

decisionmaking tools and determine when a DST may be needed. Additionally, the reader should 

have a better understanding of how to assess their current and future DST needs and identify if 

their current or planned DSTs are feasible and meet those needs.

KEY ISSUES TO CONSIDER

When evaluating if existing DSTs can be reused or modified, an agency should review the 

following key issues to determine if current or future DSTs are necessary: 

• What existing operational tools and processes can a new DST replicate? 

• What existing business processes can a new DST accommodate? 

• When should existing business processes be modified for use in a new DST?

• How can the knowledge necessary to support the DST be captured and expressed? 

• How is the current DST being maintained? 

• What sources of knowledge contribute to current decisionmaking? 

• What new sources of knowledge can potentially contribute to decisionmaking using the 

DST?

• What, if any, existing tools support manual decisionmaking and are structurally similar to 

the planned approach for the DST? 
66 

STEPS TO IDENTIFY EXISTING DECISION-SUPPORT RESOURCES

Agencies must understand the purpose of assessing the current resources, processes, procedures, 

and tools they use in making decisions within their TMS to define the future capabilities and 

tools they will need from a new DST. This assessment includes current and future resource needs

for the design, development, deployment, and ongoing operations and maintenance of the DST 

and TMS, as shown in figure 18. 

Source: FHWA.

Figure 18. Diagram. Steps to identify existing DST resources.

Step 1—Identify Resources

The first step is to identify organizational resources to assist in evaluating existing DST 

development and future DST design, development, deployment, and maintenance. Adopting 

DSTs as part of a TMS program may require the specific skills and capabilities of in-house or 

contracted resources. Agencies will need to determine what departments and staff will be 

involved in planning and executing DST initiatives. 

Step 2—Identify Existing DST-Related Items

The second step is to identify processes, procedures, and tools used in operating a TMS. 

Agencies should perform an analysis to determine which of these items can be reused and which 

may need to be converted to an online DST that will meet the identified needs and requirements. 

Step 3—Identify DST Conversion Candidates 

The third step is to identify the processes, procedures, and tools that must be implemented with 

an online DST. If some reusable components need to be customized, the agency can evaluate and 

document as additional criteria what products and components have customization possibilities 

and the complexity that would be involved with any possible customizations. 
67 

Step 4—Identify Integration Strategies

The fourth step is to identify a strategy for integrating a new DST into the TMS. It is important 

to understand the capabilities and interfaces available from the current TMS to develop a strategy 

for integrating the DST with the TMS. Various strategies exist for integrating a DST with a 

TMS, as discussed in chapter 6. These strategies include creating a stand-alone DST and 

developing or procuring a new TMS with a fully integrated DST. 

ORGANIZATIONAL RESOURCES

To maximize the investment in a DST, agencies should rely on operational and technical experts, 

who may also support the DST’s development lifecycle from planning to operations. 

Project Champions 

A project champion’s role is to advocate for and support the DST project to help ensure its

success. The project champion will educate stakeholders on the needs and benefits of the DST.

The project champion will be the liaison with the project sponsor, project team, and senior 

management to ensure the appropriate resources are provided to support the project and to help 

solve issues and mitigate concerns that arise. 

Qualities of a project champion may include the following: 

• Respected by the agency and its leadership. 

• Adept at understanding and navigating institutional and operational politics. 

• Able to adapt conversations, have difficult conversations with ease, and avoid and resolve 

conflict. 

• Functions with strong organizational skills and able to select the right personnel and keep 

them motivated and on track. 

• Proficient at empathy and an understanding of how others will interpret words and 

behavior. 

• Possesses extensive experience and understanding to mitigate issues.

The project champion may own the following key responsibilities to ensure the project happens 

and is successful:

• Defines the strategic objectives for the project and works to make sure everyone in the 

organization is aligned. 

• Oversees the definitions of project needs, features, and requirements. 

• Ensures the design and implementation fulfill agency needs and requirements. 
68 

• Helps select the subject matter and define agency practices. 

• Identifies and eliminates risks and obstacles to ensure project viability. 

• Works with management to make resources available for the project and for 

postimplementation operations and maintenance. 

Subject Matter Experts

DSTs are complex tools that will support key operational elements of a TMS. It is important to 

identify subject matter experts (SMEs) who have specific expertise in the operational procedures 

and processes the DSTs will support. SMEs will exemplify the best traits for the operational 

activities and strategies employed by the agency, including practices for detecting and managing 

congestion; practices for detecting, assessing, and responding to events; familiarity with all data 

sources and systems integrated into the TMS; and understanding the capabilities and 

shortcomings of the TMS.

Qualities of an SME may include the following:

• Someone who is a recognized domain expert and consistently performs at the highest 

level among their peers.

• Someone who is an effective communicator and can easily explain agency operational 

procedures and policies and describe operations practices. 

• Someone who is a willing and excited participant in the project. 

• Someone who is able to devote the time and effort to make the project successful. 

Readiness for DSTs in TMS Operations

In addition to identifying and prioritizing organizational resources, agencies should consider the 

following activities in advance of DST implementation: 

• Operational concept: Deploying DSTs may cause changes to the agency’s traffic 

management operational procedures and workflows, including how the TMS functions 

and the roles and responsibilities of personnel. Developing an operational concept is 

useful for identifying changes in processes and workflows, defining how the agency may

inform and educate personnel, and describing plans to enforce these new processes. 

• Data inventory: Accessing agency data will likely be a DST need. This data will include 

data stored in agency warehouses and data streaming from agency systems (e.g., TMSs) 

or data partners (e.g., probe data providers). A data inventory should be performed to 

enumerate the available data sources, identify the access to these data sources, and define 

any data integration issues that must be addressed as part of the project. 

• TMS integration plan: Affirming the level of effort needed to integrate the DSTs into the 

TMS is accomplished by the agency asking, prior to development: “Does the TMS have 
69 

standard interfaces and APIs, or will custom integration be necessary? Are the resources 

available to support the integration project?” 

• Benefits and benchmarks: Evaluating the success of the project and the recognized 

benefits to the agency should be accomplished by identifying performance metrics and 

benchmarks. 

EXISTING PROCESSES, PROCEDURES, AND TOOLS ALREADY AVAILABLE IN 

THE TMS

Many agencies already have existing offline and online tools that are used in their 

decisionmaking processes within the TMS. Understanding these existing processes, procedures, 

and tools can be helpful in deciding which of them can be converted to an online DST and 

integrated with the TMS. Specifically, the following should be evaluated for future usefulness: 

• Existing operational tools and processes: DSTs encompass the universe of decision

support, including online computer-based tools and offline noncomputer-based tools. 

Agencies can reuse many of these tools or use them as the basis for the development and 

procurement of a new DST. 

• Business processes and standard operating procedures: Many written materials usually 

exist within organizations that define operational processes and procedures for TMSs. 

Written materials may include standard operating procedures; manuals for incident 

management; and planned event, work zone, and incident response plans. 

PLANNING CONSIDERATIONS FOR SPECIFIC DST TYPES

Three primary types of DSTs are typically most useful for supporting traffic management: 

knowledge-driven DSTs, data-driven DSTs, and model-driven DSTs. In addition to general 

planning issues that apply equally across all types of DSTs, each specific type of DSTs has its 

own planning considerations. 

Knowledge-Driven DSTs 

Knowledge-driven DSTs apply operational practices by emulating human reasoning. Planning 

for knowledge-driven DSTs needs additional considerations related to creating and validating the 

knowledge base. 

Identifying the Source of Expertise

Agency practices and standard operating procedures will form the baseline for the expertise to be 

incorporated into knowledge-driven DSTs. When considering the source of expertise there are 

three items to explore: 

• Written materials: Agencies typically produce standard operating procedures; manuals 

for incident management; and planned event, work zone, and incident response plans that 

define operational processes and procedures for traffic management. The project team 

must have access to the most up-to-date versions of the written materials.
70 

• SMEs: Personnel who are SMEs often contribute to the composition of written materials 

and are experts in understanding how these practices and operational procedures are 

applied in real-time traffic management. SMEs may also be adept at using a TMS to 

execute these operational procedures. 

• Approval authority: Each project generally addresses and resolves the issue of who will 

make the final decision on what knowledge is to be represented in the DST when there 

are multiple SMEs and written sources. The project must agree on the person who is to 

verify and validate the DST and issue final approval that it accurately replicates agency 

operating procedures. There are roles and responsibilities to clarify for each project. The 

project sponsors and the project champion may identify and assign a final arbiter to make 

final decisions. The final arbiter can be a senior member of the team who is an 

acknowledged expert respected by the team.

Knowledge-Driven DSTs as Compulsory or Advisory

When integrating knowledge-driven DSTs into TMSs, it is important to determine how the 

outputs may be used by operations personnel. Following are two common ways it may be used: 

• Compulsory: In some instances, an agency may want personnel to use the outputs from 

the knowledge-driven DSTs without making changes. 

• Advisory: In other cases, an agency may want to use the knowledge-driven DSTs to 

provide a recommended course of action but offer personnel the flexibility to modify or 

override the outputs.

Decisions about making the DSTs compulsory or advisory may vary based on capabilities of 

individual personnel (e.g., a team may decide to make the tool compulsory for novice staff but 

advisory for experienced staff) or on the problem being solved.

Data-Driven DSTs 

Unlike knowledge-driven DSTs that are inherently constructed around agency policies, 

data-driven DSTs use advanced mathematical models to identify data patterns. Data-driven DSTs 

generate decisions and predictions, but it is difficult to explain how or why decisions are 

reached. Planning to use a data-driven DST involves a different mindset than planning for 

knowledge-driven DSTs. 

Data-driven DSTs typically use data from databases that are designed to be queried, which 

enables processing and analysis of data to develop insights that support decisionmaking. 

Statistical analysis software is one of the most common types of data-driven DSTs. More recent 

systems use ML algorithms to learn from historical data to identify patterns and make predictions 

based on current data. The effectiveness of a data-driven DST depends on the quality of the data 

gathered and the effectiveness of the analysis and interpretation by the decisionmaker.
71 

Data Inputs: Training and Testing

Understanding the problem to be solved is the first step in determining if a data-driven DST is an 

option. For instance, an agency may want to predict when current conditions on the roadway 

indicate that an incident is likely to occur. A data-driven DST can be used to compare historical 

data against current conditions and make a statistical determination that the current data show an 

incident is likely to occur at a specific location.

This example indicates the data used to develop and train the data-driven DST is a key factor for 

success. In the planning phase, an agency may review and evaluate the historical dataset for the 

problem it is building the data-driven DST to address. If the historical data show incident 

conditions, such as time of day, weather, levels of congestion, and average speed, these measures 

can be used to train a multivariable statistical algorithm used within the data-driven DST. If an 

agency’s incident data are unavailable or lack the granularity, completeness, and quality needed 

to train the data-driven DST, other sources of data, such as research institutions, third-party data 

providers, and other State agencies, may need to be considered.

Model-Driven DSTs 

Model-driven DSTs use mathematical models that express the theoretical relationships among 

data elements or key variables of interest to conduct an analysis. These tools can be used (either 

online or offline) to simulate the behavior of a transportation system (or parts of the system) 

using different values for certain parameters. Model-driven DSTs use different types of analysis 

tools (e.g., statistical software and traffic analysis software) to assess the available data, evaluate

them, and report on conditions. Simulation models, in which a transportation network is modeled 

to replicate historical conditions, are a major subset of a model-driven DST. Traffic analysis 

tools that use data captured by a TMS can be used offline or online to assess how the 

transportation network will perform based on various potential actions. Model-driven DSTs can 

be used in realtime as part of a TMS to predict the possible outcomes of actions a TMS is 

considering implementing. This use allows agencies to assess the impacts on key metrics like 

travel time, environmental impacts, and person and vehicle throughput. 

Data Inputs: Training and Testing

Understanding the problem to be solved is the first step in determining if a model-driven DST is 

an option. For instance, an agency may want to model various responses to events within the 

TMS to determine the best response to a particular event.

A simulation model is a type of model-driven DST that can be developed and used by the TMS 

to evaluate the current transportation network and whether a particular response can be 

implemented. Algorithms and software applications (e.g., traffic simulation models) are 

integrated into the software subsystem to predict travel times in the future with and without 

potential actions (i.e., the results of using a specific response compared to taking no action). 

Similar to predicting traffic, this prediction function estimates travel times based on current 

conditions or a future period. These predictions are usually based on historical information from 

data collected at similar times of day and during similar weather conditions and congestion 

levels. 
72 

A typical approach used in the development of a model-driven DST is to create a mathematical 

model or use simulation tools to replicate the decisions an operator makes in various scenarios. 

This approach relies on an understanding of TMS operations, the data needed to create the 

model, and real-world scenarios to validate that the model is calibrated. A simulation model uses

a representation of the transportation network (e.g., roads, intersections), the devices that control 

that network (e.g., traffic signals, ramp meters), and the vehicles traveling on the network (e.g., 

origin/destination, volumes at various times of day). The model then attempts to replicate how 

the transportation network operates and is used to evaluate the impact of different operational 

decisions on the transportation network. 

Agencies considering a model-driven DST can leverage existing planning demand models as a 

basis for building a simulation model. Model-driven DSTs need to replicate the transportation 

network at a resolution to simulate various control strategies. Agencies can use Traffic Analysis 

Toolbox Volume XIII: Integrated Corridor Management Analysis, Modeling, and Simulation to 

better understand the requirements and data needs of a simulation model used within a 

model-driven DST (Alexiadis, Salman, and Armstrong 2012). 

DST ASSESSMENT EXAMPLE

To manage congestion on the I–4 corridor, FDOT wanted to develop a DST and TMS to support 

the future development and operation of the surface transportation system. FDOT hired a 

consultant to lead the assessment and strategy for developing the DST and its integration with 

their TMS (FDOT 2022).

The first steps in the project were for FDOT to develop the user needs and initial requirements as 

part of the ConOps for the TMS. The DST that was developed was focused on coordinating the 

actions and traffic operations of regional agencies responding to events on the I–4 corridor. It 

was expected to consider various response plans based on rules the operations experts in the 

region developed. The TMS was used to integrate and facilitate the sharing of information 

between the freeway TMS and the arterial TMS, so that traffic signal timing plans could be 

implemented for detour routes identified as part of response plans developed for incidents.

The FDOT consultant met with each stakeholder agency to assess the feasibility of integrating a 

DST into the operation of the TMS. The goals of this assessment included the following: 

• Integrate multiple separate systems from partners (including the counties of Orange, 

Seminole, Osceola, Brevard, Volusia, Flagler, Lake, Marion, and Sumter and cities 

within these counties not under county control) to unify responses and optimize system 

performance. 

• Develop signal timing to support system needs by partnering with an active arterial 

management contractor. 

• Evaluate alternative means for effective control of traffic signal systems; determine the 

impact of alternatives (e.g., legal, political, societal, and cost).
73 

After completing this assessment, a comprehensive alternative analysis was performed for FDOT 

and its stakeholders to select a strategy for integrating the DST with the TMS. The alternative 

analysis that was conducted included inviting vendors to demonstrate their products for various 

components of the software subsystem of the DST and TMS. The alternative analysis process 

involved developing high-level concepts that had been planned for the DST and TMS. The 

following process ensured that alternatives were evaluated and reviewed, with the best approach 

and solution being selected: 

• The first step in the alternative analysis was to complete a high-level system concept 

(logical architecture). The project team reviewed the existing TMS architecture to ensure 

understanding and to identify necessary updates to the TMS. 

• The next step was to analyze alternatives for the products and identify key product 

components and interfaces that traced to the key requirements of stakeholders. 

• The next step was to identify software products, customizable software products, and/or 

DST components available to meet the requirements of the DST and TMS. Vendors were 

asked to demonstrate that their products could meet the requirements and needs. Based on 

the product demonstrations and research conducted during the state-of-the practice 

document and ConOps, the team identified software products available to meet the needs 

of the stakeholders. Some products that were identified needed some level of 

customization, and an analysis of the relative cost to develop a new DST was considered.

• The final step was to develop criteria for evaluating options for build/buy/reuse product 

components, subsystem solutions, and integration needs. The team developed a scoring 

matrix and selected alternatives based on their scoring. The scoring methodology for this 

alternative analysis was based on rating the primary functions of the desired system and 

scoring functions based on the alternatives. The scores were multiplied by a relative 

priority (1 = low, 2 = medium, and 3 = high) and added to give the total functional score 

for each alternative.

A score percentage was calculated by dividing the functional score by the total possible score. 

Next, based on the assumptions and similar system analysis, an approximate deployment cost 

and 10-yr operations and maintenance cost was calculated, as shown in figure 19. 

Figure 19. Equation. Total system cost over a 10-yr period.

Where: O&M = Operations and Maintenance 

As shown in figure 20, the relative benefit/cost ratio was calculated by multiplying the score 

percentage by the average benefit-cost found in similar systems (15:1).
74 

Figure 20. Equation. Relative benefits to cost ratio.

Finally, the alternatives were compared by calculating an estimated benefits score for each 

alternative, shown in figure 21. 

Figure 21. Equation. Estimated benefits.

From this alternative analysis, FDOT identified several feasible alternatives based on available

time and budget, selected several potential DSTs that were further evaluated, and eventually 

developed a request for proposal (RFP) for a vendor to develop the DST. 

ISSUES TO REVIEW FOR DST AND EXISTING RESOURCE EVALUATIONS

Agencies should assess current and future DSTs, processes and procedures used in 

decisionmaking, and strategies for integrating new DSTs with a TMS. After this assessment, 

agencies can double-check that they have collected all information needed prior to selecting a 

DST using the following questions: 

• Has the agency identified the resources needed to evaluate current DSTs? Resources may 

include the people, processes, and tools needed to perform the evaluation. 

• Has the agency reviewed existing decision processes, procedures, and tools?

• Has the agency identified the capabilities a new DST should provide? 

• Has the agency developed a strategy to integrate the DST with the TMS?
75 

CHAPTER 6. SELECTING A DST FOR A TMS

This chapter discusses the process of selecting a DST, which includes considering the agency’s 

needs and requirements, the existing processes and tools and its users, the institutional 

capabilities, and the integration of the DST into a TMS. It describes a process for evaluating 

current DSTs and comparing them against the needs and requirements identified in previous 

chapters. Additionally, it discusses an analysis of build versus buy versus reuse and some lessons 

learned. 

The objectives of this chapter are as follows: 

• To develop an understanding of how to evaluate existing DSTs before making decisions 

about the planning, procurement, or design phase of a project. 

• To develop an understanding of general strategies for using DSTs to improve the 

management and operation of a TMS. 

• To identify the issues for consideration during the selection of a DST, including 

evaluating an existing DST or creating a new DST either through development or 

procurement. 

After reading this chapter, the reader should better understand the processes for selecting a DST 

to be used with a TMS and preparing for projects to support procurement of a new DST. 

KEY ISSUES TO CONSIDER

When selecting a DST, agencies should consider the following key issues prior to deciding if the 

development or implementation of a DST is needed: 

• What are the trade-offs between build, buy, and reuse? Has the agency analyzed and 

documented those options in a build/buy/reuse trade-off study? 

• What are the options for custom development of a DST? Can the agency use existing 

contracts, or does the agency have staff who can develop a DST or configure an existing 

DST to meet the needs? 

• How does the agency value the reliability of an off-the-shelf product versus the flexibility 

of a custom product if pursuing a stand-alone DST?

• How would a current practice or trade study help the agency to better understand 

available DST products? Is this type of study needed? How closely do agency 

requirements match existing off-the-shelf products?

STEPS FOR SELECTING AND DESIGNING A DST

As with many software systems, agencies can consider options to build, buy, or reuse their 

DSTs. There may be multiple commercially available software packages or services and/or 
76 

customizable open-source or commercial products that might meet an agency’s needs and 

requirements. Agencies should evaluate these products and services and document the potential 

positives and negatives of the various DSTs. If none of the commercially available products or 

services or internal reusable DSTs are suitable, agencies should consider building a new DST. A 

build/buy/reuse analysis may include the following steps: 

• Determine costs, timeline, and overall resources required to build a custom DST. 

• Determine long-term maintenance costs of a custom DST (license, maintenance 

agreements, etc.). 

• Analyze trade-off between build, buy, and reuse options and document options in a 

build/buy/reuse trade-off study. 

• Obtain feedback from technical (e.g., IT department, developers on staff), procurement, 

and management teams regarding the analysis of build/buy/reuse options and criteria. 

• Create documentation of build/buy/reuse decision recommendation and rationale once a 

decision is made and communicate the decision. 

This analysis is described further in the following section and shown in figure 22. 

Source: FHWA.

Figure 22. Diagram. Steps to define the design of a DST.

Step 1—Verify Reuse Options

As discussed in chapter 5, agencies may want to perform an analysis to identify existing DSTs 

and software components that may be reused to meet the agency’s needs. The agency may 

already have licenses or services available that can be reused or customized. 

If some of the reusable components need customization, agencies can evaluate, as additional 

criteria, the products and/or components with customization possibilities and the complexity that 

would be involved with carrying out any customizations. 
77 

Step 2—Make Build/Buy/Reuse Decisions

Next, agencies may want to identify build/buy/reuse decisions for each physical component and 

present recommendations to the appropriate procurement, management, and technical teams. 

Based on team feedback and approval, agencies should document the recommended product 

component. The build decision can include hiring a contractor or developing the tool using 

agency resources. The integration strategies described in this chapter will constrain the options 

for procurement discussed in chapter 7. Table 16 shows where integration strategies are 

applicable based on procurement options. 

Table 16. Integration strategies and procurement options.

Strategy Reuse Build Buy Comments

Configure TMS

Y N N 

This strategy will almost always correspond 

to a reuse decision. The agency is 

configuring the existing TMS using native 

DST capabilities.

Customize TMS

N Y Y 

This strategy is most often associated with a 

build decision. The agency is getting local 

customizations for the TMS. It is important 

that the resources performing the 

customization have an excellent grasp of the 

TMS. This model may also include a buy 

model because a new module or package 

may have to be purchased for the TMS.

UI integration with 

stand-alone DST

N Y Y 

This strategy may be both build and buy. 

The stand-alone DST may be an existing 

product that is purchased or may be custom 

built. In either case, the integration work 

with the TMS may be major and may need 

buying services.

Data integration with 

stand-alone DST Y Y Y 

A stand-alone DST may be bought or built. 

The integration work may not be as 

significant and can conceivably be managed 

by local resources.

Operational integration N Y Y There is no technical integration, and the 

stand-alone DST may be bought or built.

Y = applicable; N = not applicable.

Step 3—Communicate Build/Buy/Reuse Recommendation

In this step, the agency captures and communicates the recommendation to build, buy, or reuse 

the DST to the procurement, management, and technical teams. The agency may develop a 

make-buy document to capture the strategy for meeting the needs and requirements previously 

developed either by creating a new DST or procuring a DST. 
78 

Step 4—High-Level Design of a New DST

In this step, the agency designs a new DST using the offline tools, processes, and procedures 

identified in the review process. The agency develops the high-level design and specification of 

the new DST. 

Step 5—Detailed Design for the Integration of the DST With a TMS

In this stage of designing a DST, the agency refines and finalizes the design document, thus 

giving software programmers and vendors the information they need to begin writing code or 

configuring their DST product. 

IDENTIFY EXISTING DECISION-SUPPORT TOOLS

Determining what DST or DST components to acquire is often referred to as a make-or-buy 

analysis. This analysis is based on the needs of the project and begins early in the project during 

the first iteration of the design. It continues during the design process and is completed with the 

decision to build, buy, or reuse a DST. 

Verify Reuse Options

Agencies should perform an analysis to identify existing DSTs that may be reused or that may be 

customized to suit the current stakeholder needs. If some of the reusable components need 

customization, the agency can evaluate as additional criteria the products and/or components 

with customization possibilities.

Build Option

If multiple DSTs, customizable DST products, and/or components are available, agencies should 

evaluate the commercially available DSTs and the vendor and document potential positives and 

negatives of the various DSTs. If none of the commercially available DSTs or internal reusable 

products and/or components with customization possibilities meet the agency’s needs and 

requirements, the agency can consider the build option. The build option includes several steps, 

as follows: 

• Determine costs, timeline, and overall resources required to build a custom DST. 

• Analyze trade-off between build, buy, and reuse options and document options in a 

build/buy/reuse trade-off study. 

• Obtain stakeholder feedback on the analysis of build/buy/reuse options and criteria. 

• Create documentation of build/buy/reuse decision recommendation and rationale once a 

decision is made and communicate the decision to the stakeholders. 

As technology evolves, so does the rationale for choosing to develop or purchase a DST. While 

complex development efforts may favor purchasing an off-the-shelf DST, advances in 
79 

productivity and tools may provide an opposing rationale. Off-the-shelf products may have 

incomplete or inaccurate documentation and may or may not be supported in the future. 

Once the decision is made to purchase an off-the-shelf DST, the requirements are used to 

establish a bid document for purchasing the DST. At times, off-the-shelf refers to an existing 

item that may not be readily available in the marketplace.

HIGH-LEVEL DESIGN

The design phase begins the transition from user needs and requirements to the design so that 

developers can begin the development process. At the conclusion of the design phase, a clear 

picture emerges of the architecture, data elements, interfaces, electronic messages and protocol, 

UI specifications, software changes, API specifications, and user interactions. 

The deliverables for this phase of design may include the following: 

• Architecture—Shows the logical systems and interfaces that are needed, and what 

standards will be used for the interfaces. 

• Preliminary UI—Shows some preliminary descriptions and pictures of the potential UI. 

Data Subsystem Design

As discussed in chapter 3, the data subsystem primarily consists of the data and the interfaces or 

APIs that extract data from other systems and devices to enable the data to be transformed and 

loaded into the TMS database. Agencies should identify the data subsystem early in the process

because the availability of certain data may constrain the types of analytics or process 

automation that are possible within the system. When designing a DST, agencies and developers 

may ask the following key questions:

• Does the DST need to provide data for decision support? If so, what data needs to be 

provided? 

• Do the data currently exist in the systems? If not, is there a way to get the missing data?

• Are these sources for new data elements already integrated into the TMS data subsystem, 

or will they need to be integrated with the TMS and the new data elements also added to 

the data subsystem?

• Do the new sources of data have defined APIs that can be used to integrate these new 

sources into the TMS and/or data subsystem?

• Do the current data provide the requirements needed (e.g., 10-s intervals instead of 60-s 

intervals, area of coverage, accuracy)?

• Is the quality of the available data sufficient to support decisionmaking? 

• Is the coverage area of the data sufficient to support decisionmaking? 
80 

The data subsystem can store data the DST needs to operate and facilitate data exchange with 

other systems. The data subsystem also needs to provide the administrative and maintenance 

interfaces necessary to manage data access and monitor the system. The following sections 

discuss what the design of the data subsystem can address. 

Data Types

Within the transportation domain, common measurements and observations are used by many 

different agencies. Agencies often find it useful to understand the range of common data 

elements the system needs in order to scope the requirements and effort. Examples of data types 

include traffic data (e.g., volume, density, and speed) and incident data (e.g., duration and 

severity). For data to be effective in a DST, they are stored using common formats and 

interpretations. If they are not stored using common formats and interpretations, the data 

subsystem and DST may need reformatting, or data may have to be transformed as they are 

collected from various sources before they can be used by the data subsystem or DST. 

Data Formats 

Once the necessary data types are well understood, system developers consider which, if any, 

data format standards to use. Examples of data format standards include the Traffic Management 

Data Dictionary (Institute of Transportation Engineers 2020) and IEEE 1512 (IEEE 2006). 

These decisions may impact the storage approach but may be particularly important in 

establishing the data import and export requirements.

Data Validation and Cleaning 

Different data sources may have different formats, data quality, or other attributes. Platform 

designers can consider what data conditions are valid (i.e., which values may or may not be 

missing), what data ranges are acceptable, and what the system does in response to invalid data. 

Storage Approach 

When data are accumulated, they can be stored in raw form as collected, aggregated, or 

otherwise restructured. The use cases for accessing data as they age will determine the best 

long-term storage formats. Aggregating data can reduce storage space and speed up some 

operations, but the system may lose the capability for some fine-grained analysis. Designers may 

decide to store raw data for a certain period of time and then aggregate the data for longer-term 

storage. 

Archival Requirements

Once data access and storage are determined, designers can decide how long data will need to be 

retained and in what formats if multiple storage approaches are being used. 

Data Volume

Agencies should consider the size of the data elements, frequency of exchanges, and desired 

retention periods to ensure the network and communication infrastructure support regional DST 
81 

needs. Communication capacity considerations can consider short-term burst rates for data flow, 

and storage capacity is based on long-term data flow rates.

Data Management Plan

The data subsystem needs routine and preventive maintenance and management, including 

processes for server hygiene and data migration and retention. Data management plans discuss 

the plans for managing data; they typically describe how data will be collected, managed, 

integrated, and disseminated before and during the operation of a DST. This data management

includes real-time and archived data that are inputs to and outputs from systems managed by the 

TMS.

For example, the data management plan for the New York City Connected Vehicle Pilot 

Demonstration program includes the following structure (Van Duren, Rausch, and 

Benevelli 2017):

• Chapter 2 provides an overview of the New York City Connected Vehicle Pilot 

Demonstration. 

• Chapter 3 provides the data management approach, consisting of: 

o Data sharing and reuse. 

o Data privacy and intellectual property issues and risks. 

o Data privacy and security controls. 

o Quality control. 

o Data preservation and archiving. 

• Chapter 4 provides the New York City data plan, consisting of: 

o Full description of data types, sources, and destinations. 

o Data quantity and data collection constraints. 

o Detailed description of data collection, processing, and storage processes. 

o Description of how data are documented and organized, including metadata.

• The appendix contains a list of each log file emanating from aftermarket safety devices 

and roadside units, including the log file’s structure, contents, and format. 

DST Type Selection

Once the designers have completed the high-level design of the data subsystem or database and 

have identified related fundamental constraints, the next step is to make a final decision on the 

type of DST that will meet the needs and requirements of the TMS. 

Availability of certain data types will influence the design and selection of the DST. If data are 

unavailable or are not available at the level of detail needed, the DST selection can take that into 

consideration. For example, many TMS data subsystems provide roadway link data that are 

averaged over a period of time and across the lanes. If the DST needs to use individual lane data, 

changes to the TMS may also be needed. 
82 

At this stage, system designers make a final decision on the type of DST to be deployed. The 

three different types of engines were summarized in chapter 3 and are described in more detail in 

the next three sections of this chapter.

Knowledge-Driven DSTs 

Knowledge-driven DSTs provide specialized problem-solving expertise based on the processing 

of stored facts, rules, and procedures or similar forms of knowledge. They attempt to emulate 

human reasoning but with more consistent results. Expert systems are the best-known type of 

knowledge-driven DSTs and use databases of knowledge generated by previous expert users, 

along with a system’s business rules, to emulate the decisionmaking capabilities of an expert 

user of the system. Based on this knowledge base, knowledge-driven DSTs recommend actions 

to traffic operators. Knowledge-driven DSTs are different from table-based tools (e.g., decision 

tables, as described in chapter 1) in the way knowledge is extracted, processed, and presented. 

The knowledge-driven DST attempts to emulate human reasoning, while the table-based tool 

responds to all events in a predefined manner. 

Data-Driven DSTs 

Data-driven DSTs use data to aid in the decisionmaking process. They typically use data from 

databases that are designed to be queried, which enables processing and analysis of data to 

develop insights that support decisionmaking. Statistical analysis software is one of the most 

common types of data-driven DSTs. The effectiveness of a data-driven DST depends on the 

quality of the data gathered and the effectiveness of the analysis and interpretation by the 

decisionmaker. With many of the data analysis tools in use by the industry, transportation 

agencies can customize dashboards to display the data they want to see and run custom reports. 

Ongoing advances in how data can be accessed, analyzed, and visualized are allowing more and 

more agency staff without a technology background to work with analytical tools, analyze data, 

and make informed decisions. 

Model-Driven DSTs 

Model-driven DSTs use mathematical models and simulation tools that express the theoretical 

relationships among data elements or key variables of interest for an analysis being conducted. 

These tools can be used (either online or offline) to simulate the behavior of a transportation 

system (or parts of the system) using different values for certain parameters. Model-driven DSTs 

use different types of analysis tools (e.g., statistical software and traffic analysis software) to 

assess the available data, evaluate the data, and report on conditions. Traffic analysis tools that 

use data captured by a TMS can be used offline or online to assess how the transportation 

network will perform based on various potential actions. Model-driven DSTs can be used in 

realtime as a part of the TMS to predict the possible outcomes of actions a TMS is considering 

implementing, thereby allowing agencies to assess the impacts on key metrics such as travel 

time, environmental impacts, and person and vehicle throughput. 
83 

Integration Strategy 

Agencies can use several potential integration strategies when selecting a DST and designing 

how it will be integrated with a TMS. These strategies include the following:

• Configuring a TMS. 

• Customizing a TMS.

• Integrating a UI with a stand-alone DST.

• Integrating data with a stand-alone DST.

• Integrating operations.

Workflow Design 

The use cases identified in the ConOps and the scenarios within those use cases can be 

articulated into clear workflows for the system operators. These workflows clearly delineate 

between automated tasks the DST performs and the manual tasks operators perform. It may be 

useful to express workflows with flowcharts or other design visualization tools, as these visually 

oriented tools help make workflows accessible to nontechnical audiences. Workflows are

validated with operational staff and against real-life examples of the problems the DST is 

expected to address.

UI Design

To the degree possible, the DST maintains UI conventions and approaches that are familiar to the 

operators. Having a similar look and feel between the TMS and DST can simplify the rollout 

process and increase user satisfaction with the new system. It may be more challenging if the 

DST is an entirely different system from the TMS than it would be if the DST were a new 

module within an existing TMS. UI designers have access to systems that operators currently use 

so that the designers can understand user expectations and preferences.

The design process includes a phase to develop wireframes. Wireframes are layouts of user 

screens that identify major elements of the interface but do not specify the details of the 

interface’s look and feel. Wireframes are the transition point from workflows to visual design. 

Operators and other stakeholders can use wireframes to confirm that workflows are correct and 

effectively presented.

Response Design

It is important that the technical implementation of the response generation process does not 

inadvertently diverge from the operational goals set forth in the ConOps. This divergence can 

occur when an aspect of a response may be lost in translation when going from ConOps to 

technical implementation. 

Designing the encoding of response rules and algorithms is an iterative process involving both 

technical and operational staff. In the case of a rules engine, this ongoing fine-tuning will mean 

having technical staff convert response rules described in the ConOps into formal business rules 

usable by the system. Technical and operational staff can work together to confirm the formal 
84 

business rule definitions match the intent of the ConOps. Technical and operational staff walking 

through real-life examples together can be an effective approach to validation. 

Computing Hardware Design 

The requirements and design for computing hardware that supports a DST follow the IT 

standards and requirements of the TMS. If a legacy TMS exists, agencies can evaluate whether 

the current computing hardware will support the added DST requirements and software or if 

additional computing capabilities or a new platform will be needed. Agencies and developers can

ask the following key questions when developing requirements and design for a DST’s hardware 

platform:

• Does the DST need to be hosted within the agency’s TMS software platform or 

subsystem? (Is it a requirement?)

• Does the current hosting environment have the available resources (e.g., processing, 

memory, and hard disk space) needed to support DST requirements?

• Can additional capabilities or resources be appended to the existing hardware platform?

• Does the current hardware platform need to be replaced?

• Can changes be made to the hardware platform, given the software being used for the 

TMS?

The Dallas ICM DST is a multiagency platform that could not be hosted on the existing 

computing hardware of the agencies. The existing TMSs of Dallas Area Rapid Transit and Texas 

Department of Transportation (TxDOT) are fully using their computing hardware; therefore, new 

computing hardware specifically for the ICM system and associated DST was designed and 

deployed (FHWA 2015). FDOT District 5 TMS uses a large set of computing hardware for its

TMS, and it had designed future expansion into its original computing hardware. After 

evaluating the data, processing, storage, and memory requirements of the new DST, FDOT and 

the software development vendor determined the existing TMS hardware platform or subsystem 

could support the additional software needed for the DST . 

DETAILED DESIGN

In this stage of designing a DST, the design document is refined and finalized so that software 

programmers have the information they need to begin writing code.1 A common challenge in 

DST development is that, when a rule is formalized into something that can be incorporated into 

an algorithm or software program, the original intent of the rule can be lost. To address this 

challenge, operations staff can work vigilantly with technical staff to ensure the formal definition 

returns the correct results.

1

This design and development approach assumes a waterfall software development method. As discussed in 

chapter 7, other software development methods (i.e., agile) may change the level of detail in this stage of the design. 
85 

The deliverables for this phase of design usually include: 

• Data interface specifications—Describe each data interface, the relevant standards that 

will be used how the data will be exchanged (i.e., format and frequency), and the content 

of the data. An interface control document is usually created by the software developer to 

document the data interface. It is used to create the API to facilitate the exchange of data 

between each system and subsystem within the TMS.

• Detailed UI—Provides visual representations and a more detailed description of the UI.

• Detailed rules/algorithm/analysis specifications—Describe the rules the DST will use, 

ranges of expected values for each rule, and formulas or algorithms the DST will use to 

calculate various measures.

• Detailed functional descriptions for each component—Describe each component of the 

DST, how each component will interface with other components, the data each 

component needs from other systems, and the functionality each component provides 

referenced to the requirements developed during the planning phase. 

• Design review at 90 percent completion—Involves a meeting between the design team 

and project stakeholders to review the almost-completed system design; this meeting 

usually occurs when 90 percent of the design is complete.

Using the concepts and preliminary design developed in the high-level design phase, the detailed 

design phase makes the technical decision on what will be developed, provides more detail, and 

documents the complete specification for each DST component. Questions provided in the 

high-level design sections for the various components can be revisited by the designer and 

further detail developed. The type of DST being developed is finalized at this point. While the 

high-level design provides a logical and physical architecture at a conceptual level, the detailed 

design includes the following:

• Functional logic of each DST component: The logic, algorithms, and processes for each 

component are finalized and documented so that a software developer can configure or 

develop the software components of the DST. 

• Database tables finalized: The data subsystem design is finalized and documented to 

include the type and size of all data elements and a data catalog that identifies all data 

within the data subsystem.

• Complete detail of the interfaces: The APIs and associated interface control documents 

are developed and finalized to allow developers to integrate the various TMS software 

subsystems with the DST. 

The detailed design phase provides a complete design that software developers and system 

integrators can use to develop the DST and integrate it into the TMS. 
86 

EXAMPLE OF SELECTING A DST

As part of the ICM program, the U.S. Department of Transportation (USDOT) has released 

several versions of the Implementation Guide and Lessons Learned (Christie et al. 2015). One 

example seen in this text is the Dallas Pioneer Site, which included in its system documentation 

an ICM system context diagram that helped show the ICM system interfaces with existing 

transportation-related systems. This display allowed system developers to use the context 

diagram to help explain the system environment and its constraints to project stakeholders.

As part of the detailed design activities and documentation, the Dallas team included a process 

for making the build, buy, and reuse decisions. 

This process involved investigating and documenting, through a formal process, the options and 

related rationale for developing or acquiring the necessary capabilities, as follows 

(Christie et al. 2015): 

• Make build/buy/reuse analysis. 

• Verify reuse options. 

• Develop and analyze design alternatives. 

• Make build/buy/reuse decisions. 

• Communicate build/buy/reuse recommendation. 

• Create bill of materials.

Having a process helps to ensure that the best decisions are made and stakeholders have the 

confidence to move forward with the project. 

ISSUES TO REVIEW: THE OPTIONS FOR SELECTING A DST

After assessing potential DSTs, verifying build/buy/reuse options, and developing a high-level 

DST design, readers can double check they have collected all information needed to select a DST 

and begin procuring or implementing their DST and TMS. This review for the assessment may 

include the following questions: 

• Did the agency analyze the trade-off options between build, buy, and reuse and document 

options in a build/buy/reuse trade-off study? 

• Did the agency make a build/buy/reuse decision? 

• Has the agency identified existing contracts that can be used for DST development? 

• Do agency requirements closely match existing off-the-shelf products?

• Has the agency decided on the DST that will be procured?

• Has the agency decided on the integration strategy for the DST with the TMS?
87 

CHAPTER 7. PROCURING AND IMPLEMENTING DECISION-SUPPORT TOOLS

The purpose of this chapter is to introduce the considerations when agencies procure or develop 

a DST. It builds off the analysis and design considerations introduced in the previous chapter, the 

build/buy/reuse analysis, and high-level design. 

The objectives of this chapter are to understand the following: 

• Steps for procuring a DST. 

• Options for procuring a DST and how they may influence product selection. 

• Potential issues with procuring a DST. 

• Steps for implementing a procured DST. 

After reading this chapter, the reader should better understand which procurement options may 

be applicable or suited to their goals for the types of DSTs they are contemplating. Information is 

also provided about issues to consider when reviewing the agency’s policies, procedures, and 

options for procuring different types of DSTs. 

KEY ISSUES TO CONSIDER

An agency may have several procurement options when planning the procurement of a DST into 

a TMS. These options may be based on policies at the agency or governmental entity (city, 

county, State). Agencies should consider the following key questions when planning to procure a 

DST for a TMS:

• What institutional policies or preferences may influence the choice of procurement 

models?

• What specific technology policies should the agency follow (e.g., cloud-hosted solution 

or hosted on-premises)?

• What intellectual property requirements are there for the DST (e.g., own, license, etc.)? 

• What funding mechanisms for recurring costs are associated with hosting and ongoing 

operations and maintenance, if any?

• What preferred procurement method (e.g., low bid, best value, qualifications-based 

negotiation) do the needs and requirements previously identified indicate, if any?

STEPS TO PROCURING AND IMPLEMENTING A DST

Once a DST has been designed to a level that it can be developed or procured, a procurement 

process may be needed. A standard procurement process for software is commonly used when 

procuring a DST or procuring the development of a DST. 

The procurement process includes understanding the options to procure the DST, developing 

procurement documents, and evaluating and selecting a vendor for the DST. This process may 
88 

use multiple procurements for different components of the TMS, which might include the 

computing hardware subsystem, software subsystem, and data subsystem needed to procure a 

full DST solution. Figure 23 provides a high-level process for procuring a DST.

Source: FHWA.

Figure 23. Diagram. Steps to procure a DST. 

Step 1—Understand Available Procurement Options

Based on the funding sources for a DST project, an agency may need to follow various rules and 

regulations. Many DSTs are software procurements, which may need oversight by a State’s IT 

department. 

Step 2—Select Appropriate Procurement and Development Method

Once an agency understands the rules and regulations dictated by the agency’s policies, the 

agency will decide the actual method for procuring a DST. Contacting other agencies that have 

procured similar systems may help the agency understand lessons learned and potential issues in 

procuring the DST.

Step 3—Develop Procurement Documents

Procurement documents for the development of a DST or DST service will provide the 

contracting mechanism for vendors to bid on the development of a DST or provide a service that 

meets the requirements identified in the previous chapters.

Step 4—Evaluate Proposals and Select a Vendor or Developer

After the agency receives proposals from vendors/developers, the agency can evaluate and select 

the vendor/developer based on the agency’s rules and criteria. Typically, these procurements use 

low-bid, best value, or a qualifications-based selection leading to negotiations and DST 

procurement. 
89 

PROCUREMENT OPTIONS

While the solution architecture describes the functional integration of TMS and DST 

components, the system architecture describes the technical hosting and integration plans and is 

heavily influenced by the nonfunctional requirements. Once the decision on build/buy/reuse has 

been made and agreed to by stakeholders, the physical system architecture can be completed.

The system architecture will depend on the agency’s IT requirements and the technical 

architecture for the DST solution. In the past, with agencies favoring systems hosted 

on-premises, the legacy TMS, along with a DST, were both in the same location and perhaps 

even used the same computing platform. 

As agencies have moved to open, modular TMS architectures and acceptance of remote hosting 

options has grown, more options have come into play for designing system architectures. What 

matters in the end is whether both the TMS and the DST(s) are built around standards-based 

APIs and whether there is a strong communication link between where the TMS and DST(s) are 

hosted. This issue is directly relevant to procurement because some modern products may only 

be offered as cloud-based services. The agency will need to understand the options for 

cloud-based services and how they conform with agency policies and conventions. 

Hardware Subsystem Options

The requirements and design for a hardware subsystem to support a DST can follow IT standards 

and requirements of the TMS. If a legacy TMS exists, agencies can evaluate whether the current 

hardware subsystem will support the added DST requirements and software subsystem or if 

additional computing capabilities or a new hardware subsystem will be needed. When 

developing the requirements and design for the hardware subsystem of a DST, agencies and 

developers should ask the following key questions: 

• Do DSTs require on-premise installation within the current hardware subsystem within 

the agency’s TMS?

• Does the current hardware subsystem have the available resources (e.g., processing, 

memory, and hard disk space) to support DST requirements? 

• Can additional capabilities or resources be appended to the existing hardware subsystem? 

• Is the hardware subsystem scalable to allow for additional processing and storage for 

future growth? 

• Does the current hardware subsystem need to be replaced?

• Can changes be made to the hardware subsystem, given the software subsystem being 

used for the TMS?
90 

As shown in figure 24, there are several options for the hardware subsystem of the

next-generation TMS. 

Source: FHWA.

OnPrem = on premises.

Figure 24. Diagram. Hardware models for the build scenario versus the procure scenario.

DST solutions for the hardware subsystem of the next-generation TMSs are available as follows 

(California Department of Transportation and FHWA 2009): 

• On-premise deployment offers users the ability to install, manage, and maintain every 

aspect of a system deployment. Typical on-premise deployments involve up-front costs 

(hardware, software licensing, etc.) but allow for greater control of the system.

• Infrastructure-as-a-service (IaaS) deployment provides scalability and minimizes 

responsibility for the DOT. Users are responsible for managing applications, data, 

runtime, middleware, and operating system. Instead of having to purchase hardware 

outright, users can purchase IaaS based on consumption (e.g., database reads/writes or 

computing cycles), similar to electricity or other utility billing.

• Platform-as-a-service (PaaS) deployment allows users to develop, test, and deploy 

applications quickly and efficiently. With PaaS, users are only responsible for data and 

application tiers. Similar to IaaS, users can purchase PaaS on a subscription basis and pay 

only for what they use. 

• Software-as-a-service (SaaS) deployment uses the web to deliver applications. Most SaaS 

applications can be accessed directly from a web browser on the client side. This model is 

entirely maintained by the vendor. Like the other service models, users typically purchase 

a subscription to access the application.
91 

On-premise and IaaS are the most common approaches to hosting agency-developed and

vendor-provided solutions. PaaS may be a good option for agencies that build their own solution 

and want to leverage the tools that many cloud providers offer. SaaS applies exclusively to 

leasing services from a vendor on a per-seat or per-agency basis.

PREPROCUREMENT CHECKLIST

Once a DST has been designed to a level that it can be developed or procured, a procurement 

process may be needed. When procuring a DST or procuring the development of a DST, 

available procurement processes should be reviewed. This review may include the following 

questions: 

• Has the agency considered how the preferred integration strategy influences procurement 

options? 

• Has the agency considered how institutional preferences influence procurement options? 

• Has the agency examined existing vehicles that can be used to procure integration 

services?

• Has the agency completed and documented the build/buy/reuse analysis? 

• Has the agency identified all agency policies that may impact options for procuring the 

DST (i.e., cloud-based products)? 

• Has the agency examined the trade-offs for different options for hosting the DST?

POTENTIAL ISSUES

Depending on the scope of a DST procurement, the agency may face the following potential 

issues:

• Interfaces to external systems and a mechanism to modify or develop that interface may 

be needed. Existing TMS software may or may not have a well-defined API for the 

integration of tools and other software. A contract with the TMS software developer or an 

external system may be needed to integrate those systems with the DST.

• Multivendor developments can lead to issues when integrating technologies into an 

overall system. An overall systems integrator can be used to manage all the various 

systems and ensure that TMS and DST integration is successful.

• Some DST technologies are new to agencies and may need more effort than planned to 

ensure the DST meets the needs and requirements. A systems manager and independent 

verification and validation process should be considered, especially if the agency does 

not have the technical expertise to oversee the vendor.
92 

EXAMPLE OF PROCURING A DST

The FDOT District 5 R–ICMS project had several options to procure its R-ICMS software. One 

of the options included a DST to select and coordinate multiagency, multimodal response plans 

to incidents on the I–4 corridor. FDOT allowed several mechanisms for procuring software and 

services, including a professional services RFP, an invitation to bid (ITB), and an invitation to 

negotiate (ITN) (FDOT 2022). 

The RFP process is typically used for contracting professional engineering services from 

prequalified companies, the ITN process is typically used for buying commercial products, and 

the ITB process is typically used for buying systems and technologies. For this procurement, 

FDOT chose the ITB process using a two-stage procurement. The first stage was a qualification 

phase, where potential teams provided their qualifications in the development of the R–ICMS

software. From the first stage, FDOT selected two companies to provide a technical proposal and 

price proposal for development of the R–ICMS software. The respondents provided two 

approaches: a works for hire and the license of a commercial product. The works-for-hire 

approach meant that FDOT would own the software and the vendor would not have rights to 

reuse it without permission from FDOT. The license of a commercial product approach meant 

that FDOT would have a license to use the software but would not be able to reuse or make 

modifications to the software in the future without contracting with the vendor.

Because FDOT wanted to potentially reuse the software in other parts of the State, and even 

license the software to other agencies in the United States, FDOT selected the works-for-hire 

approach. Additionally, since the project was a software procurement, FDOT had to follow the 

State’s Office of Technology and Information Services process for Enterprise Application 

Services for the design, development, and implementation of the DST. 

FDOT also decided that its on-premise hardware subsystem located at its TMC would host all 

software developed for the DST, which required staff to deploy and configure the hardware 

where the vendor would install the software. 

Understanding the process and procedures that needed to be followed for procuring the DST 

allowed FDOT staff to contract, design, develop, and deploy the DST to meet the needs and 

requirements it had identified before procuring it.

ADDITIONAL RESOURCES

As stated in Federal-Aid ITS Procurement Regulations and Contracting Options: 

State and local agencies planning to procure intelligent transportation systems (ITS) 

projects with Federal highway funds face unique challenges. They choose appropriate 

contracting techniques that optimize project quality and cost while meeting applicable 

Federal, State, and local procurement regulations. These challenges are especially 

paramount when procuring ITS projects that involve advanced technologies and require 

specialized skills and knowledge. Even deployments of simple ITS system expansions 

have become complex undertakings to ensure consistency with the National ITS 

Architecture and evolving standards. Typically, the requirements of these ITS projects 
93 

cannot easily be specified at the outset of the project—resulting in the difficulty of 

establishing realistic low bids and ensuring end-product quality (Gord 1997). 

The Federal-aid procurement regulations, as set forth in 23 CFR §172, 23 CFR §635, 

23 CFR §655, and 49 CFR §18, define the requirements that State and local agencies adhere to 

when procuring projects with Federal-aid highway funds. These procurement regulations identify 

possible contracting options available for designing and constructing projects, including such 

contracts as engineering and design-related services, construction, and nonengineering or 

nonarchitecture. The regulations also require competitive contract award procedures for any 

project financed by Federal highway funds (23 U.S. Code (USC) § 101(a)). Use of a qualified 

on-call consultant may be acceptable if the list of on-call consultants resulted from a competitive, 

qualifications-based process (National Archives eCFR 2022; National Archives eCFR 2023; 

GovRegs 2023). 

The process of developing a DST includes considering the development methodology an agency 

and vendor uses in the development and implementation of the DST. Traditionally, Federally

funded projects have used a systems engineering approach that employs a waterfall 

methodology. More recently, system development projects have used agile development. 

The following resources provide background on these methodologies: 

• FHWA’s (n.d.) “Welcome to the Systems Engineering Guidebook for ITS Web Site” 

• Staples et al.’s (2017) Applying Scrum Methods to ITS Projects

• Scrum Alliance’s® (n.d.) “What Is Scrum?” 

• Marbach’s (2016) “Introduction to Agile Practices” 

• Agile Alliance’s (n.d.) “Agile 101” 

• DeWeese’s (1994) MIL-STD-498 Software Development and Documentation
94 

CHECKLIST: ISSUES TO REVIEW WHEN PROCURING A DST 

After planning the procurement of a DST, deciding which procurement options may be 

applicable and/or suited to the agency’s goals, and contemplating the types of DSTs, an agency 

should review the following issues prior to initiating procurement: 

• Have all options for DST procurement been investigated?

• Have specific technology policies (e.g.., cloud-hosted solutions) been documented? 

• Do intellectual property requirements (i.e., own, license, SaaS, etc.) determine the type of 

procurement? 

• Does the agency have hardware subsystem requirements (on-premises, cloud) the vendor 

must follow? 

• Does the agency have funding mechanisms for recurring costs associated with hosting 

and ongoing operations and maintenance?

• Has the agency selected a procurement method based on policies and requirements?
95 

CHAPTER 8. INITIATING THE USE OF DECISION-SUPPORT TOOLS

This chapter provides agencies with an overview of the steps following the development or 

procurement of a DST to prepare for operations. It discusses DST verification and validation to 

help ensure the DST meets the needs and requirements the agency previously developed. 

Additionally, it enumerates deploying the DST software onto the computing hardware platform 

and ensuring all data and interfaces are complete and integrated so that the TMS is ready for 

operations. 

Verification of a DST determines that the DST was developed correctly and meets requirements. 

Validation of a DST focuses on ensuring the correct type of DST was developed to meet the 

needs of the agency.

The objectives of this chapter are as follows: 

• To understand the implementation and initiation process for DSTs. 

• To discuss the verification and validation of DSTs. 

• To discuss activities to consider when transitioning from testing to day-to-day use of a 

DST. 

This chapter introduces the processes of implementing and initiating the use of a DST and 

describes the following stages of the systems engineering process:

• Systems verification. 

• Systems validation. 

• Operations and maintenance transition.

After reading this chapter, the reader should better understand the steps in DST verification and 

validation and the steps to transition to operations. 

KEY ISSUES TO CONSIDER

An agency should consider the following key questions when preparing to operate a DST: 

• Has the agency developed the test plans? Do all the staff members who will be involved 

understand the plans?

• Are all tests traceable to all the requirements?

• Are ongoing activities needed to train operators to use the DSTs efficiently and 

effectively? If so, what are these activities?

• Has the agency developed plans for potential issues during deployment? Does the agency 

have back-out plans if the deployment must be halted? 

• Has the agency documented the testing (unit, integration, and acceptance) results?
96 

• Has the agency completed a test readiness review?

• Has the agency performed a systems acceptance test to verify all requirements have been 

met and demonstrated?

STEPS TO PREPARE FOR OPERATING A DST

A testing process is needed to verify and validate a DST has been developed correctly and 

operates to meet the requirements and needs the agency previously identified. This process, 

shown in figure 25, is described in the following paragraphs. 

As stated in ISO/IEC [International Electrotechnical Commission] 15288:2008, the verification 

process confirms the specified design requirements are fulfilled by the system. The verification 

process provides the information necessary to affect remedial actions that correct 

nonconformances in the realized system or the processes that act on it (ISO 2008). 

Once the verification process has been completed, the agency can transition to operations. The 

purpose of the transition process is to establish a capability to provide services specified by 

stakeholder requirements in the operational environment. The transition process installs a 

verified system (DST and TMS) together with relevant enabling systems (e.g., operating system, 

support system, operator training system). The transition process is used at each level in the TMS 

structure and in each stage to complete the criteria established for exiting the stage. 

The validation process provides objective evidence that the services provided by a system when 

it is in use comply with stakeholder requirements, achieving the DST’s intended use in the 

DST’s intended operational environment. The validation process performs a comparative 

assessment and confirms that stakeholder requirements are correctly defined. Where variances 

are identified, they are recorded and help with corrective actions. The stakeholders ratify system 

validation. 

Ultimately, the transition process transfers custody of the DST and TMS and responsibility for 

system support from one organizational entity to another. This transition includes transfer of 

custody from the development team to the organizations that will be operating and supporting the 

system. After the transition process has successfully concluded, the operation and maintenance 

phase of the DST typically begins. 
97 

Source: FHWA.

Figure 25. Diagram. Steps to prepare for operation of a DST. 

Step 1—Verification of Requirements

Verification is an ongoing process that tests each subsystem as the subsystems are assembled and 

integrated to ensure subsystem performance meets design requirements. Verification is repeated 

at each level of integration until the entire system is assembled, at which point the entire 

system’s performance may be verified a final time. Each time verification testing has been 

completed, the tests, results, and corrective actions are documented. Verification is typically 

conducted using an installation of the system dedicated to development or quality assurance (i.e., 

not under real-world conditions). 

Step 2—Deployment of System 

Deployment and validation are the process of installing the system in the field, confirming that

the system functions in its intended environment (i.e., performs according to system 

requirements), and confirming the system meets the needs of the intended users. This process can 

be a challenge for any TMS. The simplest approach may be to switch operations over to the new 

system, but this switch also has the potential to disrupt operations. This situation can be

particularly challenging with DSTs because the situations necessary for DST validation 

(congestion and incidents) are the situations where the most important factor is to not disrupt 

operations. It is ideal to run the new and old systems parallel to each other for a period of time. 

This dual use of systems allows for uninterrupted operations and enables observing the behavior 

of the new system under field conditions. 

Step 3—System Validation

The validation process is invoked during the stakeholder requirements definition process. 

Validation confirms that the requirements properly reflect stakeholder needs and establishes

validation criteria (i.e., that the right system has been built). The validation process is also 

invoked during the transition to operations to handle acceptance activities.
98 

The validation process includes the following activities: 

• Plan the validation: Develop a validation strategy—a plan for validating the system and 

ensuring the system meets the operational needs of the TMS operations staff. 

• Perform the validation: 

o Develop validation procedures that demonstrate the system is fit for its purpose and 

satisfies stakeholder requirements. 

o Ensure staff readiness to conduct the validation. 

o Support in-process validation activities throughout system development. 

o Conduct validation to demonstrate conformance to stakeholder requirements. 

o Analyze detected anomalies for corrective actions, detect trends in failures to find 

threats to the system, and detect evidence of design errors. 

o Recommend corrective actions and obtain stakeholder acceptance of validation 

results. 

o Document validation results and enter data into the requirements tracking database. 

Step 4—Transition to Operations

As stated in ISO/IEC 15288:2008, the operational transition process establishes a capability to 

provide services specified by stakeholder requirements in the operational environment 

(ISO 2008). The operational transition process installs a verified system together with relevant 

enabling systems (e.g., operating system, support system, operator training system). This process 

is used at each level in the system structure and in each stage to complete the criteria established 

for exiting the stage. It includes preparing applicable storage, handling, and shipping of the 

systems.

Ultimately, the transition process transfers custody of the system and responsibility for system 

support from one organizational entity to another. This transition includes transferring custody 

from the development team to the organizations that will be operating and supporting the system. 

After the transition process has successfully concluded, the utilization stage of the system of 

interest typically begins. 

The transition process includes the following activities:

• Plan the transition: 

o Prepare a transition strategy, including operator training, logistics support, delivery 

strategy, and problem rectification/resolution strategy.

o Develop the installation procedures. 
99 

• Perform the transition: 

o Prepare the installation site and install the system according to established procedure. 

o Train the system users in its proper use and ensure they have the knowledge and skills 

necessary to perform operations and maintenance activities. This process includes a 

complete review and handoff of operator and maintenance manuals, as applicable. 

o Receive a final confirmation that the system, as operated and maintained by the 

intended users, meets their needs. This process typically ends with a formal written 

acknowledgement that the system has been properly installed and verified, all issues 

and action items have been resolved, and all agreements pertaining to development 

and delivery of a fully supportable system have been fully satisfied or adjudicated.

o Document any postimplementation problems that may lead to corrective actions or 

changes to requirements.

VERIFICATION

Some aspects of verification can be particularly challenging for DSTs. Because DST behavior 

often depends on a complex combination of inputs from multiple data sources, it can be difficult 

to recreate large, varied input streams to be useful for repeatable testing and verification.

Some approaches for verification include the following: 

• Randomized inputs: Testing tools can be created to provide random numbers that 

approximate data sources (e.g., traffic detector readings). These tests can be made 

repeatable by reusing the same random number seed. This process can be a simple way to 

produce data that can be input to the DST for testing. The drawback is that the data may 

not match realistic inputs when viewed from a system perspective. A key aspect of a 

successful DST is that it responds correctly to conditions over a large area or time 

interval, and it is difficult to get a coherent dataset over widely ranging values of time 

and space using randomized inputs. 

• Record and playback: Testing tools can be built to record live data inputs and play them 

back for testing purposes. This process can be a simple way to collect data that are 

realistic and coherent over time and space. A limitation of this approach is that it may be 

challenging to collect data reflecting extreme circumstances.

• Traffic simulation: A realistic traffic simulation can be created to derive inputs such as 

traffic volumes and speeds. This process can be used to create realistic testing scenarios, 

and simulation parameters can be varied to create extreme conditions. However, it may 

be expensive and time-consuming to build and calibrate a model if one does not already 

exist.
100 

Deliverables for this phase may include the following: 

• Test plans provide the step-by-step script an agency can follow to verify that the system 

developed meets the requirements determined during the planning and design phases.

• Test readiness reviews involve meetings between the development team and stakeholders 

to review the results of internal testing and ensure the system is ready for system 

acceptance testing by the agency.

• System acceptance testing verifies the completed system to ensure it meets all 

requirements and performs as expected, and the agency accepts the completed system and 

is ready to deploy it and begin operations.

• The agency develops documentation of each previous deliverable: 

o A test plan is created during the design phase and reviewed again prior to verification.

o A test readiness review is drafted, including all preliminary testing that has been 

completed, the test results, and any known defects. 

o A final test report is created after system acceptance testing has been completed. This 

report shows the test results, any corrective actions, and the acceptance of the DST.

Verification of Knowledge-Driven DSTs 

A knowledge-driven DST may be tested to verify the requirements and ensure that the logic 

within the DST functions as expected. The most typical knowledge-driven DST uses business 

rules within a rules engine. Testing a rules engine consists of developing random inputs for the 

key variables of the rules engine to verify the correct recommendation is provided. Using 

randomized inputs can generate a wide range of test cases easily. It is important that all tests are 

repeatable; the test inputs are stored to enable the tests to be rerun. In addition to randomized 

inputs, SMEs work with the technical team to ensure that input combinations common in the real 

world are represented in the test cases.

As an example, a typical incident response rules engine uses the current conditions of the 

network, the time of day, day of week, incident location, and incident severity to determine a 

recommended response plan. The response plan might include DMS messages, detour routes, 

and signal timing plans for an agency to implement. Testing the logic of the DST is needed to 

ensure the logic is developed correctly.

Verification of Data-Driven DSTs 

A data-driven DST may be tested to verify the requirements and ensure that the algorithms 

within the DST function as expected. The two typical data-driven DSTs are predictive analytics 

algorithms and ML algorithms. Predictive analytics algorithms may be tested to ensure the 

output is reasonable and provides expected results. ML systems may compare the actual output 

of the engine to the expected output. 
101 

Testing predictive analytics models is different from testing most other types of software. While 

agencies need to test the model’s performance, the testing also needs to demonstrate how well 

the model performs on data. An algorithm’s accuracy depends on the model itself, which is 

developed from historical data, and the data that feeds the model. The training data need to be 

relevant to the problem the algorithm is trying to solve. A good predictive analytics algorithm 

performs well on different sets of data without favoring one set over another. However, 

insufficient testing can leave unresolved bias and variance in a model, which reduces the model’s 

overall value.

Testing ML engines qualitatively is different from testing any other type of software. In most 

testing situations, agencies may seek to ensure the actual output matches the expected one. With 

ML engines, looking for exactly the right output is exactly the wrong approach. Typically, 

agencies will be unable to calculate the right output without writing the software twice.

The key to testing an ML engine is to understand both the requirements for the production results 

and the limitations of the algorithms. The requirements need to translate into objective 

measurements—ideally, the standard deviation of the mean result, assuming that the mean result 

is closely related to the actual result found in the training data. Using objective measures instead 

of qualitative testing methods allow agencies to assess the results of an ML engine from a 

statistical standpoint, rather than from a yes-no standpoint.

Agencies may not expect an exact right answer all of the time, or even most of the time. How 

agencies test and evaluate may entirely depend on the goals of the system 

(Heusser and Varhol 2017). 

Verification of Model-Driven DSTs 

Verification of a model-driven DST begins with overseeing the calibration of the model and 

ensuring a proper calibration is performed. The following list summarizes the process for 

calibrating a model: 

• Establish calibration objectives and review project objectives to ensure the calibration 

task directly supports the project objective. 

• Identify the performance measures and key locations against which the models will be 

calibrated. 

• Determine the statistical methodology to be used to compare modeled results to the field 

data. 

• Determine the strategy for model calibration and identify parameters within the dynamic 

traffic assignment (DTA) models that are the focus of adjustments. 

• Assemble the field data that has previously been collected for comparison to model 

outputs. 
102 

• Conduct model calibration runs following the strategy and conduct statistical checks. 

When statistical analysis falls within acceptable ranges, the model is considered 

calibrated. 

• Test the calibrated model or compare it with a dataset not used for calibration. If the 

model replicates the different datasets, the calibration parameters and model are 

considered validated. 

Figure 26 depicts a general process applicable to calibrating a DTA model. 

Source: FHWA.

Figure 26. Diagram. Model calibration process (Sloboden et al. 2012). 

After a model has been calibrated, the verification process may test the model using multiple

scenarios and objectives and an expected level of accuracy for each test. As discussed in 

Dynamic Traffic Assignment: A Primer, a model can be tested with alternative scenarios and 

evaluated relative to the base model. Alternative scenarios can be developed to reflect the effect 

of various possible demand and network scenarios in the future (Chiu et al. 2011). 

SYSTEM DEPLOYMENT AND VALIDATION

Deployment and validation are the process of installing the system, confirming the system

functions in its intended environment (i.e., performs according to system requirements), and 

confirming the system meets the needs of the intended users. It is helpful to run the new and old 

systems in parallel for a period of time, which is known as a soft launch. This parallel operation 

can last from a few days to a few months, depending on the technological risk of the new system. 

For instance, if a DST is added to an existing TMS and the stakeholders want to use it for a 

period of time to ensure it operates as expected, a longer soft launch of the DST may be 

warranted. 
103 

The deliverables for this phase may include the following: 

• A validation report documenting any issues or nonconformances to ensure that all 

requirements and use cases are validated.

• A change request identifying, through the verification and validation process, additional 

requirements or desired changes that need to be requested from the DST developer. 

The agency approves system acceptance once validation has been completed, and then the DST 

will be ready for operation. 

VERIFICATION AND VALIDATION OF A DST

Example of a Regional DST for ICM

FDOT’s R-ICMS includes several subsystems that assist regional agencies with multimodal, 

multiagency responses to incidents within the I–4 corridor. The R-ICMS DST consists of two 

DSTs, as follows (FDOT 2022): 

• ERE—A knowledge-driven DST that contains the logic to make determinations based on 

predefined rules. This DST includes monitoring current conditions to determine when a 

response plan needs to be implemented, modified, or deactivated. 

• Prediction engine—A model-driven DST that consists of a real-time mesoscopic model 

that calculates the predicted conditions of the transportation network and determines 

changes to signal timing plans, detour route selection, and expected conditions 30 min 

into the future with and without a response plan. 

To develop and test the prediction engine, a model calibration and validation process was

performed by the development team. The prediction model was calibrated to a level of accuracy 

to support the potential R-ICMS scenario analysis. However, recognizing that a model will never 

be perfect, the development team identified a level of error tolerance after studying the 

variability of field data in the real world and the stochasticity of the DTA model. 

The following calibration performance metrics and target acceptance values for different 

performance metrics are used by a development team: 

• Screenline volumes: Natural or artificial divisions of the study area are reflected into 

sectors and intercept all traffic traveling between these sectors of the model. The targeted 

calibration threshold of the screenlines is to have the mean modeled screenline volumes 

within 5 percent of the mean observed screenline volumes. 

• Link volumes: All locations with observed traffic counts are assessed by comparing the 

modeled counts against the observed counts at the hourly level for each link. Methods to 

examine the counts can include scatterplots, root mean square error (RMSE) percent, and 

Geoffrey E. Havers (GEH) statistics. Both the R-squared value of that regression line and 

the slope of the regression line are examined. First, the R-squared value is targeted to be 

0.90 or higher, and the slope of the regression line is targeted to be between 0.95 and 
104 

1.05. Second, the RMSE percent is calculated for different road classes (e.g., freeways, 

ramps, major arterials, and other roadways). While the RSME percent value is expected 

to be higher for the lower class roadways, the target is to have an RMSE percent value of 

less than 10 percent for all freeway counts. Finally, GEH statistics are computed for 

selected key roadways in the mesoscopic model study area. Given the importance of the 

I–4 corridor to the mesoscopic model, count locations along I–4 are tracked and reported 

by computing a GEH statistic for each link for each hour of the simulation. The target is 

to have 85 percent or more of GEH statistics with a value of seven or higher for these key 

roadway counts. 

• Corridor travel times: Travel time data are compared for the directional freeway corridors 

as well as selected arterial corridors. The arterial corridors selected for travel time 

validations are major arterials in the system or significant routes along key diversion 

routes within the defined response plans. These variation envelopes are used to assess the 

fit of the modeled travel times. The modeled travel time reflects the average modeled 

condition. The first validation target is to have 95 percent of all modeled travel times fall 

within the 2-sigma band. This target ensures that the modeled travel times are not 

producing significant outliers when compared to the range of typical weekday travel 

times. The second validation target is to have two-thirds of the modeled travel times 

within the 1-sigma band. This target helps ensure the modeled travel times are generally 

similar to the typical travel times seen on typical days.

CHECKLIST FOR PREPARING FOR OPERATIONS

After the agency procures the DST or the selected vendor has provided or developed the DST, 

the agency verifies and validates that the DST meets the requirements. Prior to accepting the 

DST to begin operations, agencies ask the following questions to demonstrate the DST is ready 

for operations: 

• Has the agency developed and understood the test plans?

• Are all tests traceable to all the requirements, and is an RTM provided? 

• Does the deployment plan include criteria for back-out plans for potential issues during 

deployment? 

• Has the agency documented testing (unit, integration, and acceptance) results?

• Has the agency performed a systems acceptance test to verify all requirements have been 

met, demonstrated, and documented? Has the agency documented formal stakeholder 

acceptance?
105 

CHAPTER 9. MONITORING, EVALUATING, AND USING A DST

Once the DST is operational, the agency can validate and calibrate the operation of the DST. The 

agency can continually monitor and evaluate the DST to ensure it is meeting the ongoing needs 

and requirements of the TMS and the performance metrics the agency has established. The 

purpose of this chapter is to present effective practices and recommendations for monitoring, 

validating, and calibrating the DST. 

The objectives of this chapter are as follows: 

• To provide an overview of the operations activities to consider for monitoring, 

evaluating, and adjusting a DST. 

• To identify typical performance measures for each type of DST. 

• To discuss the data requirements for performance measures that have been identified. 

After reading this chapter, the reader should better understand the measurement and monitoring 

of DSTs to ensure they are operating as expected and continue to meet the agency’s needs. 

Agencies should better understand how to identify and select key performance indicators (KPIs) 

to assist in the ongoing monitoring and evaluation of a DST. 

KEY ISSUES TO CONSIDER

When monitoring an operational DST, agencies should consider the following key questions: 

• Has the agency identified key performance criteria for the DST? Which performance 

measures and KPIs does the agency use?

• Has the agency identified the data needed to calculate the performance measures and 

KPIs? 

• Does the agency want to review performance measures on a weekly, monthly, or annual 

basis? How many times a year will the reviews occur?

• Has the agency decided on thresholds for each performance measure and KPI that 

indicate corrective actions are needed?

STEPS FOR MONITORING, EVALUATING, AND ADJUSTING A DST

As discussed in Guide to Effective Freeway Performance Measurement, developing a 

performance measurement program to evaluate the effectiveness of a TMS and DST(s) begins 

with identifying the data available to perform the evaluation (Margiotta et al. 2007). Figure 27

illustrates this principle.

During design and development of a DST, an agency can consider the purpose of the DSTs and 

how to measure whether the DST is performing correctly. This assessment will allow vendors to 
106 

configure or develop the DST to ensure the data needed for the performance measures are 

available. Depending on the contract method, a vendor should report KPIs and performance 

measures for the DST on a routine basis. Some agencies have used service-level agreements to 

incentivize the performance of the TMS and DST vendor. A service-level agreement defines the

LOS an agency can expect from a vendor, the KPIs by which the DST is measured, and the 

remedies or penalties when agreed-upon KPIs are not achieved.

Source: FHWA.

Figure 27. Diagram. Evaluating DST performance. 

The following seven sections discuss the steps for developing performance measures to evaluate 

the performance of a DST as part of a TMS. 

Step 1—Select Performance Measures and KPIs

Based on the DST the agency has selected, the agency can identify performance measures and 

KPIs associated with the DST’s operation to address the four characteristics used to evaluate 

TMSs and DSTs: effectiveness, efficiency, use, and satisfaction. For instance, the availability of 

the DST is a common performance measure that agencies use. The actual measure is related to 

how important the DST is to the agency’s operation. An agency decides how long a DST can be 

nonoperational and still meet its needs. For instance, a 99.999-percent availability means the 

system can only be nonoperational for a period of 6 min per year. A 95-percent availability 

would allow 3.65 d of downtime per year (or about 36 h per month). When measuring 

availability, agencies should consider both software and hardware in the overall calculation. 

Step 2—Obtain Existing Data 

Since most available performance data are collected for purposes other than reporting 

performance, obtaining data from existing TMSs and traveler information systems is often more 

difficult than logic would indicate. Budgets for developing and deploying TMSs and traveler 

information systems may often be smaller than needed. A common cost-reduction strategy is to 

remove or curtail the data-archiving function needed to store and efficiently retrieve data 

collected as part of a TMS. Consequently, creating a performance monitoring system often starts 

with constructing the software needed to efficiently store and retrieve data already collected by 
107 

an existing TMS. Steps 3–5 may or may not be needed, depending on the TMS, the DST, and the 

data needs.

Step 3—Develop Data Manipulation Procedures

Data manipulation allows agencies to perform actions on raw data to organize and store the data 

the TMS and DST need more efficiently. Data scientists and database developers use tools and 

data manipulation languages for adding, deleting, and modifying data in a database. 

Once obtained from the data subsystem, the data collected from the TMS can be manipulated in 

the database and used as follows: 

• As a direct measure of performance (e.g., vehicle volumes, vehicle speeds). 

• In combination with other data from other devices in the field to compute a new 

performance statistic (e.g., travel times computed from toll tag readers at different 

locations). 

• For mathematical transformation into a different performance measure (e.g., point speeds 

at consecutive locations can be used to estimate travel times along a corridor). 

• In combination with other directly measured data to produce more complex performance 

measures (e.g., vehicle volume and speed data can be used to compute vehicle hours of 

travel or vehicle hours of delay). 

• As input into various transportation modeling systems to estimate a wide variety of 

statistics that cannot be measured by the available sensor equipment (e.g., volume data 

used to feed a simulation model can produce estimates of pollution emissions). 

Step 4—Understand Available Data

Once the agency has identified all available data, the next step is to understand exactly how well 

those data represent the performance of the DST they are collected from and how limitations in 

the data affect their use as performance measures. The “Additional Resources” section at the end 

of this chapter identifies resources agencies can use to further identify the data requirements of 

the performance measures.

Understanding strengths, weaknesses, and holes in the available data helps determine what 

supplemental data need to be collected specifically for performance monitoring. The agency also 

defines the need for many of the data manipulation steps necessary and many of the assumptions 

that are made to convert the available data into performance statistics.

Step 5—Collect Supplemental Data

Once the agency understands the available data, the agency can define the supplemental data 

collection needed to complete the datasets for the desired performance monitoring system.
108 

Supplemental data will be used as follows: 

• To fill in gaps in available data, which for a DST may be historical data available from 

other agencies.

• To provide information that helps eliminate biases in the previously collected data. 

Step 6—Create Performance Measures and Develop Reports

The agency can develop performance reports using the performance measures and measures of 

effectiveness selected in step 1 and the data collected during steps 2–5. These reports can show 

how the DST is performing based on the effectiveness, efficiency, use, and satisfaction 

recommended to evaluate the performance of a DST. The performance reports can be provided 

to meet the operational needs of the agency and the importance of the DST. Reports may be run 

daily to indicate any current operational issues, weekly or monthly to show trends, and annually

to provide longer-term performance measures.

Step 7—Develop Corrective Actions

If a DST or TMS is not performing as desired (or expected), corrective actions may be needed. 

Actions may include modifying processes and procedures used by TMS operators, changing 

DST parameters and configurations, expanding DST capabilities, and implementing needed DST 

changes. TMS and DST maintenance involves ongoing monitoring, evaluation, and calibration of 

the performance of the system. See chapter 10 for further discussion on maintaining a DST. 

SELECTING APPROPRIATE PERFORMANCE MEASURES

All DSTs will have basic performance measures that agencies may consider using to ensure the 

DST is meeting the needs of TMS operators. Procurement of a DST can include specific 

performance measure requirements the selected vendor must meet. Performance measures may 

be considered that measure how well the DST is operating, if the DST recommendations are 

implemented by operators, and the operator’s perception of the DST.

These types of performance measures may include the following: 

• How quickly the DST provides a recommendation. 

• How varying conditions and data loads (e.g., minor versus major incidents) impact TMS 

and DST performance (i.e., how quickly a decision can be calculated based on the load 

on the computing platform and data platform). 

• What percentage of the time a TMS operator implements responses recommended by the 

DST. 

• How TMS operators and TMS management perceive the quality of the DST responses. 
109 

The discussion for each type of DST is not meant to be exhaustive. While these common 

performance measures may be considered on the basis of the type of DST used by a TMS, 

additional specific DST performance measures can also be considered.

Knowledge-Driven DSTs 

As previously discussed, knowledge-driven DSTs provide specialized problem-solving expertise 

based on the processing of stored facts, rules, procedures, and similar forms of knowledge. They 

attempt to emulate human reasoning but with more consistent results. Expert systems or rulesbased systems are the best-known type. These systems use databases of knowledge generated by

previous expert users along with a system’s business rules to emulate the decisionmaking 

capabilities of an expert user of the system.

For the purpose of monitoring, evaluating, and adjusting a knowledge-driven DST, performance 

is mostly related to the speed of making a recommendation based on the rules and knowledge 

base. For example, a TMS may have a rules engine and business rules that calculate the message 

for an incident verified within the TMS. When an operator verifies the incident, the DST 

recommends displaying specific messages on DMSs prior to the incident. The performance of 

the knowledge-driven DST in this situation should include the speed of the response.

Efficiency Performance Measures

Efficiency performance measures indicate the results achieved by the DST and the response 

strategies the DST uses to provide an operator with the best decision using the fewest resources. 

Performance measures to evaluate DST efficiency can include the following: 

• Capacity indicator: The ratio between the number of recommendations the DST provided 

and the time it took to make them. 

• Quality indicator: The ratio of correct response recommendations to total number of 

response recommendations. 

• Productivity indicator: The amount of time a DST takes to make a recommendation

compared to the time it would take a human operator to decide. 

Effectiveness Performance Measures

Effectiveness performance measures indicate the results achieved by the DST in providing 

timely and accurate decisionmaking. 

Performance measures to evaluate the effectiveness of the DST can include the following: 

• Speed of response generation: An indicator of how quickly from when an event occurred 

to when a recommendation was generated once minimum thresholds were met.
110 

• Accuracy of the response recommendation: An indicator of the correctness of the 

recommendation in the context of the rules and operating procedures a TMS uses for 

responding to events.

Data Requirements To Support Performance Measures

Performance measures for knowledge-driven DSTs use the DST’s and TMS’s logs of data 

associated with the incident management timeline, as follows: 

• When an incident has occurred (date, time usually from the 911 system). 

• When an incident is detected (date, time usually from the TMS).

• When a response is requested (date, time usually from the DST).

• When a response is enacted (date, time usually from the DST).

• When an incident is cleared (date, time usually from the TMS).

• When the network returns to normal (date, time usually from the TMS).

Table 17 provides example data for an incident and its source. It is important to use a common 

clock to ensure different systems are using the same time for measurements.

Table 17. Example incident management timeline. 

Event Date Time (a.m.) Source

Incident reported August 1, 2020 08:23 CAD 911

Incident detected August 1, 2020 08:25 TMS

Incident verified August 1, 2020 08:35 TMS

Response requested August 1, 2020 08:36 TMS

Response recommended August 1, 2020 08:44 DST

Response enacted August 1, 2020 08:55 DST

Incident cleared August 1, 2020 09:30 TMS

Return to normal August 1, 2020 09:45 TMS

CAD = computer-aided dispatch.

From the data provided in table 17, several performance measures can be created:

• TMS incident verification time: 12 min (incident verified—incident reported).

• DST response plan enacting time: 19 min (response enacted—response requested).

• Incident clearance time: 1 h, 7 min (incident cleared—incident reported).

Agency operators can use these values to identify potential corrective actions and improvements 

in the systems, processes, and tools the agency uses as part of its TMS.
111 

Data-Driven DSTs 

Data-driven DSTs typically use data from databases that are designed to be queried, which 

enables processing and analysis of data to develop insights that support decisionmaking. 

Statistical analysis software is one of the most common types of DSTs. More recent systems use 

ML algorithms to learn from historical data to identify patterns and make predictions based on 

current data. The effectiveness of a data-driven DST depends on the quality of the data gathered 

and the effectiveness of the analysis and interpretation by the decisionmaker. Two basic types of 

data-driven DSTs measure performance in different manners, as discussed in the following two 

sections.

Statistical Model Data-Driven DST

Statistical models use mathematical formulas and historical data to predict future conditions. 

Some of the more common types of statistical models used for data-driven DSTs are linear 

regression, logistic regression, time series, decision trees, neural networks, support vector 

machines, and Naïve Bayes classifiers (Mitchell 2017). Each model works best for specific types 

of data and desired output. A statistical model data-driven DST’s performance measure is related 

to how well it predicts and recommends a response to an event within a TMS. 

ML Data-Driven DST

The challenge for ML data-driven DSTs is that they need different measures, depending on the 

purpose of the DST. ML data-driven DSTs can self-learn as new data are received, so measuring 

their performance can be a challenge. However, systems and data used by the ML data-driven 

DST need to be measured and monitored to detect issues at the right time. This monitoring 

includes monitoring the data input into the DST and measuring the performance metrics for 

detecting strange model behavior, which ensures the DST does not provide unexpected results.

For example, ensuring the data input into the DST is accurate and timely can be monitored and 

measured. The availability and response time of the DST can be measured to ensure the DST is 

operating as expected in a timely manner.

Performance Measures for Data-Driven DSTs 

Which performance measures are used influences how the performance of a data-driven DST is 

measured. However, performance measures can also be deceiving. If agencies do not choose 

performance measures that correctly measure how accurately the DST is predicting, they may 

falsely conclude a DST is a robust prediction engine. All problems that data-driven DSTs can 

solve fall into two categories: classification problems and regression problems. 

A classification performance measure indicates what category something falls into. The 

following performance measures can be used to evaluate a classification of the DST:

• The classification accuracy is the ratio of correct predictions to the total number of 

predictions made. For instance, a DST might predict when an incident is likely to occur. 

The correct prediction can be measured if the incident does occur. However, this may 

also be challenging, because part of the DST’s functionality is to recommend an action to 
112 

mitigate the predicted incident. To measure accuracy, an agency may need to choose not 

to respond to the prediction to ensure the DST is accurate. 

• A confusion matrix provides a matrix as output and describes the complete performance 

of the model. This description includes four key terms:

o True positives: the times the DST provided correct predictions and recommended 

actions. 

o True negatives: the times the DST provided correct predictions and recommended no 

actions. 

o False positives: the times the DST provided incorrect predictions.

o False negatives: the times the DST provided incorrect actions.

A regression performance measure is about predicting a quantity. The following performance 

measures can be used to evaluate a DST’s regression values: 

• R-squared indicates how well the variation of a measure is explained by the other

variables included in the DST prediction. R-squared does not take into consideration any 

biases that might be present in the data. Therefore, a good data-driven DST might have a 

low R-squared value, or a data-driven DST that does not fit the data might have a high Rsquared value. 

• Average error is the numerical difference between the predicted value and the actual 

value. 

• Median error is the average of all differences between the predicted and the actual values. 

• Average absolute error is similar to average error but is calculated by using the absolute 

value of the difference to balance out the outliers in the data.

Choosing the correct granularity of the data being used for the regression analysis is important to 

ensure the precision of the analysis. For instance, an agency may have micro-second traffic 

signal data used to determine the effectiveness of changing a signal timing plan. However, 

condensing the data into a longer time frame (1 s, 10 s, etc.) may be quicker, require less work to 

perform the analysis, and yield just as useful results.

Data Requirements To Support Performance Measures

Performance measures for data-driven DSTs use data to calculate when the predictions and 

actions are correct versus when they are incorrect and the associated data types. This task may 

require an assessment by operations experts to compare the DST’s recommendation to the 

experience and expertise of the senior operations personnel in the agency. 
113 

Model-Driven DSTs 

Model-driven DSTs use mathematical models that express the theoretical relationships among 

data elements or key variables of interest for an analysis being conducted. These tools can be 

used (either online or offline) to simulate the behavior of a transportation system (or parts of the 

system) using different values for certain parameters. Model-driven DSTs use different types of 

analysis tools (e.g., statistical software and traffic analysis software) to assess the available data, 

evaluate the data, and report on conditions. 

Performance Measures for Model-Driven DSTs 

Performance measures for model-driven DSTs use data to calculate when the predictions and 

actions are correct versus when they are incorrect and the associated data types to include all 

traffic data associated with the output of the model (i.e., volume data—both predicted and 

actual). The most common performance measure is volume accuracy (GEH statistic): For traffic 

simulation models, the model will predict traffic volumes on the transportation network, which is 

compared against the actual volumes from field equipment connected to the TMS. The volume 

accuracy will be defined by 95 percent of available count locations using the formula in figure 

28. 

© Geoffrey E. Havers. 

Figure 28. Equation. GEH statistic.

Where: E = model-estimated volume. 

V = field count or volumes from the TMS. 

The GEH formula is useful in the following situations: 

• Comparing the traffic volumes obtained from a travel demand forecasting model with 

real-world traffic volumes. 

• Adjusting the traffic volume data collected at different times to create a mathematically 

consistent dataset that can be used as input for travel demand forecasting models or 

traffic simulation models, as discussed in NCHRP Report 765 (Horowitz et al. 2014). 

Data Requirements To Support Performance Measures

Performance measures for model-driven DSTs use data to compare the simulated network and 

the actual network to determine if the model-driven DST needs recalibration.
114 

DST Performance Measure Checklist

Following is a performance measure checklist with useful questions to ask:

• Has the agency selected the performance measures for the TMS and DST?

• Has the agency identified existing data for calculating the performance measures?

• Has the agency developed a process for manipulating existing data sources, if needed?

• Has the agency decided on the data collection process and defined the storage 

requirements?

• Has the agency decided on the algorithms and formulas for calculations of the selected 

performance measures?

• Has the agency decided the reporting format and frequency for each performance 

measure?

OBTAINING THE DATA NEEDED FOR MEASURING PERFORMANCE

During the design and development phases of a DST project, an agency identifies the 

performance measures that will be used to monitor a DST during operations. Next, the agency 

identifies the data requirements for those measures. Requirements for the TMS, the DST, and 

external systems are developed to ensure that all data, with the correct granularity, is available 

once the DST becomes operational.

If the current TMS and external systems do not have the data or the granularity needed, agencies 

may decide to modify those systems to make the data available. Additionally, other sources of 

the data may be investigated. For example, the Dallas ICM DSS needed traffic volume and 

speeds by lane for the US 75 freeway. However, the regional center-to-center system only 

provided aggregated speed and volume data across all lanes. To receive the more granular data, 

an interface to the TxDOT TMS software was integrated, which did provide the volume and 

speed data per lane (FHWA 2015).

PERFORMANCE REPORTING

The performance of a TMS, DST, and the transportation network can be assessed using three 

levels of performance. The three levels of performance reports used in operations include the 

following:

• Real-time dashboards and reports: Operators use these reports and dashboards to view 

and analyze real-time systems, check whether the DST and TMS are working properly, 

and provide a list of current active decisions being managed.

• KPIs and deviations from historical norms: TMS managers and supervisors use these 

reports and dashboards to identify if the TMS, DST, or transportation network is 

operating outside of historical norms. For instance, if a freeway is operating at an average 
115 

speed of 25 mph during the morning rush, the DST can analyze this data and inform users 

that a 40-mph speed is normal and further investigation may be needed. These reports 

and dashboards can provide real-time KPIs on how quickly a DST moves from event 

notification to decision recommendation versus the average time this determination has 

been made in the past using a legacy system or staff. This measurement will indicate 

whether the DST is operating less efficiently or having issues that maintenance personnel 

may need to investigate.

• High-level summary data and KPIs: Managers and agency executives use these 

dashboards to view summary data from the TMS and DST. These data might include 

current average speed of the network (versus historical) and current number of active 

events.

Similar to the requirements for the data needed for performance measures, the performance 

reporting and dashboards are identified during the design phase to ensure the correct data and 

format will be available once the DST is developed.

CORRECTIVE ACTIONS

By using performance measures and KPIs, agencies can identify TMS or DST systems, 

procedures, and field equipment that may need corrective action. Through the proactive use of 

the data and KPIs, agencies can quickly identify when a DST may not be operating as expected. 

The DST may need routine maintenance or recalibration (i.e., retraining and calibration of a 

model-driven DST). The performance measures and KPIs can also provide trends over time to 

show a degradation of the performance of systems and equipment that may need maintenance, 

enhancement, replacement, or retirement.

ADDITIONAL RESOURCES

The following additional resources can assist agencies in developing performance measures and 

evaluation processes for DSTs: 

• Park’s (2005) Transportation Management System Performance Monitoring, Evaluation, 

and Reporting—A Technical Handbook. 

• National Academies of Sciences, Engineering, and Medicine’s (2022) Evaluating 

Alternative Operational Strategies To Improve Travel Time Reliability. 

• Margiotta et al.’s (2007) “Guide to Effective Freeway Performance Measurement: Final 

Report and Guidebook.” 

• Dowling’s (2007) Traffic Analysis Toolbox Volume VI: Definition, Interpretation, and 

Calculation of Traffic Analysis Tools MOEs. 

• Breck et al.’s (2017) The ML Test Score: A Rubric for ML Production Readiness and 

Technical Debt Reduction. 

• Amershi et al.’s (2019) “Software Engineering for Machine Learning: A Case Study.” 
116 

EXAMPLE OF MONITORING AND EVALUATING A DST

For the ICM program, the USDOT evaluation team developed an evaluation plan for the DSTs 

for both the Dallas and San Diego ICM projects. These evaluations considered several key 

performance and accuracy measures, as follows: 

• The quality of responses generated by the DSTs. 

• The accuracy of the simulation software’s predictions as to transportation system 

conditions 30 min or more into the future.

• The speed of response plan generation. 

• The impact of varying conditions and data loads (e.g., minor versus major incidents) on 

TMS and DST performance (i.e., how quickly a decision can be calculated based on the 

load on the computing platform and data platform). 

The evaluation of the DST considered different measures of effectiveness to be analyzed, 

including the following: 

• Percentage of times a TMS operator implements responses recommended by the DST. 

• Percentage of times a TMS operator alters the recommended responses (without 

dismissing them completely). 

• Average time for the DST to deliver an actionable response plan. 

• Average time for the DST to deliver predictions of response plan effectiveness. 

• Average number of response plans generated per hour during event. 

In addition, the following qualitative measures of effectiveness were selected and used as a basis 

for the evaluation:

• Responses consistent with operator’s experience and perceptions (per the TMS 

operators). 

• Perceived quality of responses, including improvements relative to any comparable 

preICM approaches (per the TMS operators). 

For the evaluation, the data collected were through a mixture of interviews and directly from the 

TMS data subsystem by the evaluator. The performance measures were developed offline after 

the project was completed. Through APIs provided by the Dallas ICM TMS, the evaluator 

connected to the data subsystem and routinely downloaded all data into their own data platform, 

which was used for the evaluation. 
117 

CHECKLIST: MONITORING, EVALUATING, AND ADJUSTING A DST

After the agency has begun DST operations and wants to ensure the DST is performing as 

expected, the agency can begin DST measurement and monitoring. The following questions can 

assist agencies in ensuring they are prepared to monitor, evaluate, and adjust the operation of a 

DST:

• Has the agency identified the key performance criteria for the DST? 

• Has the agency identified which performance measures and KPIs will be used? 

• Has the agency identified what data are needed to calculate the performance measures

and KPIs? 

• Has the agency identified any additional data needed to calculate the performance 

measures and KPIs that must be created or developed?

• Is the agency planning to review performance measures weekly, monthly, or annually? 

• Has the agency decided the threshold for each performance measure and chosen KPIs to 

indicate when corrective actions will be needed?

119 

CHAPTER 10. USING AND MAINTAINING DECISION-SUPPORT TOOLS

The purpose of this chapter is to provide agencies with an overview of the ongoing operations, 

monitoring, and maintenance of a DST once it is operational. This chapter discusses the routine 

maintenance activities for each type of DST technology and focuses on DST maintenance to 

ensure it is operating, and continues to operate, as expected. 

The objectives of this chapter are to provide the following: 

• An overview of the maintenance activities to consider for a DST. 

• An overview of the types of maintenance to consider for a DST. 

• A framework for monitoring the operation of a DST and deciding when maintenance is 

needed. 

After reading this chapter, the reader should better understand when DST maintenance is needed, 

the activities used to tune the DST, and how to identify when enhancements or the replacement 

of a DST may be needed. 

KEY ISSUES TO CONSIDER

Agencies should consider the following key questions when preparing for and maintaining a 

DST:

• What key processes are involved in maintaining a DST?

• What activities are needed for the routine maintenance of a DST?

• Does the agency have monitoring tools in place to ensure the DST is operating correctly?

• Does the agency have a process for reporting DST issues?

• Does the agency have a process for managing changes? 

• Does the agency have a process for managing enhancements and new releases?

• Does the agency have a plan to train operators when changes are made to the DST?

MAINTENANCE PROCESSES

Many agencies may already have maintenance processes for their IT systems. The maintenance 

processes for TMSs and DSTs may be similar. Agencies perform TMS and DST maintenance for 

reasons including the following: 

• To correct failures in the TMS and DST. 

• To interface with new systems. 

• To enhance the TMS or DST. 

• To migrate to a new TMS or DST. 

• To retire a TMS or DST. 

• To upgrade the TMS subsystems (computer hosting platforms and data platforms). 
120 

Two of the most common types of DST maintenance are as follows: 

• Corrective maintenance: This category includes modifying and updating the TMS 

subsystems and DSTs to correct or fix problems and failures that are either discovered by 

operators or identified through performance reports.

• Preventive maintenance: This category includes modifying and updating the TMS to 

prevent future problems with the subsystems. Preventive maintenance aims to prevent 

problems that might not cause issues in the moment but may cause issues in the future. 

This type of work may include archiving old data within the data subsystem to free up 

resources and space on the computer-hosting platform.

STEPS FOR MAINTAINING A DST

The purpose of the operations and maintenance phase is to use the system to deliver its services. 

TMS personnel operate the system, monitor the system and services, and measure the system 

performance. To sustain the DST, monitoring tools may identify and analyze operational 

problems in relation to vendor contracts, stakeholder requirements, and organizational needs and 

constraints, as shown in figure 29. 

Source: FHWA.

Figure 29. Diagram. Maintaining a DST.

The following three sections describe the steps for the ongoing maintenance and monitoring of a 

DST.

Step 1—Monitor and Maintain the DST

Monitoring a DST is similar to monitoring any software application. Using monitoring tools, a 

DST may be monitored for operational and performance conditions. Operational monitoring is 

used to ensure the DST is working. The resources from the computer hosting platform and 

software subsystem are monitored to ensure the DST has the needed resources, including

computer memory, disk space, and connectivity between the DST and other software. 
121 

Performance monitoring is used to ensure the DST is performing as expected with tracking and 

reporting on performance issues. Performance monitoring for a DST may be based on the type of 

DST and its key performance measures. Performance monitoring includes performance 

indicators, such as the average response time for a DST to provide a recommendation. Data from 

both operational and performance monitoring may be recorded for calculation of longer-term 

performance measures, which can be used to identify when DST changes may be needed. 

Step 2—Identify When Changes Are Needed

The DST and its related subsystems may need changes when the performance has degraded, new 

functionality is necessary, or new business processes are identified. A DST may need its 

hardware, software, logic, or underlying data updated when it no longer performs as expected, 

when new information and data become available, or when changes are made to one of the 

components. Updates are also needed when the computing hardware platform, DST (e.g., 

software and algorithms), or TMS has reached the end of its life or when upgrades are made to 

one component. Changes to a DST may be needed when expectations, policies, and technologies

evolve. Additionally, agencies may identify unintended and undesirable effects when monitoring 

the DST due to the DST’s actuating process or its recommendation of inappropriate, 

unacceptable, or outdated actions, which means changes to the DST are needed.

Step 3—Update and Replace the DST

Once the agency has identified changes to the DST, the agency can follow a defined change 

management and configuration management process to make changes to the TMS and DST 

subsystems.

KEY MAINTENANCE CONCEPTS

A TMS and its DST(s) may need hardware, software, logic, or underlying data updated when

performance is not as expected, when new information is available, or when changes have been 

made to one of the components. Agencies will likely need to evaluate and plan for potential 

changes to DSTs any time changes occur in a TMS. Enhancements to DSTs or APIs can be done 

simultaneously with TMS changes or after they have been made, depending on how complex the 

changes are. If there are numerous changes, agencies might want to consider modifying one 

subsystem at a time so that errors are more easily detected and analyzed if they occur. 

Managing and Improving DST Operation

A DST provides key information and decisionmaking support to assist transportation agencies in

understanding the increasing volume of incoming data and choosing from a complex array of 

alternative actions. To consider changes to a DST, an agency can follow a change management 

process similar to the one seen in figure 30. The first step is to identify a potential change to the 

DST based on monitoring and agency needs. Potential changes may include new functionality or 

fixing an identified problem. 

Before implementation, an agency may want to evaluate any change to any software system to 

determine its potential impact on the overall TMS, cost, and benefits. Once this information is 

known, an agency can decide whether the change can be made or not. 
122 

Source: FHWA.

Figure 30. Diagram. Change management process. 

Once the agency decides to proceed with a change, the agency can develop a plan for the change. 

This plan may include the updating process for the various subsystems, the installation 

procedures, and back-out procedures if the change does not go as planned. Once the change has 

been deployed, the TMS can be fully tested to ensure the change is performing as expected and 

has not created unforeseen impacts. Lastly, the configuration changes are documented and 

verified. Following these procedures, normal operation can continue. 

Assessment Approaches and Evaluation Methods

How an agency assesses DST performance depends on the type of DST and the data available 

from the TMS, the outputs of the DST (its functions and types of decisions), and data from 

various field devices. From a computer system point of view, many tools and processes are 

available to ensure the hardware, network, and software are operating correctly. From an 

operational perspective, agencies can monitor the following TMS and DST system elements to

evaluate whether a DST is operating correctly:

• The availability and accuracy of data, information, and content as decision inputs. 

• Any decision-process bottlenecks and traffic (i.e., whether decision calculations are 

taking too long due to a resource constraint within the system). 

As discussed in chapter 9, performance measures can be established through assessing 

effectiveness, efficiency, use, and satisfaction. The following example measures address these 

items:

• Correctness and precision of DST response recommendations: Is the recommendation 

accurate?

• Problems resolved after DST response recommendations (percentage): Is network 

performance improved? 

• Speed of decisionmaking: Does a DST take too long to recommend a response? 
123 

• Timeliness and efficiency of operator process: How long does it take a TMS operator to 

accept, reject, or modify a response recommendation? 

• Productivity of DST: How many response recommendations are calculated for a given 

event? 

• Operator confidence in DST predictions and response recommendations: Does the 

operator trust the system? (This assessment is a qualitative measure). 

Computing Hardware Updates

Computing hardware or subsystem updates usually occur when the current hosting servers are 

near or at end-of-life. Due to growth, budget cuts, or rack limitations, servers deployed for one 

purpose often begin fulfilling additional services and responsibilities; therefore, it is important to 

periodically audit systems. Reviewing a server’s resource load helps ensure the organization 

optimizes performance and prevents downtime. Server upgrades always need planning. 

Data Updates 

Changes in the transportation network can occur frequently, depending on where the data 

originate (e.g., third-party data, detectors, and other TMSs). For the majority of TMSs, two types 

of data changes may occur: static and dynamic. Static data (e.g., roadway network and device 

location) do not change often; dynamic data (e.g., speed, volume, and occupancy) are constantly 

changing. The accuracy of the static data used by a TMS can impact DST operation. Agencies 

may implement a defined update period to ensure changes can be made to all systems affected by 

data changes. Quarterly updates to the static data may be appropriate for traveler information 

systems, TMSs, and ICM programs. 

New sources and types of data may become available as a TMS matures (e.g., additional field 

detectors, third-party data, CV data). When these sources become available, an analysis should 

be done to determine if these data will improve DST accuracy and reliability. Just because a new 

data source is available does not necessarily mean it should be integrated into the TMS and used 

by its DST(s). 

Software Updates

Knowledge-Driven DSTs 

Knowledge-driven DSTs may need updates when the business process or operating process has 

changed. Business rules management systems are the most common type of knowledge-driven 

DSTs and use an expert’s experience and knowledge to develop a set of rules. When the 

operating procedures for a TMS change due to experience, policy, or new technology, the 

knowledge-driven DST may need to be updated. 

Updates to a knowledge-driven DST should occur if the current DST is not performing as 

expected or if new operating policies and procedures are implemented. For example, if a TMS 

adds CV infrastructure to its system, a business rule to post a CV message on a series of roadside 

units may be added to the rules engine logic for specific situations. If new or additional response 
124 

plans have been developed due to changes in the transportation network because of temporary 

construction or longer-term construction, then changes to the DST may be needed. 

Performance issues may be another reason for an update. For example, if a DST is taking longer 

than expected to make a recommendation, a change to the DST may be needed. Replacing a 

knowledge-driven DST to acquire new technology with additional functionality or features that

the current DST lacks is the change most likely to be needed. 

Data-Driven DSTs 

Data analytics models and ML models are two types of data-driven DSTs. The effectiveness of a 

data-driven DST depends on the quality of the data gathered and used to train/calibrate the 

data-driven DST and the analysis and interpretation by the decisionmaker using the model. 

Both types of data-driven DSTs may need updating when new training data have become 

available, and the current DST is not providing the expected results because of changes in the 

data. Two types of retraining or calibration can occur for ML engines: manual retraining and 

continuous learning.

Manual retraining maintains the data-driven DST with fresh data to train and deploy the DST 

using the same process used to develop the ML engine. Continuous learning, the process to 

support a data-driven DST, keeps it up-to-date using an automated system to continuously 

evaluate and retrain the ML engine. Continuous learning may include the following aspects: 

• Saving the new training data as they are received. For example, if updated travel patterns 

and incident data are being received, saving that information to a database.

• Testing the data accuracy against the ML engine when enough new data have been 

received. 

• Using the new data if the accuracy of the ML engine degrades over time, or a 

combination of the new data and old training data, to build and deploy a new ML engine. 

The benefit to a continuous learning system is that it can be completely automated. Since 

data-driven DSTs can be recalibrated or retrained, replacing them need only occur if there is new 

technology, if a new vendor is selected, or if a new type of DST is being implemented. A release 

management plan should be developed to deploy and test the new DST and retire the old DST, 

similar to other software system replacements.

Model-Driven DSTs 

Model-driven DSTs use mathematical models that express the theoretical relationships among 

data elements or key variables of interest for an analysis being conducted. The most common 

type of model-driven DST is a simulation model. Similar to planning models, a model-driven 

DST needs to be updated when travel demand and travel patterns change, when the 

transportation network changes, or when the commercial modeling product changes. 
125 

Updating a model-driven DST is done for three components of the simulation model: updating 

the transportation network model, updating the transportation data, and updating the software 

product. When new roads are constructed or modifications are made to the physical 

transportation network, the DST may be updated to reflect these changes. This updating may 

include changes to a signalized traffic intersection that include a new lane configuration, a new 

road being built, or changes to an existing road that include new lane configurations. 

Since simulation models use historical and real-time data to simulate the transportation network, 

recalibrating the model may be necessary when data changes for travel patterns and travel 

demand. 

Lastly, if a vendor updates the software product the model-driven DST uses, a change 

management process can be followed for testing the updated product to determine whether the 

model is still valid or if it needs to be recalibrated. Like a data-driven DST, a model-driven DST 

can be recalibrated or retrained—replacement is needed if there is new technology, a new vendor 

is selected, or a new type of DST is being implemented. 

FRAMEWORK FOR DETERMINING WHEN MAINTENANCE IS NEEDED

When changes occur in the TMS, agencies may evaluate and plan for potential changes to the 

DSTs. Depending on the complexity of the change, the enhancements to the DSTs or APIs can

be done simultaneously or after the TMS changes have been made. If there are numerous 

changes, agencies may want to consider doing one subsystem at a time; this way, errors can be 

more easily determined if they occur. 

All TMS and DST changes should follow a change management process, with defined back-out 

procedures in case the changes fail or do not deliver the expected result. According to the 

Information Technology Infrastructure Library process framework, the goal of change 

management is to control risk and minimize disruption to associated IT services and business 

operations (Change Management Institute 2015). 

Computing Hardware Updates

Computing hardware or subsystem updates usually occur when the current hosting servers are 

near or at end-of-life. Reviewing a server’s resource load helps ensure the organization optimizes 

performance and prevents downtime. 

Software and API Updates

As with hardware updates, the process for updating the operating system, tools, software, APIs, 

and database software on the servers should be thoroughly tested. A back-out procedure should 

be developed in the event an upgrade does not go as planned. 

Newer generations of DSTs are beginning to have self-evaluating capabilities. Additionally, 

agency staff should monitor and evaluate DSTs for the effectiveness of recommended responses 

and the utilization rates. If recommended responses run counter to the preset agreements and 

boundaries of a DST’s logic, agency staff should review the DST for areas that need 
126 

improvement. Depending on the type of DST(s) used, business rules or predictive models may 

need to be updated based on changes in the data or analysis of the DST operation. 

Data Updates 

Changes in the transportation network can occur frequently, depending on where the data 

originate (e.g., third-party data, detectors, and other TMSs). For the majority of TMSs, two types 

of data changes may occur: static and dynamic. Static data (e.g., roadway network and device 

location) do not change often; dynamic data (e.g., speed, volume, and occupancy) are constantly 

changing. The accuracy of static data used by a TMS can impact the operation of the DSTs. > 

Agencies may implement a defined update period to ensure changes can be made to all systems 

affected by data changes. Quarterly updates to the static data may be appropriate for traveler 

information systems, TMSs, and ICM programs. 

New sources and types of data may become available as a TMS matures (e.g., additional field 

detectors, third-party data, CV data). When these sources become available, an analysis should 

be done to determine if these data will improve DST accuracy and reliability. Just because a new 

data source is available does not necessarily mean it should be integrated into the TMS and used 

by its DST(s). 

USING AND MAINTAINING A DST: CASE STUDY

The Dallas Integrated Corridor Management (ICM) Demonstration Project case study illustrates 

some of the maintenance concepts discussed in this chapter and the potential impacts of not 

maintaining a DST. The US 75 ICM project was a collaborative effort led by Dallas Area Rapid 

Transit in collaboration with USDOT; the cities of Dallas, Plano, Richardson, and University 

Park; the town of Highland Park; the North Central Texas Council of Governments; North Texas 

Tollway Authority; and TxDOT. The Dallas ICM deployment focused on the four primary goals 

of any ICM: improving incident management, enabling intermodal travel decisions, increasing 

corridor throughput, and improving reliability of travel time (FHWA 2015). 

The Dallas team used a variety of coordinated multimodal operational strategies to achieve these 

goals using DSTs, including the following: 

• Use simulations to predict travel conditions for improved operational responses. 

• Implement response plans interdependently among agencies. 

• Divert traffic to strategic arterials and frontage roads with improved, event-specific 

response plans for traffic signal timing.

These strategies were implemented using a combination of two DSTs. The primary DST was a

knowledge-driven DST that used a rules-based engine to produce potential response plans for 

incidents on US 75. The rules-based engine considered incident location, direction of travel, time 

of day, and congestion to select an initial response plan. Next, it evaluated conditions on detour 

routes, including available capacity on frontage roads and parallel arterials, and alternative 

modes, including light-rail transit. After making calculations, the rules-based engine selected 

potential response plans for the secondary, model-driven DST to evaluate. 
127 

The model-driven DST was used to simulate the various response plans and select the plan that 

provided the most overall benefit to the corridor. The model-driven DST used a simulation 

engine that employed a mesoscopic model to simulate the US-75 corridor. 

Maintaining the knowledge-driven DST and the model-driven DST for the ICM program 

included monitoring the DSTs within the TMS computer hosting platform and ensuring the 

DSTs were online and receiving information. Additionally, data was collected from both DSTs 

for later evaluation of their performance. The stakeholder team met on a monthly basis to review 

the incidents that occurred, the response plans that were selected by the DSTs, and the impact of 

the responses provided. Adjustments were then made to the response plans and the rules engine 

if changes were determined necessary by the stakeholder committee. 

The importance of maintenance was most evident with the model-driven DST. Due to funding 

issues, the model-driven DST’s calibration was not maintained with new transportation network 

data as it became available. The model-driven DST was not recalibrated for a period of 2 yr, 

which caused the stakeholders to begin to question its output and reliability after the 2 yr of 

operation. Since the model was no longer calibrated to the current network, the stakeholders 

decided to retire the DST for the ICM program. This anecdote illustrates that a DST needs 

ongoing operations, maintenance, and recalibration to ensure the agency’s investment receives 

its expected benefits over the life of the TMS.

ADDITIONAL RESOURCES

Agencies can reference the following resources to review processes for maintenance of software 

systems:

• ISO’s (2006) ISO/IEC 14764: 2006 Software Engineering—Software Life Cycle 

Processes—Maintenance

• Smith’s (2003) Configuration Management for Transportation Management Systems: 

Final Report

• Jackson, Gallagher, and Dorgan’s (n.d.) “System Maintenance” web page from the 

Systems Engineering Book of Knowledge (SEBoK) website

• ISO’s (2015) ISO/IEC/IEEE 15288:2015 Systems and Software Engineering—System 

Life Cycle Processes
128 

DST MAINTENANCE CHECKLIST

After an agency has begun operations and monitoring of its DST, the agency should consider a 

DST maintenance process to ensure the DST is continuing to operate as expected. To help ensure 

they are prepared for maintaining the DST for its useful life, agencies should ask the following 

questions: 

• Has the agency defined all DST maintenance activities?

• Does the agency have the monitoring tools in place to ensure DST(s) are operating 

correctly?

• Does the agency have a process for reporting issues with DST(s)? 

• Does the agency have a process to manage changes to DST(s)? 

• Does the agency have a process to manage enhancements and new releases?
129 

REFERENCES

Agile Alliance. n.d. “Agile 101” (web page). https://www.agilealliance.org/agile101/, last 

accessed November 2, 2022. 

Alexiadis, V., K. Jeannotte, and A. Chandra. 2004. Traffic Analysis Toolbox Volume I: Traffic 

Analysis Tools Primer. Report No. FHWA-HRT-04-038. Washington, DC: FHWA. 

Alexiadis, V., D. Salman, and A. Armstrong. 2012. Traffic Analysis Toolbox Volume XIII: 

Integrated Corridor Management Analysis, Modeling, and Simulation Guide. Report No. 

FHWA-JPO-12-074. Washington, DC: FHWA. 

Altschuld, J., and D. D. Kumar. 2010. Needs Assessment: An Overview. Thousand Oaks, CA: 

SAGE Publications, Inc. 

Amershi, S., A. Begel, C. Bird, R. DeLine, H. Gall, E. Kamar, N. Nagappan, B. Nushi, and T. 

Zimmerman. 2019. “Software Engineering for Machine Learning: A Case Study.” 

Presented at the ICSE ‘19: 41st International Conference on Software Engineering.

Montreal, Canada: SIGSOFT and IEEE-CS.

Breck, E., S. Cai, E. Nielsen, M. Salib, and D. Sculley. 2017. “The ML Test Score: A Rubric for 

ML Production Readiness and Technical Debt Reduction.” In Proceedings: 2017 IEEE 

International Conference on Big Data. Boston, MA: IEEE.

California Department of Transportation and FHWA. 2009. Systems Engineering Guidebook for 

Intelligent Transportation Systems 3.0. Washington, DC: FHWA. 

https://www.fhwa.dot.gov/cadiv/segb/files/segbversion3.pdf, last accessed February 15, 

2023. 

Change Management Institute. 2015. The Effective Change Manager: Change Management 

Body of Knowledge, 1st ed. New York, NY: Change Management Institute.

https://www.tsoshop.co.uk/product/9780992362492/The-Effective-Change-ManagerChange-Management-Body-of-Knowledge-PDF-PDF, last accessed February 15, 2023. 

Chart.maryland.gov. n.d. “Welcome to Maryland 511 and CHARTWeb!” (website). 

https://chart.maryland.gov/, last accessed February 17, 2023. 

Chiu, Y., J. Bottom, M. Mahut, A. Paz, R. Balakrishna, T. Waller, and J. Hicks. 2011. 

Transportation Research Circular E-C153: Dynamic Traffic Assignment: A Primer. 

Washington, DC: TRB. 

Christie, B., D. Hardesty, G. Hatcher, and M. Mercer. 2015. Integrated Corridor Management: 

Implementation Guide and Lessons Learned. Report No. FHWA-JPO-16-280. 

Washington, DC: FHWA. 

Cyert, R., and J. March. 1963. A Behavioral Theory of the Firm. Englewood Cliffs, NJ: 

Prentice-Hall.
130 

DeWeese, P. R. 1994. MIL-STD-498: Software Development and Documentation V 01.00.00. 

Report No. SPC-94032-CMC. Herndon, VA: Virginia Center of Excellence for Software 

Reuse and Technology Transfer. https://apps.dtic.mil/dtic/tr/fulltext/u2/a282003.pdf, last 

accessed February 15, 2023. 

Dowling, R. 2007. Traffic Analysis Toolbox Volume VI: Definition, Interpretation, and 

Calculation of Traffic Analysis Tools Measures of Effectiveness. Report No. 

FHWA-HOP-08-054. Washington, DC: FHWA. 

FDOT. 2005. Statewide Systems Engineering Management Plan for Intelligent Transportation 

Systems. Deliverable 1-10: Technical Memorandum. Tallahassee, FL: FDOT.

https://www.fdot.gov/docs/defaultsource/traffic/its/projects_deploy/semp/pdf/050315_D1-10_V2.pdf, last accessed 

February 15, 2023. 

FDOT. 2022. “FDOT District 5 Regional Integrated Corridor Management System (R-ICMS)” 

(web page). https://teo.fdot.gov/architecture/architectures/d5/html/elements/el286.html, 

last accessed February 15, 2023. 

FHWA. 2015. Dallas Integrated Corridor Management (ICM) Demonstration Project—Final 

Report. FHWA-JPO-16-234. Washington, DC: FHWA. 

https://rosap.ntl.bts.gov/view/dot/3573, last accessed February 15, 2023. 

FHWA. 2020. “Welcome to the Systems Engineering Guidebook for ITS Web Site” (website). 

https://www.fhwa.dot.gov/cadiv/segb/, last accessed February 15, 2023. 

FHWA. 2021. “Office of Research, Development, and Technology at the Turner-Fairbank 

Highway Research Center” (website). 

https://highways.dot.gov/research/laboratories/saxton-transportation-operationslaboratory/ITS-technologies, last accessed February 15, 2023. 

Gord, A. 1997. Federal-Aid ITS Procurement Regulations and Contracting Options. Report No. 

FHWA-RD-97-145. Washington, DC: FHWA. https://rosap.ntl.bts.gov/view/dot/35881, 

last accessed February 15, 2023. 

GovRegs. USC Title 23, Chapter 1, § 101(a). 2023. 

https://www.govregs.com/uscode/title23_chapter1_section101, last accessed February 21, 

2023. 

Heusser, M., and P. Varhol. 2017. “4 Factors for Testing Machine Learning Applications.” 

InfoWorld, January 5, 2017. https://www.infoworld.com/article/3155066/4-factors-fortesting-machine-learning-applications.html, last accessed February 15, 2023. 

Horowitz, A., T. Creasey, R. Pendyala, and M. Chen. 2014. Analytical Travel Forecasting 

Approaches for Project-Level Planning and Design. NCHRP Report 765. Washington, 

DC: TRB. http://www.trb.org/Publications/Blurbs/170900.aspx, last accessed February 

15, 2023. 
131 

IEEE. 1998. IEEE Recommended Practice for Software Requirements Specifications. 

IEEE 830-1998. New York, NY: IEEE.

IEEE. 2006. Standard for Common Incident Management Message Sets for Use by Emergency 

Management Centers. IEEE 1512. New York, NY: IEEE.

INCOSE. 2011. INCOSE Systems Engineering Handbook, version 3.2.2. Report No. 

INCOSE-TP-2003-002-03.2.2. San Diego, CA: INCOSE.

Institute of Transportation Engineers. 2020. Traffic Management Data Dictionary (TMDD) 

Standard v3.1 for the Center-to-Center Communications. Washington, DC: ITE.

ISO. 2006. Software Engineering—Software Life Cycle Processes—Maintenance. ISO/IEC 

14764: 2006. Geneva, Switzerland: ISO. https://www.iso.org/standard/39064.html, last 

accessed February 15, 2023. 

ISO. 2008. International Standard—Systems and Software Engineering—System Lifecycle

Processes. ISO/IEC/IEEE 15288-2008. Geneva, Switzerland: ISO. 

https://standards.ieee.org/standard/15288-2008.html, last accessed February 15, 2023. 

ISO. 2011. Guidance for the Development of the Set of Requirements, System Requirements 

Specification (SyRS). ISO/IEC/IEEE 29148:2011. Geneva, Switzerland: ISO. 

https://www.iso.org/standard/45171.html, last accessed February 15, 2023. 

ISO. 2015. Systems and Software Engineering—System Life Cycle Processes. ISO/IEC/IEEE 

15288:2015. Geneva, Switzerland: ISO. https://www.iso.org/standard/63711.html, last 

accessed February 15, 2023. 

Jackson, S., B. Gallagher, and D. Dorgan. n.d. 2022. “System Maintenance” (web page).

https://www.sebokwiki.org/wiki/System_Maintenance, last accessed February 15, 2023. 

Lukasik, D., B. Churchill, J. Golob, T. Malone, and E. Hubbard. 2011. Assessment of Emerging 

Opportunities for Real-Time, Multimodal Decision Support Systems in Transportation 

Operations. Washington, DC: USDOT. 

Marbach, P. 2016. “Introduction to Agile Practices.” INCOSE Insight, July 2014. 

https://www.incose.org/docs/default-source/default-document-library/3---marbach---

introduction-2-agile.pdf?sfvrsn=3bb481c6_0, last accessed February 15, 2023. 

Margiotta, R., T. Lomax, M. Hallenbeck, S. Turner, A. Skabardonis, C. Ferrell, and B. Eisele. 

2007. Guide to Effective Freeway Performance Measurement: Final Report and 

Guidebook. Web-Only Document 97. Washington, DC: TRB. 

Marone, O. 2000. “Requirement Traceability: A Tool for Quality Results.” Presented at the 

Project Management Institute® Annual Seminars & Symposium. Newtown Square, PA: 

Project Management Institute.
132 

Miller, K., J. Horner, J. Adler, and R. Sanchez. 2021. Decision Support for Traffic Management 

Systems—Current Practices. Report No. FHWA-HRT-21-108. Washington, DC: FHWA.

Mitchell, T. 2017. Chapter 3: Generative and Discriminative Classifiers: Naïve Bayes and 

Logistic Regression.” Machine Learning. New York, NY: McGraw Hill. 

https://www.cs.cmu.edu/~tom/mlbook/NBayesLogReg.pdf, last accessed March 23, 

2023. 

McTrans Center. 2022. Highway Capacity SoftwareTM. Release 8.1. University of Florida 

Transportation Institute, Gainesville, FL. 

Myers, A. 2018. “The Australian Approach and Architecture for Decision Support Subsystems.” 

Presented at the 97th Annual Meeting of the Transportation Research Board. 

Washington, DC: TRB. 

National Academies of Sciences, Engineering, and Medicine. 2022. Evaluating Alternative 

Operational Strategies To Improve Travel Time Reliability. Strategic Highway Research 

Program Report S2-L11-RR-1. Washington, DC: The National Academies Press. 

https://www.trb.org/Main/Blurbs/168142.aspx, last accessed February 15, 2023. 

National Archives eCFR. CFR Title 23, Chapter 1, Subchapter K, Part 940.11, Subpart A, 

§ 940.11. 2022. https://www.ecfr.gov/current/title-23/chapter-I/subchapter-K/part940/section-940.11, last accessed February 15, 2023. 

National Archives eCFR. CFR Title 49, Subpart A, §18. 2023. 

https://www.ecfr.gov/current/title-49, last accessed February 21, 2023. 

National Operations Center of Excellence. 2018. “Decision Support Subsystem Requirements for 

the Next Generation Traffic Management Systems and Centers (TMCs).” Workshop held 

at the 97th Annual Meeting of the Transportation Research Board. Washington, DC: 

TRB. https://transportationops.org/publications/decision-support-subsystemrequirements-next-generation-traffic-management-systems-and, last accessed February 

15, 2023. 

NOAA. 2018. “Needs Assessment Guide: Overview” (web page). 

https://coast.noaa.gov/needsassessment/#/, last accessed February 15, 2023. 

Park, Byungkyu (Brian). 2005. Transportation Management System Performance Monitoring, 

Evaluation, and Reporting—A Technical Handbook. Report No. FHWA-HOP-07-124. 

Washington, DC: FHWA. 

Robinson, E., M. Motamed, D. Newton, K. Olyai, and L. Bedsole. 2017. Elements of Business 

Rules and Decision Support Systems Within Integrated Corridor Management: 

Understanding the Intersection of These Three Components. Report No. 

FHWA-HOP-17-027. Washington, DC: FHWA. 
133 

Sloboden, J., J. Lewis, V. Alexiadis, Y. Chiu, and E. Nava. 2012. Traffic Analysis Toolbox 

Volume XIV: Guidebook on the Utilization of Dynamic Traffic Assignment in Modeling. 

Report No. FHWA-HOP-13-015. Washington, DC: FHWA. 

Scrum Alliance®. n.d. “What Is Scrum?” (website). https://www.scrumalliance.org/learn-aboutscrum, last accessed November 7, 2022. 

Simon, H. 1955. “A Behavioral Model of Rational Choice.” The Quarterly Journal of Economics 

69, no. 1 (1955): 99–118. 

Smith, B. 2003. Configuration Management for Transportation Management Systems. Report 

No. FHWA-OP-04-013. Washington, DC: FHWA. 

Staples, B., D. Hardesty, B. Christie, T. Deurbrock, J. Seder, M. Insignares, and P. Chan. 2017. 

Applying Scrum Methods to ITS Projects. Report No. FHWA-JPO-17-508. Washington, 

DC: FHWA. https://rosap.ntl.bts.gov/view/dot/32681/dot_32681_DS1.pdf, last accessed 

February 15, 2023. 

Tavasszy, L., B. Smeenk, and C. Ruijgrok. 1998. “A DSS for Modelling Logistic Chains in 

Freight Transportation.” International Transactions in Operational Research 5, no. 6 

(1998): 447–459. 

TRB Freeway Operations (ACP20). 2018. “Sponsored Workshops & Sessions.” Presented at the 

TRB Annual Meeting. Washington, DC: TRB. 

https://sites.google.com/view/trbfreewayops-acp20/meetings/annual-meetings/2018, last 

accessed February 15, 2023. 

TRB. 2016. Highway Capacity Manual, Sixth Edition: A Guide for Multimodal Mobility 

Analysis. Washington, DC: National Academy of Sciences. 

Van Duren, D., R. Rausch, and D. Benevelli. 2017. Connected Vehicle Pilot Deployment 

Program Phase 2, Data Management Plan. Report No. FHWA-JPO-17-454. 

Washington, DC: FHWA. https://rosap.ntl.bts.gov/view/dot/35363, last accessed 

February 15, 2023. 
HRDO-20/07-23(WEB)E Recycled

Recyclable

Recommended citation: Federal Highway Administration,

Decision Support Methods and Tools for Traffic Management Systems 

(Washington, DC: 2023) https://doi.org/10.21949/1521376