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

  • Project Background
  • Live Demonstration of IBS/TODSS
  • Transit Business Rules Configuration
  • Results and Lessons Learned

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.]

  • 9 Operating Divisions
  • Small and large divisions from 30 to 200+ vehicles
  • Transit Bus, Van Pool, ADA Service
  • Serves 6 county Chicago Metropolitan area with over 240 fixed routes
  • Total ridership in 2008 over 45 million
  • Service area population 5.2 million

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

  • Pace and FTA defined the Project Plan
  • Pace and Continental entered into contract that included the Statement of Work
    • This was difficult process due to all parties unfamiliar with mechanics of an R&D project
  • Pace Developed Concept of Operations and Local Requirements for TODSS Operational Scenarios
    • A series of Team TODSS meetings identified the needs and operational requirements
  • Continental developed Detailed Requirements and System Architecture
    • April 08 through Sep 08
  • System Development and Testing
    • July 2008 through February 2009
  • Implementation and Operational Test Period
    • Went live March 3, 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

  • Project Background
  • Live Demonstration of IBS/TODSS
  • Transit Business Rules Configuration
  • Results and Lessons Learned

Slide 9:  Agenda

  • Project Background
  • Live Demonstration of IBS/TODSS
  • Transit Business Rules Configuration
  • Results and Lessons Learned

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.]

  • Team TODSS process to configure TODSS
    • Decide what incidents dispatchers must actively manage and provide oversight
    • Decide what triggers each incident
    • Build an Action Plan(s) to assign to each incident
    • Build a Research List to assign to each incident
  • Create a set of Action Items that could be re-used wherever possible
  • Create a set of Research Lists and Action Plans that could be re-used wherever possible
  • Pace re-defined the driver initiated (canned) data messaging to improve safety and fit within the TODSS concept

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.]

  • Multiple Action Plans can be assigned to an incident for dispatcher options within TODSS
  • Through IDS Administration individual rules can be enabled/disabled in real-time
  • Complete sets of rules centered around specific operational scenarios can be created and saved and loaded when needed
    • Special Events
    • Emergency Operations
    • Weather Disruptions
  • Or Work Assignment Roles can be configured for specific operational scenarios

Slide 19:  Agenda

  • Project Background
  • Live Demonstration of IBS/TODSS
  • Transit Business Rules Configuration
  • Results and Lessons Learned

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.]

  • I have time to explore all the TransitMaster information provided by IBS (↑ significantly)
  • I know where to go to get the information I'm looking for (↑ significantly)
  • I know how to easily access related information (↑ significantly)
  • When I need information it is often hard to find in IBS (↓ significantly).

Slide 22:  Lessons Learned

  • Integrated internet and email capabilities provide immediate internal and external operations communications, where management and line staff become more directly informed and involved in the day-to-day operations
  • Training for system administrators, dispatchers, and operators is critical to sustain the TODSS effort
  • Color coding of priority and unique audible cues are relied on by dispatcher more than was initially understood
  • Required restoration strategies, through action plans, result in a more uniform response within and throughout the divisions
  • Setup of TODSS is much easier when an agency has a theory of service management articulated in defined standard operating procedures
  • Incident reporting was duplicating other dispatcher actions and was not needed as much as it was previously

Slides 23–24:  Development — Keys to success

  • Commitment to project by key stakeholders
    • Resources
    • Time
  • Joint cooperation and participation
    • Visits
    • Meetings
  • Structured product life cycle
    • Requirement capture
    • Needs analysis
    • Roles/Responsibilities
  • Experienced Team Members
    • Subject matter experts
    • Effective communication/speaking "Transit Language"

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

RITA's privacy policies and procedures do not necessarily apply to external web sites.
We suggest contacting these sites directly for information on their data collection and distribution policies.