Integrated Corridor Management (ICM) Program: Major Achievements, Key Findings, and Outlook

Appendix A. Decision Support Systems

ICM could not exist absent the recent advent (a decade or so) of "big data," or, extremely large data sets that may be analyzed computationally to reveal patterns, trends, and associations, especially relating to human behavior and interactions. Big data is often characterized by the 3Vs: the extreme volume of data, the wide variety of data types and the velocity at which the data must be processed. Based on those criteria, the DSS will recommend a response plan and communicate it to network operators for review and approval. The ultimate goal of an ICM automated system would be to have the DSS assess corridor needs and independently implement plans to the benefit of corridor operations.

Decision Support Systems (DSS) exist in research libraries, water, sewer and electrical grids, in medicine, and in financial and military communities, etc., to not only aggregate huge lists of data, but more importantly, to assist humans in creating computer-speed analysis, alternatives, and decision making. DSS is a key component of an ICMS. The ICM DSS basically involves the collection of data and information describing the corridor or portions of the corridor that are experiencing disruptions in traffic flow. Based on the information collected and analyzed, it develops real-time response plans, and communicates them among corridor partners, and then implements them to help mitigate the traffic flow disruptions.

Like any other system, the DSS can be implemented using a range of solutions. To save time and money an initial DSS implementation may very well be a solution that leverages human resources. This appears to be an increasingly popular first phase for DSS implementation. Human network operators within the corridor work to develop ICM response plans based on their experience within the corridor. The developed response plans may or may not benefit each network operator and they are free to implement the plans based on their own needs and projected benefits.

With time, corridor partners can improve the DSS structure leading toward a more automated system. Corridor data can be collected, stored, and analyzed based on an increasingly more sophisticated set of decision criteria.

DSS Development

The decision support system (DSS) can be thought of as a chess board where the pieces interact and decisions are made. The board itself is the geographical constraint of the ICM region and corridor. The chess pieces can be thought of as the managers, operators, agencies, and organizations (e.g., stakeholders) involved in the ICM corridor; each one having its own special talents but also restrictions; for example, a bishop can move diagonally any number of unimpeded spaces, but a pawn can move only one space forward. However, each are needed to advance the game. ICM business rules are the pre-agreed "chess rules" by which these individuals and agencies (pieces) interact. And like innumerous chess strategies, the DSS contains the ICM strategies to beneficially utilize these rules. In other words, knowing the rules of how the entities interact is not enough, just like knowing the basic rules that govern pieces on a chess board does not make someone a chess champion. Combining these rules within the chess board context in the most beneficial way to succeed is one way of defining strategy.

Developing requirements for a DSS is a logical incremental step in moving forward with an ICM system. It is clear from lessons learned during implementation of DSS in Dallas and San Diego that there is still a lot to be learned from developing a DSS. As each region is different, with different partners, road networks and complementary agencies, there is no "off the shelf" DSS that is one size fits all. Possible approaches include improving an existing DSS engine or developing a new DSS using software in the loop, machine learning, and Artificial Intelligence.

Like shopping at a store, a DSS can pick from previously agreed upon signal timing programs (e.g., a.m versus p.m. versus mid-day, etc.) or dynamic ramp metering programs, or any of pre-programmed DMS messages, et al, to build and select response plans. In San Diego it was estimated that there are well over a million potential combinations of plans, although to be fair, a more concise number of plans were ever considered. This information, along with preferences, restrictions, and guidelines based on incident severity, real time traffic conditions, incident location and other information, is entered into a business rules engine, which is guided by each agency's capabilities or constraints. The rules engine will then suggest response strategies, compared to the "do nothing alternative" for corridor events. These response plans will optionally be evaluated (scored) by running a predictive simulation using a micro model of the corridor. This simulation predicts the resulting benefit on the corridor based on the potential response plan implementation. The best plan is forwarded. The results of this simulation and the basic ordering provided by the rules engine is also used to present an ordered list of response plans for operators to approve or decline. Why might an operator choose to decline his agency's part of the plan? Maybe he or she knows of a competing challenge, like a water main break, or disruption to school loading or unloading, or a localized outage or similar constraint. "Declines" don't happen very often but they remain a failsafe in some cases.

Keys to developing a DSS in a corridor include:

• Establishing a multimodal detour policy (includes transit and pedestrians safely accessing a detoured transit vehicle, for example)
• Addressing data needs:
  • Forming a corridor data policy
  • Forming agreements with third parties and sharing real-time, multimodal construction zone information across agencies (e.g., One regional TSMO Program investment is improving a local agency entry tool for Right-of-Way (ROW) construction that will deploy statewide; a second service is expanding from a Geographic Information System (GIS) layer to an online data service coordinated among several local agencies Multimodal ICM corridor)
• Building corridor partnerships to foster event and demand management

Some of the cited constraints for DSS development¹³ include:

• The DSS will need to consider the traffic rerouting strategies being offered by current mapping systems. The rerouting that they offer creates dynamic traffic patterns that the DSS will need to assess on the fly to make accurate recommendations.
• A DSS may not consider certain jurisdictional rules about what can be communicated to travelers (e.g., some jurisdictions do not allow for direct diversion messages with instructions to be communicated, instead favoring less specific messages). This can have a major impact on the efficiency of a traveler information dissemination strategy recommended by a DSS.
• Many jurisdictions may restrict truck use on certain roads. A DSS that has not incorporated this information and interagency agreements regarding truck traffic would not differentiate the traveler type. A properly calibrated DSS should incorporate this into the recommendation protocol to separate out vehicle travelers from truck traffic in any diversion or messaging suggestion.
• Local jurisdictional constraints may exist on the use of traffic signals and diversions at certain times. For example, in San Diego there were safety concerns about traffic being diverted past schools around school start and end times. These concerns and restrictions are contextual constraints that the DSS should be accounting for when providing recommendations.
• For traveler information posted to DMS, there are often regulations regarding the structure and format of messages. This should be incorporated into the DSS recommendations. Although constraining the message content and structure to conform to local signs and protocol is likely part of the DSS development, additional rules for types of messages and phasing frequency based on traffic speed may be the type of agreed upon use that is not usually incorporated.
• Something as simple as TMC staffing is another area where not all jurisdictions operate in the same way. Recommendations should incorporate whether staff from other facilities are available to coordinate with and if not, is there another representative or agency that can step in?

Ongoing DSS Improvements and Suggested Research

There are several universities and private companies that continue to refine DSS for ICM. Some of the needed improvements noted by ICMS deployment regions include:

• Finding a way to make the DSS plan implementation process more efficient, because agency approvals may be required to confirm DSS plan implementations.
• Considering various ways for DSS to make changes during incidents, for example change from 4-phase to 2-phase signal operation along frontage roads.
• Campaigning for the development of a region-wide program that would set a path for building the ICM infrastructure systems and DSS at a regional level once manual processes have been implemented, practiced, continuously improved, and proof of concept established, within a corridor.
• Writing draft system requirements documents that outline the use of a DSS that deploys specific response plans for select types of events. The plan is to classify each event to varying degrees of severity where a select set of response strategies would be available for implementation. An automated strategy could be as simple as deploying messages that notify travelers of downstream incidents, such as weather-related messages (e.g., "Watch for Ice on the Road") triggered by weather sensors.
• Defining baseline business rules. There is not a one-size fits all proposition when it comes to DSS. All regions have unique needs where DSS is concerned. However, it would be nice to have a baseline set of business rules to improve upon.
• Understanding the benefit of having a shared TMC so many operators are already collocated and can coordinate quickly for human-centric DSS solutions.
• Understanding that heavily automated DSS is not necessary to realize benefits.
• Realizing the role of DSS will evolve over time as operational collaboration around real-world needs helps to define value-added roles for these kinds of tools and systems.
• Recognizing that currently, in this complex multi-agency environment, the emphasis likely needs to be on human-centric strategies while the more experimental DSS are still being tested.
• Understanding that heavily automated DSS strategies need more research and testing before they can effectively advance ICM in a corridor.
• Adding to the Traffic Management Data Dictionary (TMDD) standards for them to meet the ICM and DSS requirements. There is a general need for harmonization of nomenclature.
• Developing guidance is also needed for how and what data can be displayed publicly versus data that is sensitive and could raise security implications.
• Addressing cybersecurity is one of the concerns that needs to be addressed regarding ICM.
• Improving DSS machine learning capacity.
• Achieving full or nearly full DSS automation will include the willingness of the partners to accept progressively automated levels of ICMS.