TSIP Concept of Operations Transit Real Time Status Addendum

Scope This document describes the high level needs for the Transit Real Time (Operational) Status Information. The needs are based on architecture and operational scenario discussions held with the TSIP Real Time Regional Stakeholder Technical Working Group (RSTWG).

Transit Real Time Status Information System Description The system description adopted by the RSTWG is the TSIP Integration Model ‐‐ Centralized using “raw” data shown in Figure 1. The subsystems are described in Table 1: System Description Subsystems.

Figure 1: TSIP Integration Model: Centralized Approach

Table 1: System Description Subsystems Subsystem Name Description Transit Agency (TrMS) Any transit agency management system that generates schedule and operational service information. AVL/RT Application An implemented that collects current locations of transit vehicles in revenue service SDP XML Document The process for generating scheduled and daily service information into an SDP XML document. TSIP The “system” per ConOps TSIP RT Module A special module that manages agency real time status information and generates predictions and status information on transit service of its participating agencies. (This subsystem may be implemented by the 511NY service.)

In the centralized approach, the core processing system receives and integrates Current Location and schedule SDP data. In Figure 1, this system is depicted as the "TSIP RT Module.” At least three major sets of flows are required:

• Transfer “AVL” Locations (TrMS to TSIP via RT Application) • Current (persistent) Daily operator status (TrMS to TSIP via SDP) • API for Customer Access (TSIP to Traveler)

The Needs outlined in the next section address these three sets of flows.

Transit Real Time Status “Profile” Needs Real Time Status “profile” Needs were divided into two groups, general needs that dealt with the functionality and performance of the real time status API, and the data that specifies the API. The general needs include:

1. Efficiently gather, process, and disseminate real time status information and deliver it to the customer. 2. Ensure that the dissemination method (syntax, semantics and encoding) specified uses conventional and industry‐accepted standards or specifications. The semantics should conform to the current version of the SDP functional requirements. 3. Provide transit operator current status information that meets downstream customer information needs (see Table 1 below) 4. Provide and identify quality and descriptive information about real time status a. Ensure the logical consistency of the data in the Real Time Status “method” (RTSM) b. Ensure data persistence or access to references included in the RTSM c. Note: the quality data should be incorporated into the RTSM Data Requirements (see Table 1 below). 5. Method descriptions should support request/response (one time), stored request/response, and subscription request/response capabilities 6. Method descriptions should be structured as “elemental” requests and developed to be “chained” into more complex requests 7. Method descriptions should support error handling and processing 8. Method descriptions should be extensible and easy to maintain. 9. Method encoding should be extensible and easy to convert to other channel encoding formats

Data needs by request and response information needs and is described in Table 2: RTSM Data Requirements.

Table 2: RTSM Data Requirements

Note: {a, b} indicates one or more sets of information. For example, the response: agencyID, {routeID, routeDirection code} ‐‐ assumes that one agencyID and multiple sets of routeID and routeDirection are included in a response. Fields in italics imply that the data is optional. # Data Need Name Request Needs Response Needs 1 Authorized User Access by authorized user only Token, key or user identifier in every transaction (request) 2 Agency Information Request agency information available {agencyID} used to access information 3 Service and Route Information Request service and route(s) by agency AgencyID, {Route name or Route ID, service and mode types} 4 Route and Route Direction Request specific route(s) and route direction(s) by AgencyID, Route Name, Route ID, route Information agency direction (code and destinations) 5 Route/route direction at a stop Request route(s) and route direction(s) that service a StopID, {agencyID, routeID, routeDirection stop (by agency, mode or service type) code} 6 Stop List Request stop list {AgencyID, StopID} 7 Stops near a location Request stop(s) near a location {stop location, stopID, activation time, deactivation time} 8 ETA/ETD for a specific route/dir Request ETA/ETD for a specific route, route direction StopID, RouteID, RouteDirection, {ETA/ETD} at a stop at a stop 9 ETA/ETD for a specific trip (train) Request ETA/D for a specific tripID (train number) at a {agencyID, routeID, tripID (train no), stop} at a stop stop (station) 10 Estimated Time Request estimated travel time (from origin stop to agencyID, routeID, from stop, to stop, travel destination stop along a route/route direction or time [min] pattern)

To calculate from raw data will need block information (for linked trips), # stops between from stop‐to stop (for dwell times), and deadhead times (between trips) 11 ETA/ETD by stop (all routes that Request ETA/ETD by stop (Response: multiple stopID {AgencyID, {routeID, route direction, service that stop) responses with ETA/D, stop, route, route direction, {ETA/ETD} } } PTV #) ‐‐ 4 levels of hierarchy # Data Need Name Request Needs Response Needs 12 Schedule Adh. Information Request schedule adherence (coordinated timing) – Raw Location data: current location (lat/long); your arrival time and service stop departure time or (a) distance (or %) along pattern of trip or since last stop (b) distance along block;

BUS: AgencyID, RouteID, RouteDirection, {BlockID, tripID, vehicleID, headsign, current location}

TRAIN: AgencyID, TrainID (tripID), time left last station (% distance traveled, % distance until destination) 13 Next Service from a location Request Next Transit service information to Response similar to 11, but data is filtered for (response includes a stop and destination from known (current) location solution set. ETD) (linked services, first map location or location attribute to map, find one or more stops, find services at each of those stops that go near the destination) 14 Disruption Information on Request information on service (delays, incidents, agency, from time, to time, { route, route specific service or related to any events, special service) by route, route direction, stop, direction, from stop, to stop, delay impact in of the above requests destination minutes, comment} 15 Template for RT trip planning Request information via a template (for linked APIs) [depends on template] (connections) 16 Persistence (inherent or (should the value and definition be embedded in ??? required) request/response, e.g., stop and stop name, block, ‐‐ Stop etc.) ‐‐ Route, trip and block information ‐‐ Agency information 17 Alternative Support different media and channelization types May depend on information format (e.g., XML, media/channelization issues REST, SOAP) 18 Errors and Exceptions to Manage errors and exceptions Return error code if invalid. Invalid may requests include: Data not available Requested field is Out of range # Data Need Name Request Needs Response Needs Etc. 19 Health and quality Information Include validity (latency) data about the information Include publication/request datetime stamp provided (e.g., generation, publication, refresh rate, Include data generation datetime stamp scheduled/estimated) 20 Version Control Manage version control of request/response Include in header information 21 Raw Location Ability to generate estimated arrival time (need to Vehicle ID (train #, ID), long, lat, nearest include current location/time, block (including intersection, time left last stop. and running times by block/route segments) Block and layover information Transit Real Time Status Operational Scenarios This section describes operational scenarios for several envisioned downstream applications (either delivered by a NY state operator, authority or third party product) from one or more Application Programming Interfaces (APIs) or Web Services. The purpose of the operational scenarios is to discover the data needs required to drive these applications. No existing API, Web Service, or application or technology platform should be inferred or attributed to the scenarios.

Three categories or Operational Scenarios are described in the narrative. The three categories include several operational scenarios that describe variations on the theme. The categories and scenarios are follows: • Typical request for predicted service information o Traveler at Home or Office o Traveler en‐route (away from transit center or stop) o Traveler at Home looking for a mode o Traveler en‐route (at commercial center) o Traveler en‐route (at a bus shelter) • Bus Breakdown/Missing Bus and RT Information Dissemination o Internal Distribution of Bus Operations Incident Information o Internal Distribution of Bus Operations Incident Information (No replacement vehicles are scheduled.) o Processing/filtering Missing Bus in RTSI (Replacement vehicle scheduled with delay.) • Transfer among Modes and Operators o In a complex Transit Facility (with multiple operators and modes) o Feeder to Long Haul (e.g., bus/ to rail or commuter bus) or visa versa o Using Trip Itinerary to Request Real Time Information • Automating Validation and Upload of Ad Hoc Schedules for Planned and Unplanned Events o Ad Hoc pre‐planned schedule using in‐house tools o Ad Hoc schedule using Portal tools

1. Typical Request for Predicted Service Information This set of scenarios show typical requests for information by patrons who are using or want to use Public Transit services.

Traveler @ Home [Office] looking for a trip Martha, a suburban commuter, fires up her Internet Browser to a bookmarked request that includes her commute trip application. The web page shows the estimated arrival and travel times of the next three from Nyack to NYPA. The web site also shows the current travel times for two other transit operators (MNR and Bee‐Line) Martha may take. Based on the travel times and convenience, Martha decides to take the CoachUSA bus. This way she won’t have to fight the traffic and look for a parking space once she is in town.

Traveler En‐route (away from Transit Center or Stop) On her way to bus, it starts to drizzle. Martha decides to check on how long she will be waiting at her . She has her cell phone set to the 511NY Real Time Bus Information IVR with her reverse commute stop. She presses the directory entry on her cell phone with the saved telephone number and the correct sequence of keys that indicates the route and stop. Then she listens to the most updated information, the arrival time is sooner than she expected, so she rushes to the stop, arriving about two minutes before the bus arrives.

Traveler @ Office [Home] looking for mode Prior to leaving work, Martha accesses her reverse commute trip bookmark that she set on her work computer. She sees that three buses leaving between 4:30 and 5:30 are on schedule.

Travel En‐route (at a Commercial Location) As she leaves work Martha decides to stop at a large department store to buy a scarf since she knows the schedule of the next three buses. As she makes her purchase, presses a short cut button on her web enabled device that lists the routes that stop by the store. Her bus is due in 15 minutes, so she decides to check out the gloves while she waits.

Travel En‐route (at a bus shelter) As Martha gets to the bus stop, the rain starts up again. She ducks into the bus shelter where she sees a sign that says the bus (and vehicle ID) is due in 5 minutes. Someone who is visually impaired walks into the shelter and takes out an annunciation device that appears to interact with an antenna embedded in the shelter. The device announces the next three buses, their route, direction, and estimated arrival times.

2. Bus Breakdown/Missing Bus and RT Information Dissemination This set of scenarios describes the Real‐Time Transit Service Information when a transit vehicle breaks down or is taken out of service unexpectedly. Each scenario is premised on the assumption that a decision has been made to remove the vehicle from operations.

Internal Distribution of Bus Operations Incident Information A supervisor or mechanic communicates to the Bus Operations center that bus # 1234, in Block #10200 is being taken out of service. A control operator inputs that information and keys in the operational strategy agreed upon to deal with the missing bus into the CAD and Incident Management workstation. The information is relayed to the RT Service Information (RTSI) server.

(Alternatively, when the vehicle is taken out of service by the mechanic or supervisor, the on‐board operator interface (device) communicates special incident and response code messages directly to the Incident Management and CAD server, and the information is relayed to the RTSI server.)

Internal Distribution of Bus Operations Incident Information (No replacement vehicles are scheduled.) When the RTSI receives the information indicating the bus incident and response message, it provides a special message to the dissemination media technologies to notate the status that the bus was taken out of service. The response code indicates that no replacement is scheduled. The presentation / publishing media may either (1) not show information related to the missing bus, or (2) display a customer message with more detailed information such as: “Route B14 Scheduled 10:17 am bus taken out of service, wait for next bus in 10 minutes.”

Processing/filtering Missing Bus in RTSI (Replacement vehicle scheduled with delay.) When the RTSI receives the information indicating the bus incident and response message, it provides a special message to the RTSI Server to notate the status that the bus was taken out of service. The response code indicates that a replacement is planned within 30 minutes. (A note is inserted with the delay indicating the circumstances.) The 30 minute delay is included in the RTSI engine.

3. Transfer among Modes and Operators This set of scenarios deals with passengers transferring from different modes or operators. The variety of transfers includes:

• In a complex Transit Facility (with multiple operators and modes) • Feeder to Long Haul (e.g., bus/ferry to rail or commuter bus) or visa versa • Using Trip Itinerary to Request Real Time Information

Dynamic Message Sign in a Complex Facility (Alternative #1) As the bus pulls in 5 minutes late to the station, Dave runs out of the bus and glances at the multi‐line dynamic message sign to see if his train arrived at the platform yet. From the sign at the entrance to the terminal, he sees that the train is due in 5 minutes … just enough time to grab his MetroCard, pay at the gate, and dash down the to the platform. No time for coffee today!

Dynamic Message Sign in a Complex Facility (Alternative #2) As Katie ascends the escalator from the NYCT subway platform, she can see the pouring rain. Her bus stop is halfway around the transit center, and she has no incentive to rush into the horizontal rain. At the top of the escalator is a multi‐line dynamic message sign with the bus arrival times. She doesn’t see her route number/direction listed, so she waits as the sign scrolls through several other routes until a message indicates that her bus is due on time (in 7 minutes).

Feeder to Long Haul Transfer (Option #1) Robert always takes Long Island Bus that arrives at Hempstead Station at 6:19 am and connects to the LIRR train which only runs at 6:35 and 8:44 am. If Robert misses his connection then he will travel to the next stop (West Hempstead Station) and connect to a different LIRR train that is scheduled to leave at 7:05 am. So he sets up a subscription from the NY511 to receive a single daily (weekday only) notice on the real‐time status of the LIB bus at 6:10 a.m. exactly. As 6:10 am approaches, he takes out his cell phone as it begins to vibrate. He views the text message that shows him the expected arrival time of his bus at Hempstead, the expected departure time of the LIRR train, and the estimated transfer time. He sees that he will be on time, so he doesn't request the second option (which is the transfer times at West Hempstead station).

Feeder to Long Haul Transfer (Option #2) One snowy day, Robert is on the LI Bus to work and he receives his usual 6:10 am email. This time, the message indicates that the LIRR train is delayed by 20 minutes due to a snow schedule, so he pushes a response message asking for option 2. Within seconds, he receives a message that indicates that the West Hempstead train will leave on time. So he decides to stay on the bus and take the West Hempstead branch into work.

Trip Plan Request for Real‐Time Information Tracy wasn’t sure how to get from her conference site in Manhattan to her friend’s house in Westchester. She didn’t have time to wait, and she didn’t want to get lost. So she logged onto the NY511 trip planning web site, and generated several optional trip plans. However, not knowing exactly when she would be out of the conference and what the traffic situation would be like, she was not sure which trip plan was the most practical. So she requested templates for two trip plan options that she could send to the RT Transit Kiosk application. The application, when it receives a request with a trip plan template and a time of departure, responds with a timetable of the estimated arrival and departure times for all the links in her trip plan template. She ordered the information to be segmented into a timetable with the following links by segment:

• Javits Center to Grand Central Terminal (feeder) o Option 1: two NYCT subway trains o Option 2: NYCT Bus M42 • Grand Central Terminal to Westchester (long haul) o MNR New Havel Line to Larchmont o MNR Harlem Line to Scarsdale • Westchester to Scarsdale address (feeder) o Bee‐Line Bus #66 (at Larchmont MNR Station) o Bee‐Line Bus #66 (at Scarsdale MNR Station)

A third option had her taking the Bee‐Line BxM4C express ‐‐ 5:41 pm trip from Madison Ave & 47th Street (a six block walk from the Convention Center). She could get off at the Larchmont Station and pick up a Bee‐Line Bus from there.

At 5:25 pm, Tracy got out of the convention hall, sent the template options and saved the response. She also sent out the ETA and travel time requests for Bee‐Line BxM4C from Madison & 47th to Larchmont station. She could easily walk to the stop to make the Bee‐Line express bus, but with the estimated arrival time at Larchmont (due to congestion and travel times on the Major Deegan Expressway), she would arrive ten to fifteen minutes after the MNR train. So she decided to take the train.

4. Automating Validation and Upload of Ad Hoc Schedules for Planned and Unplanned Events

This set of scenarios deals with the delivery to 511NY and other downstream applications of updated, changed or new schedules using the SDP XML Schema. The context of these scenarios is that a schedule is changed for a short time (during a “schedule version period”) due to a pre‐planned event such as construction, weather emergency, or special event, or a long‐term unplanned event that will last for longer than a day. The unplanned event may be due to a major incident or disruption on a transit alignment (track or road). The Portal should be able to validate and disseminate the SDP XML Document within minutes of receiving an ad hoc schedule.

Long Island Rail Road Construction Schedule

Long Island Rail Road (LIRR) is planning to change its train schedule due to construction on several track blocks over the weekend. They planned these events several weeks in advance, and determined how they would schedule the "track rights" and customer trains. They inserted the data into their internal scheduling system. This system has a tool to automatically generate SDP XML Documents and deliver them to the Portal Data Registration process. LIRR staff tag the SDP XML Document as an ad hoc schedule (in the XML Document ScheduleRevision element), also indicating the activation and deactivation dates. In addition, the Route element includes a description field, and they use the routeBeginDate/routeEndDate, and description fields to clarify that the changed routes are temporary (through the date fields), and the extent of the changes are detailed in the description field. The description content from the Route element may then be used as the reason for the schedule change to the public. The description inserted into the field says:

"This Train Schedule for the Hampton Service will replace trains: 2345, 3345, 3544 and 3455 on October 24 and 25, 2009."

Following the Data Registration validation process, as the Portal is loading the Document metadata, the System identifies the document as an "ad hoc" schedule revision. An "ad hoc" revision will trigger an alert to key downstream Data Consumer Administrators with information related to period of validity. The new Document will automatically be posted to all the Data Consumers who subscribe to the data set.

Long Island Bus Adjustment Due to LIRR Due to the changes in the LIRR schedule, Long Island Bus (LIB) made some changes. First, they downloaded the LIRR ad hoc schedule from the Portal after they were alerted to the changes. Then they loaded the schedule into the Dynamic Timetable Generator1 to view the schedule. Using these tools they were able to see how they needed to adjust their schedules. Using the WDMS2, they pulled up their SDP schedule data, adjusted the regular times using the trip template, created an ad hoc schedule that corresponded to the same activation times as LIRR, notated the routes and added notes and assigned them to the trips. Then they generated the SDP XML Document through the WDMS. The WDMS registered the LIB ad hoc schedule using the Portal Data Registration process. Similar to the LIRR, the Portal, when it processed the data for its metadata, identified this new file as an ad hoc schedule and triggered a message to Data Consumer Administrators, and posted the new data set to all Data Consumer subscribers.

1 An open source tool developed through a TRB Transit IDEA grant that displays timetables from SDP XML document format. 2 The WDMS project is in the process of developing interfaces that read and write SDP XML documents