To: Faisal Saleem, MCDOT James Book, RPTA Technical Memo From: HDR Engineering & Oz Engineering Project: AZTech TM Transit Data Integration Concepts of Operation CC: Tomas Guerra Saroja Devarakonda, File Date: July 29, 2009 Job No: 105240 Jurisdictions within the Maricopa County region have continually demonstrated the benefits of multi-agency coordination. AZTech is a regional partnership of private and public agencies working together to integrate intelligent communication and transportation systems technologies. AZTech s mission is to: Integrate existing ITS infrastructure into a regional system Establish an integrated traveler information system Expand the transportation management system for the Phoenix metropolitan area Real-time transportation data can offer the traveling public an enhanced decision-based travel tool that can produce individual and community benefits like travel time savings, traveler safety and increased traveler confidence. Integration of available real-time transit data with the AZTech Regional Archive Data Server (RADS) can help enhance the efficiency of the region s multi-modal transportation system. The Regional Public Transportation Authority/Valley Metro (RPTA), in partnership with Maricopa County Department of Transportation (MCDOT), has initiated this Concept of Operations Plan to understand existing transit operations, integrate transit data with RADS, and to develop potential ATIS applications and services. The goal of this plan is to provide: 1. Improved transit operations; 2. Improved transportation data to the public. Figure 1: Simplified Example of Integrating Real-time Transit Data with RADS Authorized Users Valley Metro Real-Time Transit Data RADS Transportation Data to Public 1
The purpose of the Concept of Operations Plan is to identify in detail the following: 1. Availability of real-time transit data attributes 2. Potential ATIS applications/services 3. Hardware and software requirements 4. Requirements for on-going public agency staff support 5. Initial and on-going costs 6. Funding opportunities to deploy potential integration, and Oz Engineering, under the oversight of MCDOT, conducted meetings with staff from the City of Phoenix Public Transit Department, RPTA and METRO Light Rail to understand the existing transit data collection and operational procedures. In addition, a tour of the regional bus and rail Operations Control Centers (OCC) was undertaken to better understand the availability and use of existing technology resources. This memo summarizes the initial research of the existing systems, and potential concepts for Advanced Traveler Information Systems (ATIS) applications/services that can be developed utilizing real-time transit data integrated with other real-time data sources (i.e. highway performance, etc.). Existing Systems Regional Archive Data Server (RADS) RADS provides a source of consolidated regional data (real-time and archived) including freeway and arterial traffic volumes, lane occupancy, lane speed, incident data and travel time. RADS servers are located in the ADOT Traffic Operations Center (TOC). MCDOT maintains the system on behalf of the AZTech partners. Figure 2: Regional Archive Data Server TMS EMS FMS RADS POTENTIAL Valley Metro TRANSIT/ Valley Metro LIGHT RAIL HCRS The following data elements are currently available within the RADS and could be used to improve transit operations and provide real-time information to the public. 1. City of Phoenix Fire Department incident response details. Real-time alerts originating at the Phoenix Fire Department dispatch center automatically notify where an emergency response 2
vehicle has been dispatched to. These alerts are active until the vehicle has cleared the scene. More than 2,000 events are generated in a typical month by this Emergency Management System (EMS). 2. The Arizona Department of Transportation (ADOT) Highway Condition Reporting System (HCRS) provides real-time alerts detailing incidents, closures and construction occurring on freeways and surface streets. Over 4,000 events are typically generated statewide per month. 3. The ADOT Freeway Management System (FMS) collects freeway speeds from the HOV and mainline lanes in portions of the Phoenix metropolitan area. This information arrives every 20 seconds, and is used to calculate travel time estimates. Historical values going back to 2005 are available. 4. The Traffic Management System (TMS) Center-to-Center (C2C) project is currently collecting traffic signal timing plan details from numerous metropolitan area municipalities. The signal timing plans are incorporated into RADS. This Concept of Operations Plan will determine if the following transit system data elements could be incorporated into RADS for use by local transit providers and transit passengers. 1. Notification of bus and light-rail (LRT) service changes or service disruptions at the systemwide and route-specific level. 2. Bus schedules and real-time next bus arrival details. 3. Light-rail train schedules and real-time arrival details. Valley Metro Light Rail Management System (VMLRMS) The VMLRMS uses a General Electric (GE) developed proprietary Train Tracking System (TTS) to manage light rail operations. Presently VMLRMS controls up to 17 multi-car trains during peak hours. The Light Rail Train Vehicle (LRTV) communicates with the TTS via an FCC licensed data radio. The Control Center may communicate with LRTV operators via voice radio or text messaging. The TTS pulls data from all scheduled LRTVs every 15 seconds. Presently, TTS cannot pull data from unscheduled trains (serving special events or emergency events). In-vehicle equipment enables the LRTV to transmit latitude/ longitude (GPS coordinates), train ID, vehicle ID, route ID and operating speed data. In addition, the data can be processed to provide next train information from TTS that will be sent to the Next Train Announcement System (NTAS). The NTAS shall provide audio and visual information via Dynamic Message Signs (DMS) located at LRT stations. The NTAS full implementation is expected by mid-summer 2009. 3
Figure 3: Light Rail Train Tracking System Regional Vehicle Management System (VMS) The City of Phoenix and regional partners deployed the Orbital Transit Vehicle Management System (VMS) earlier this decade to provide real-time bus monitoring. The VMS tracks late, on-time, and early buses as well as vehicle location, speed, route adherence and other variables. The system presently manages approximately 790 regional buses, of which approximately 400 are City of Phoenix vehicles. Data and voice transmissions between transit vehicles and VMS control servers is handled through wireless radio communications. Figure 4 provides schematic view of the Regional VMS architecture. Figure 4: Regional VMS Architecture 4
Existing Regional VMS Advanced Traveler Information Systems (ATIS) Components Data generated by the VMS is currently provided for use in two ATIS applications: Trapeze Trip Planner System and Phoenix RAPID Passenger Information Signs. The real-time VMS data for all bus routes is sent (pushed) to the Trapeze Trip Planner System for the customer service frontend to provide call-in customers with real-time next bus information. The data is sent every 20 seconds in a comma separated flat file format (<6Kb). This data contains any changes in vehicle location that occurred in the prior 20 seconds. The Phoenix RAPID Passenger Information Signs relies on the VMS Real-Time Database Server to calculate next bus arrival times at every Time Point (TP). This data is sent to the ATIS DMS server to process and disseminate next bus information to 20 ATIS signs located in the downtown Phoenix area and at City of Phoenix park-and-ride facilities. Each ATIS sign receives and displays real-time next bus arrival information for RAPID buses over CDMA (Cell phone connection). Finally, the VMS provides for short term and long term data retention. Data from buses are stored for seven days in the Real-Time Database Server; however, after seven days the data are replicated to an Archive Server for storage up to 90 additional days. Figure 5: Vehicle Management System 5
The VMS relies on data provided by the HASTUS Scheduling software to create schedule information necessary for identifying on-time performance in real-time. Major changes to the bus schedule and Time Points (TP) occur in January/July and minor changes occur in April/September. To generate accurate on-time performance and route compliance (vehicle off-route) data events, the HASTUS data files must be regularly updated in the VMS. Computer-Aided-Dispatch (CAD) components of the VMS enables communications with transit vehicles. Automated Vehicle Location (AVL) data is transmitted (data pull) to the VMS central data servers via an FCC licensed data radio at least every two minutes, or when a bus opens its doors or passes a TP. An AVL-stamp contains the date/time, latitude/longitude, route number, trip number, and route direction. Revenue miles data is also collected. A vehicle may store up to 90 days of data locally. VMS is a dedicated system that has 8 servers: Data Communication Controller (DCC) Server - 2 Servers Real Time Database Application Server - 1 Server 6
Potential ATIS Applications/Services The integration of real-time transit and light-rail data with regional freeway and arterial traffic data, incidents, and vehicular travel time data provides opportunities to better serve regional transportation needs. Based on the below listed input from City of Phoenix Public Transit Department, Valley Metro/Regional Public Transportation Authority and MCDOT the following concepts for integrating real-time transportation data are envisioned. 1. System-wide and route specific service changes or bus/train disruptions 2. Scheduled and actual next bus arrival 3. Scheduled and actual next light rail train arrival 4. Fire incidents occurring within range of light rail train and bus routes 5. Major incidents and road closures within range of light rail train and bus routes 6. Freeway speed and travel time estimates Concept 1: Incident Impact Alert Using the incident and major road closure details available from the Phoenix Fire Department and ADOT HCRS, the RADS would automatically notify the call center operations when a Transit or LRT route is impacted. 1. The system would be configurable to specify the severity level of the incident or closure that should be considered. 2. The list of Transit routes, intersections and LRT locations that should be considered for notification would be configurable. 3. Notification alerts would be available via telephone text message, email or pop-up on computer screen to a configurable list of clients. Figure 6: Sample Incident Impact Alert Concept 2: Freeway Travel Time Alert Using the HOV and mainline freeway speeds available from the ADOT FMS, the RADS would automatically notify the call center operations when a RAPID or Express route is adversely impacted. 1. The system would be configurable to specify the amount of deviation between current and historical travel times that should be considered. 2. The list of RAPID or Express routes that should be considered for notification would be configurable. 3. Notification alerts would be available via telephone text message, email or pop-up on computer screen to a configurable list of clients. 7
Figure 7: Sample Freeway Travel Time Alert Concept 3: Public Internet and Mobile Website The public would access a real-time website through the Internet. The website would also provide access by means of a mobile telephone. 1. The following data elements would be represented in the website: a. Real-time location of buses and LRT trains, including routes b. Phoenix fire incidents, c. Major traffic incidents and road closures, d. Freeway speed colors, e. Incident and Travel Time Alerts. 2. At the top level, the user would be presented with a map from which they could select one of nine regions: a. Northwest Valley b. North Phoenix c. Northeast Valley d. West Valley e. Phoenix f. East Valley g. Southwest Valley h. South Phoenix i. Southeast Phoenix Figure 8: Public Internet Website Entry Screen A B C D E F G H I 8
3. After selecting a region, the user would be able to select one of the major intersections. This list of intersections may include the airport and other major travel destinations: Figure 9: User May Select an Intersection 4. Once the intersection is selected, the one-hour transit status would display: a. System-wide or route-specific rider alerts, including pre-recorded messages. b. Scheduled and estimated next departure time for the transit and LRT trains at the selected intersection. The timeframe shown would correspond to the preceding five minutes up to the next one hour. c. Accidents and road closure details would be shown. Figure 10: Intersection Details: One-hour Transit Status 9
5. An equivalent set of Internet screens would be available for those public users accessing the website through a telephone. At the top level, the user would select one of nine regions. Figure 11: Public Mobile Phone Entry Screen 6. Then they would select an intersection. Figure 12: User May Select an Intersection 10
7. The one-hour intersection transit status would display: Figure 13: Intersection Details One-hour Transit Status Concept 4: Valley Metro Members Authorized Real-time Map Authorized members of Valley Metro would access a real-time website through the Internet. 1. Icons would be used to represent the: a. Real-time location of buses and LRT trains, b. Phoenix fire incidents, c. Major traffic incidents and road closures, d. Freeway speed colors, e. Incident, Travel Time and other Alerts. 2. At the top-level, authorized users would log in and zoom in on a desired region. Figure 14: Valley Metro Authorized User Screen 11
3. Clickable icons would provide item details. Figure 15: Valley Metro Clickable Icon Details Concept 5: Park-N-Ride Large-Screen Monitor Display Large-screen view-only displays would be installed at a Park-N-Ride (PNR) facility. 1. The real-time details for the area surrounding the PNR facility would be displayed, including: Real-time location of buses and LRT trains, including routes show graphically Freeway speed colors shown Major fire and traffic incidents and travel time alerts, would appear as scrolling text Next train and bus details would be shown as scrolling text Bike lane routes would be displayed Figure 16: Park-N-Ride Large-Screen Monitor Display 12
2. Initial pilot deployment could be at the following locations: a. 19 th Avenue and Montebello PNR b. Chandler Transit Center Concept 6: Connection Protection Alert Using the bus and LRT train schedules and real-time location details, RADS would automatically notify the call center operations when a critical LRT to bus connection may be protected. One specific example would be if the last bus of the day is scheduled to leave an LRT facility, but the train is running a few minutes late, a notification could protect those passengers who are to be on that last bus. 1. The system would be configurable so that only off-street or Park-N-Ride (PNR) buses close to LRT routes would be considered. 2. The system would operate only during AM and PM peak hours. 3. Only hold buses that connect to a PNR or LRT. 4. Don t hold LRT trains or express buses. 5. Hold or dwell the bus for no more than five (5) minutes. 6. Notification alerts would be available via telephone text message, email or pop-up on computer screen to a configurable list of clients. Figure 17: Sample Connection Protection Alert 13
Definition of Terms used in this Report HASTUS Scheduler: A Software application used to create regional transit schedules. This system feeds numerous secondary applications including dispatch, payroll, trip planning (next bus schedule), passenger telephone support (602-253-5000) and the VMS. Trapeze Trip Planning: A regional transit trip itinerary application which uses HASTUS Scheduler data with customer support and ValleyMetro.org interfaces. Person-to-person customer support is accessed through an Interactive Voice Response (IVR) system. Time Points: Pre-determined locations along a bus route whose coordinates are associated with a departure time. 14