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: 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 Travel 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), layover 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 #, bus ID), long, lat, nearest include current location/time, block (including intersection, time left last stop. layovers 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/ferry to rail or