1. 1 Transit Operations Decision Support Systems Development of Core Requirements For Identification of Service Disruptions and Recommendations for Service Restoration James A. Bunch, Senior Principal ITS and Planning Mitretek Systems ITS Forum APTA EXPO 2002 September 22, 2002 Las Vegas, Nevada

2. 2 Overview Project History and Timeline What Decision Support Means Project Goals and Objectives Summary of Results Planned Activities and Deliverables

3. 3 Project History and Milestones 1998 19992000 2001 2002 Fleet Operations Workshop for FTA 5 Year R&T Plan Identifies Need 2003 Project Developed and budgeted Transit Agency Interviews (Volpe TSC) Transit Agency Workshop 1/08/01 Draft Workshop Report (Volpe TSC) 3/01 Initial Vendor Interviews (Volpe TSC) Re-Focus Project to Real Time Ops Initial Investigation/project scoping Vendor Workshop 9/25/01 Joint Workshop 3/02 Core Specifications Final Scoping, Phasing, Procurement Options Volpe Mitretek Education & Training R&D Pilot Implementation 2004 Remaining Funds $555K $ From JPO Program Support $ From Remaining Funds $ From FY 03 Budget $800k from FY 98 – FY 00 budgets $480k transferred to Volpe

4. 4 What Are Decision Support Tools? The use of advanced technologies for data collection and analysis to assist decision makers identify options, predict and evaluate their impacts, and make informed choices. Project need was first identified during December 1997 Fleet Operations Workshop as: –Real Time Operations Decision Support in response to workshop statement: "Dispatchers do not have time to digest huge quantities of data for decision making in a normal operating environment”. Dispatchers and field supervisors managing medium and large transit fleets need tools accessing real-time data to help: –make decisions to resolve operational issues before they become problems –manage problems or incidents as they arise –restore service with minimal disruption to the transit system.

5. 5 Overall Project Goals and Objectives Determine perspectives on Needs and Gaps for Decision Support Tools to Assist Dispatchers –Transit Agencies –Vendors (software and hardware) Resolve differences in perspectives and Identify true gaps along with ways to address both: Gap inApproach –Perceptions of capabilitiesEducation –Software algorithms/analysisTool Development –Design or interfaceHuman Factors –Procurement ProcessEducation/Clarification

6. 6 Summary of Workshop Findings Transit Agencies Operations Needs –Headway based service support –Schedule based service support (already exists) –Incident/emergency event support –Connection protection –Real-time requests for transfer connections –Variable thresholds for notices/alarms –Early warning signs and impacts of actions –Provision of recommended actions –Prioritization of problems and solutions (Volpe, Jan, 01)

7. 7 Summary of Workshop Findings Transit Agencies System Needs/Issues –System wide impact analysis –Two-way communication between vehicles, supervisors, and management center –Projection of emerging problems and response –Integration of system with other modes and ITS components –Understandable display of information (human factors) –User defined reports and data screens –Use of standards, open architecture, and data definitions –Modular, incremental implementation of functionality (Volpe, Jan, 01)

8. 8 Summary of Workshop Findings Vendors Procurement process and RFPs can be improved –Low bid is not always the best approach –Limit customization and unnecessary functions –Recommend modular, phased implementation Some needs are currently provided by operations management systems System customization and maintenance of modifications is costly and hampers new improvements. Need a “Core” system that meets most important agency needs Identification and response to service disruptions is an area likely to have a large percentage of core functions (Mitretek, Sept, 01)

9. 9 Summary of Workshop Findings Joint Transit Agency/Vendor Develop/refine "Core" system for identification of service disruptions and provision of service restoration recommendations requirements. –The service disruption and restoration scenarios –The functional requirements, or specifications, of a Core system(s) –The examination of the legal issues Outreach and training needs for TODSS, and definition of program to address them. –Industry wide "awareness" and general knowledge level, –Site Specific / Vendor requirements –Procurement and specifications –Information exchange (User Groups, Websites, etc.) Using a Working Group for development in each area, and Overall Advisory Panel for review (Mitretek, March ‘02)

10. 10 Working Group Participants Service Disruptions and Restoration Strategies Transit Agencies –New Jersey Transit –New York City –Boston –Seattle –Montgomery Co. Maryland Vendors –Orbital TMS –Init Systems –Siemens –ATC-NEC (Multisystems) –SchulumbergerSema –Clever Devices

11. 11 Defining the “Core” Event/Condition Identify Disruption Service Restoration Strategies Service Characteristics Service Standards and Policies Surveillance (inputs) Surveillance (inputs) Surveillance (inputs) What Service Characteristics, Standards, & Policies? What Potential Disruptions (and inputs)? What Potential Service Restoration Strategies?

12. 12 Defining the “Core” Potential Disruptions Restoration Scenarios (characteristics, standards& policies) Service Restoration Strategies Scenario 1 Common Needs Service Restoration Scenario n Complex System Service Restoration Unusual Characteristics Uncommon Disruptions Custom Features Other Functions

13. System Sophistication & “Intelligence” Computation Decision Support and Control Display/ Notification Recommended Solutions Automation Data Analysis Imputation Expert Systems Error Checks Pattern Recog. Pre-Defined Solutions Prediction Network Analysis Prediction Optimization Impact Propagation Current Capabilities Future Integrated “Intelligent” System Management Identified Near Term Needs Core ?

14. 14 Proposed Terms Event – Unusual occurrence or condition (internal or external to transit) Incident – An event that requires action by the transit agency Service Disruption – Incident where service provision falls outside agency service standards and policies Threshold – Value of input that triggers an action. Can be set at different decision points (e.g. detection, tracking, display, action, and reporting) Restoration Scenario - combination of service type, incident/service disruption, and conditions that identify appropriate restoration strategy (ies)

15. 15 Service Standards & Policies Frequency of Service –Scheduled Tripper Time point = 0<Scheduled time<? min –Schedule Based Time point = 0<Scheduled time<? min –Headway Based Headway = Scheduled Headway +/- ? min –Load Based Depart when vehicle at X% max. load Loading –Seated –Seated plus max standing –Special (e.g. E&H, Bike) Connection Protection –None –Scheduled –Single hold –Pulse (double hold) –By request Operating Rules & Org. –Extra-Board and Work Rules –Centralized Control –Distributed Functions to Supervisors –Distributed Functions to Operators –Share data between agencies/modes –Share Control between agencies /modes

16. 16 Analysis Sequence Event/Condition Service Disruption Restoration Scenario Service Characteristics Service Standards and Policies Surveillance (inputs) Surveillance (inputs) Surveillance (inputs) Thresholds Other Inputs ? Analysis (level, impact) Recommended Restoration Strategies Monitor Results of actions Potential Strategies for conditions/service Action

17. 17 Analysis Sequence All Potentially Applicable Restoration strategies for the type of disruption Disruption Other Const. Environment External Events Service Type Restoration Scenario Applicable Restoration strategies Analysis (Actions Impacts) Analysis (Actions Impacts) Analysis (Actions Impacts) Evaluate / Prioritize Recommendations

18. 18 Service Disruptions by Identification Inputs (Revised from 9/04/02) Part 1

19. 19 Service Disruptions by Identification Inputs (Revised from 9/04/02) Part 2

20. 20 Potential Service Restoration Strategies Adjust Travel Time –Selective Hold –Speed Control (along route) –Signal Prioritization –Schedule shift Adjust Travel Time & Passenger Access/Egress –Egress Only –Express along route –Deadhead –Passing –Short Turn Adjust Travel Time, Passenger Access/Egress, Route –Re-Route –Express re-route

21. 21 Potential Service Restoration Strategies (Continued) Additional Driver –Provide driver relief Additional Vehicle –Insert/Replace vehicle From barn From standby location From other in service route From other out of service route –Relay Vehicle From barn From standby location From other route From other out of service route

22. 22 Making the Connections What restoration strategies are potentially applicable for each type service disruption? What scenarios should each potential restoration strategy be used in (type of service, environmental conditions, etc.)? What additional information is needed to classify the service disruption and identify/recommend the restoration strategy (ies) to use? Disruption Restoration Scenario Potential Restoration Strategies for Disruption Candidates Conditions 1 Conditions 2

23. 23 Other “Core” Considerations System sophistication and “intelligence” –Prioritization –Impact propagation –Prediction Communications –MDT, voice, one way, two way Control –distributed vs. centralized Modular Standard interface ? –Service representation –“Event” notification

24. 24 Project Time Line Next Steps

25. 25 Collaboration Web Site Find Out More And Participate In The Project at: http://mitretek.infopop.cc/6/ubb.x

26. 26 Additional Contacts Contacts for Participation, Questions, or Additional Comments –Sean Ricketson, Federal Transit Administration 202-366-6678, Sean.Ricketson@fta.dot.gov –Jim Bunch, Mitretek Systems 202-863-2984, jabunch@mitretek.org –Gwo-Wei Torng, Mitretek Systems 202-488-5714, Gwo-Wei.Torng@mitretek.org –Yehuda Gross, FHWA ITS Joint Program Office 202-366-1988, Yehuda.Gross@fhwa.dot.gov