T3 Webinar Presentation

Clearing the Dispatcher's Queue: Using a Transit Operations Decision Support System (TODSS) to Improve Real-time Incident Response (October 21, 2009)

Presenter:   David Jackson
Presenter's Org:   Booz Allen Hamilton

HTML version of the presentation
Image descriptions are contained in brackets. [ ]
Back to Webinar Files

T3 Webinars are brought to you by the ITS Professional Capacity Building Program (ITS PCB) at the U.S. Department of Transportation's (USDOT) ITS Joint Program Office, Research and Innovative Technology Administration (RITA)

Slide 1:  TODSS T3 Webinar

Transit Operations Decision Support System Demonstration Overview
Booz Allen Hamilton

[Logos appear for: Regional Transportation Authority, U.S. Department of Transportation, Continental, and Pace.]

Slide 2:  Agenda

Slide 3:  Pace operating and service characteristics are representative of the transit industry and serves as a good demonstration site

[This slide contains a map of Pace's operating and service areas in Illinois. There are nine operating divisions, 30 to 200 plus vehicles, transit buses, van pools, and ADA services are available, service covers six county Chicago Metropolitan areas with 240 plus fixed routes, 2008 ridership was 45 million, and service area population is 5.2 million.]

Slide 4:  The Project Started 4/06 and the Operational Test Ended 5/2009

Slide 5:  The approach to the pilot was to build the TODSS engine beside the CAD/AVL system using the Decision support engine as the interface

[This slide contains a diagram that demonstrates how the pilot TODSS engine was built. The TODSS engine was built alongside the existing CAD/AVL system or PACE IBS by adding the decision support system and configuration tools to create a new user interface. The TODSS prototype was an augmentation to existing CAD system.]

Slide 6:  All inputs, from all available sources of information, are evaluated, prioritized, and potential restoration actions provided to Pace dispatchers

[This slide contains a diagram that demonstrates how the pilot TODSS engine was built in block format. The left side of the diagram demonstrates how in additional to IBS events, external events and dispatcher events can now be entered into the system to generate a research list, action plan, and incident details, which are located on right side of the diagram and called Incident Queue.]

The cost of developing the IDS prototype including the design, build, and evaluation was a fraction of the cost of a CAD/AVL procurement.

Slide 7:  Pre-TODSS Incident Queue

[This slide contains a screenshot of TransitMaster Operations software that demonstrates an incident queue prior to TODSS. The left side of the screen demonstrates tabular pages with reference information. The right side of the screen shows the four different message categories such as Emergency Messages, Talk Requests, Adherence Messages, and Other Messages.]

Slide 8:  Agenda

Slide 9:  Agenda

Slide 10:  Team TODSS provided the input to implement the set of business rules used for the TODSS Operational Test that lasted 60 days

[This slide contains a screenshot of TODSS software that demonstrates the different types of business rules such as incident configurations, incident audits, work assignments, and other rules.]

Slide 11:  Business rules mean: Different parameters for different situations

[This slide contains a map of the types of the different kinds of service offered in a PACE service area. BRT routes, express routes, and local routes require different sets of business rules.]

Slide 12:  Configuration of a BRT adherence incident trigger for morning peak, in revenue, on course and with working AVL equipment

[This slide contains a screenshot of TODSS software that displays a configuration of a BRT adherence incident trigger for morning peak, in revenue, on course and with working AVL equipment.]

Slide 13:  External sources of information now included in the CAD system

[This slide contains a screenshot of Traffic.com to the right. Traffic.com provides an RSS feed of traffic conditions along arterial routes and interstate highways. The RSS feed can be entered into the TODSS application as an incident and can be generated as an incident in the incident queue. The map from Traffic.com can be displayed in TODSS with an active link back to Traffic.com, which is shown on the left side of the slide.]

Slide 14:  End result is an IDS message in CAD from the Internet

[This slide contains screenshots of TODSS software. The smaller screenshot in the bottom left forefront of the slide demonstrates the incoming RSS feed from Traffic.com. The larger screenshot in the background demonstrates how the external traffic message from Traffic.com is now a part of the TODSS system in the incident queue.]

Slide 15:  Using the graphical programming tool the trigger is built for the traffic congestion incident

[This slide contains a screenshot of TODSS software that helps build incident trigger conditions using parameters and values from the event called "Feed Info" in a TODSS system.]

Slide 16:  Work Assignment Roles provide real-time information to user groups based on fleets, garages, vehicles, routes, or regions

[This slide contains a screenshot of TODSS software that demonstrates work assignment roles of dispatchers, maintenance, management, road supervisors, and electronic technicians. The software provides real-time information to these user groups based on fleets, garages, vehicles, routes, or regions.]

Slide 17:  Combined with NT groups, system administrators, maintenance, supervisors, and others can have their own real-time environment defined

[This slide contains a screenshot of TODSS software and a Blackberry phone displaying real-time incidents. Implementing TODSS on a Blackberry allows various user groups to manage service in real-time.]

Slide 18:  Several techniques are available to provide options and handle unusual operational scenarios

[This slide contains a list of several techniques available via TODSS to provide options to handle unpredicted operational events. These techniques include Multiple Action Plans, using IDS Administration to enable/disable rules in real-time, creating sets of rules to address specific operational scenarios, and configuring Work Assignment Roles for special operational scenarios. The slide contains a screenshot of TODSS software that displays the rules for certain action plans.]

Slide 19:  Agenda

Slide 20:  Project data shows IDS had the desired effect of managing the flow of information and better use of the system by dispatchers

[This slide contains a picture of a table that displays the effectiveness of TODSS by demonstrating statistics pre- and post- TODSS. The data used to measure the effectiveness are the Number of Data Messages Displayed to Dispatchers (down 60%), Voice Communications between Drivers and Dispatcher (down 30%), Average RTT Response Time (increased by 2 seconds), Standard Deviation of RTT Response Time, Incident Reports (decreased 36%), and Drivers Use of Canned Messages (increased 7%).]

Statistic Pre-TODSS TODSS
# Data Messages displayed to dispatchers down over 60% 7,927 (without adherence warnings) 2,515 (including adherence warnings
Dramatic decline (30%) in voice communications between drivers and dispatchers ˜14,000 ˜10,000
RTT Response Time Average (hmm ...) 86 sec 88 sec
RTT Response Time Standard Deviation (but ...) 253 sec 171 sec
Incident reports decreased 36% due to automated email notifications 1417 907
Drivers use of canned messages increased 7% (there was a 2/3 reduction in available canned messages) 12,286 13,187

Slide 21:  Before and after comparisons from the project evaluation survey, demonstrate TODSS impact on Dispatcher's attitudes

[This slide contains two pictures of dispatchers. The picture on the left contains a woman using one monitor to dispatch while the picture on the right demonstrates a man using several monitors and software to perform his dispatching duties.]

Slide 22:  Lessons Learned

Slides 23–24:  Development — Keys to success

Slide 25:  Next Steps

  1. Promote TODSS Knowledge and Experience through Stakeholder Outreach
  2. Revise and release TODSS Core Requirements based on prototype findings and recommended changes
  3. Develop "how-to" guide on planning, procuring, and implementing TODSS
  4. Seek Integration of TODSS with Other ITS Efforts, such as ICM
  5. Develop a business case for TODSS

Slide 26:  Contact information for today's presenters

John Braband
Pace Suburban Bus

Bill Hiller
Logged On Transit

Steve Mortensen FTA Office of Research, Demonstration & Innovation steven.mortensen@dot.gov

Yehuda Gross
ITS Joint Program Office

David Jackson
Booz Allen Hamilton

Dan Spinks
Continental Corporation

back to top