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 vehicle tracking system 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:

Efficiently gather, process, and disseminate real time status information and deliver it to the customer.
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.
Provide transit operator current status information that meets downstream customer information needs (see Table 1 below)
Provide and identify quality and descriptive information about real time status
Ensure the logical consistency of the data in the Real Time Status “method” (RTSM)
Ensure data persistence or access to references included in the RTSM
Note: the quality data should be incorporated into the RTSM Data Requirements (see Table 1 below).
Method descriptions should support request/response (one time), stored request/response, and subscription request/response capabilities
Method descriptions should be structured as “elemental” requests and developed to be “chained” into more complex requests
Method descriptions should support error handling and processing
Method descriptions should be extensible and easy to maintain.
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 Information / Request specific route(s) and route direction(s) by agency / AgencyID, Route Name, Route ID, route direction (code and destinations)
5 / Route/route direction at a stop / Request route(s) and route direction(s) that service a stop (by agency, mode or service type) / StopID, {agencyID, routeID, routeDirection 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 at a stop / Request ETA/ETD for a specific route, route direction at a stop / StopID, RouteID, RouteDirection, {ETA/ETD}
9 / ETA/ETD for a specific trip (train) at a stop / Request ETA/D for a specific tripID (train number) at a stop (station) / {agencyID, routeID, tripID (train no), stop}
10 / Estimated Travel Time / Request estimated travel time (from origin stop to destination stop along a route/route direction or pattern)
To calculate from raw data will need block information (for linked trips), # stops between from stop-to stop (for dwell times), layover and deadhead times (between trips) / agencyID, routeID, from stop, to stop, travel time [min]
11 / ETA/ETD by stop (all routes that service that stop) / Request ETA/ETD by stop (Response: multiple responses with ETA/D, stop, route, route direction, PTV #) / stopID {AgencyID, {routeID, route direction, {ETA/ETD} } }
-- 4 levels of hierarchy
12 / Schedule Adh. Information / Request schedule adherence (coordinated timing) – your arrival time and service stop departure time / Raw Location data: current location (lat/long); 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 (response includes a stop and ETD) / Request Next Transit service information to destination from known (current) location
(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) / Response similar to 11, but data is filtered for solution set.
14 / Disruption Information on specific service or related to any of the above requests / Request information on service (delays, incidents, events, special service) by route, route direction, stop, destination / agency, from time, to time, { route, route direction, from stop, to stop, delay impact in minutes, comment}
15 / Template for RT trip planning (connections) / Request information via a template (for linked APIs) / [depends on template]
16 / Persistence (inherent or required)
-- Stop
-- Route, trip and block information
-- Agency information / (should the value and definition be embedded in request/response, e.g., stop and stop name, block, etc.) / ???
17 / Alternative media/channelization issues / Support different media and channelization types / May depend on information format (e.g., XML, REST, SOAP)
18 / Errors and Exceptions to requests / Manage errors and exceptions / Return error code if invalid. Invalid may include:
Data not available
Requested field is Out of range
Etc.
19 / Health and quality Information / Include validity (latency) data about the information provided (e.g., generation, publication, refresh rate, scheduled/estimated) / Include publication/request datetime stamp
Include data generation datetime stamp
20 / Version Control / Manage version control of request/response / Include in header information
21 / Raw Location / Ability to generate estimated arrival time (need to include current location/time, block (including layovers and running times by block/route segments) / Vehicle ID (train #, bus ID), long, lat, nearest intersection, time left last stop.
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
Traveler at Home or Office
Traveler en-route (away from transit center or stop)
Traveler at Home looking for a mode
Traveler en-route (at commercial center)
Traveler en-route (at a bus shelter)
Bus Breakdown/Missing Bus and RT Information Dissemination
Internal Distribution of Bus Operations Incident Information
Internal Distribution of Bus Operations Incident Information (No replacement vehicles are scheduled.)
Processing/filtering Missing Bus in RTSI (Replacement vehicle scheduled with delay.)
Transfer among Modes and Operators
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
Automating Validation and Upload of Ad Hoc Schedules for Planned and Unplanned Events
Ad Hoc pre-planned schedule using in-house tools
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 buses 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 TransitCenter or Stop)

On her way to bus, it starts to drizzle. Martha decides to check on how long she will be waiting at her bus stop. 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. Theinformation 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 escalator 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.