1. REAL TIME & SERVICE RSTWG 23 SEPTEMBER 2009 TSIP: Real Time Situational Status Profile

2. Discussion Items Context for Real Time SDP Extension Real Time Status “Profile” / “Method” Needs Architecture and Data Flows Existing APIs  TriMet  MTC Methods and Context / Sequence Diagrams

3. “A FRAMEWORK TO PROVIDE A SINGLE POINT OF STORAGE, DISCOVERY, AND ACCESS TO A VARIETY OF TRANSIT SERVICE INFORMATION AND TOOLS” INCLUDING REAL TIME SITUATIONAL STATUS INFORMATION AND THE TRANSIT SERVICE DATA THAT SUPPORTS REAL TIME DATA TSIP Project Purpose

4. Task & Schedule Task 2 & 3 – 11 Months Task 4 – about Month 6 Task 5 – 11 th Month Task 2: SDP Extensions  Planning Data  Real Time / Status Data  Fare Data Task 3: TSIP Requirements Task 4: External TSIP Requirements Task 5: Procurement Approach

5. Real-Time Status Extension – RT TWG (Tasks and Deliverables) White paper: -- Industry scan: Issues, architectures, standards -- Survey on Situational Data Needs for region

6. TSIP Project Systems Engineering Approach

7. “Situational Status” Definition Estimated impact (estimated arrival, estimated departure, schedule adherence, etc.) on actual service at a transit stop.

8. Real Time Status “Profile” Needs 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)

9. Real Time Status “Profile” Needs 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  Ensure the quality data is incorporated into the RTSM.

10. Real Time Status “Method” Needs Method descriptions should  support request/response (one time), stored request/response, and subscription request/response capabilities  be structured as “elemental” requests and developed to be “chained” into more complex requests  support error handling and processing  be extensible and easy to maintain.  be extensible and easy to convert to other channel encoding formats

11. TSIP Integration Model: Centralized Approach Transfer “AVL” Locations  (TrMS to TSIP via RT Application) Current (persistent) Daily operator status  (TrMS to TSIP via SDP) API for Data Consumer Access  (TSIP to Traveler)

12. TRMS TO TSIP VIA RT APPLICATION Transfer “AVL” Locations

13. “AVL” Location Data Needs Information should include:  Current Location (spatial, distance traveled along route configuration, heading, speed-avg, other public information)  Updated Route Configuration (block for bus, layovers, pattern, running times, dwell times, etc. or changes to scheduled route configuration)  Updated system detour and disruption information (congestion along tracks going into station, fire in tunnel, detour route for bus due to construction, etc.) Performance requirements  Frequency, file size, quality measures

14. TSIP TO TRAVELER API for Data Consumer Access

15. TriMet Methods APIDescription Arrivals:Reports next arrivals at a stop identified by location ID. Detours:Retrieves a list of detours currently in effect by route. RouteConfig: Retrieves a list of routes being reported by TransitTracker from the active schedule, optionally a list of directions for those routes and stops in each of those directions. Trip Planner:Plan trips between two locations programmatically. Request AppID

16. TriMet Arrivals API Request: up to 10 location identifiers, each associated with a transit stop (in a comma delimited list). resultSet includes -- attribute (queryTime) -- errorMessage -- location -- arrival -- routeStatus

17. Arrivals resultSet for “6849” & “6850” …. <blockPosition at="1249652656000“ feet="27670“ heading="177“ lat="45.5309937“ lng="-122.6945941"> <trip desc="Holgate & 134th Dr" destDist="65898“ dir="0“ pattern="1“ progress="38228“ route="17“ tripNum="1060" /> Note: API supports stop and route persistence

18. MTC “My 511” Methods Service NameCategoryEndPointDescription GetTokenSecurityTransit.asmxRetrieves a security token for use with service calls. (Planned) GetVersionSystemTransit.asmxRetrieves the version of the service endpoint. GetAgencyListTransitTransit.asmxRetrieves a list of the transit agencies in the MY 511 system. GetDeparuteTimeListTransitTransit.asmxRetrieves a list of departure times for a given set of stop IDs. GetDirectionListTransitTransit.asmxRetrieves a list of direction entries for an agency that supports direction information. GetRouteListTransitTransit.asmxRetrieves a list of routes for a given agency. GetStopListTransitTransit.asmxRetrieves a list of transit stops for a given route.

19. MTC API: GetDeparture TimeList() Request: -- agency (GetAgencyList), -- route (GetRouteList), -- stop (GetStopList) Response: “GetDepartureTimeList retrieves a list of departure times for a given list of stop IDs. Each departure time is represented by an integer minutes value.” Response to GetDepartureTimeList 7 10 14

20. SDP Real Time API Data Needs NeedsMTC / TriMet Authorized UserGetToken / request AppID via email Agency InformationGetAgencyList (no mixed status information messages) / not applicable (NA) Service & Route InformationGetDirectionList; GetRouteList; GetStopList / RouteConfig Note: MTC only includes stopIDs near requested intersection; no spatial reference information Real Time Status (departure, arrivals, disruptions) GetDepartureTimeList – by route & stop (no disruption information) / Arrivals by stop; Detours Quality InformationNA/ attribute = query time Estimated Travel TimeNot Available Specific “train” informationNot Available Errors / ExceptionsIncluded in both Schedule Adherence or raw locationsNo / may be derived* from Arrival@block

21. Supports Multiple Routes at a “Stop”

22. TRMS TO TSIP VIA SDP Current Daily Operator Status

23. Current Daily Operator Status Data Needs Special service  Can the SDP revision element support this requirement? Actual detours and disruptions to regular service and stop/station (including parking) Changes to schedule -- Ad Hoc Schedule in the form of SDP Revision  For Buses: including Block information, information for public (e.g., headsign, bus ID)  For Trains: number of cars, etc. Changes to Stops and Stations Configuration  E.g., Portal closed, stop under construction, platform supports only first two cars in consis…

24. METHODS AND MESSAGES Errors & Exceptions

25. Errors and Exceptions Potential error messages from TCIP 3.0.2 nullData (1), intentionalBlank (2), deletedByDevice (3), msgUnavailable (4), illegalCalc (5), deviceMalfunction (6), msgExpired (7), suppressedSecurity (8), suppressedPrivacy (9), unspecified (10), vehicle Shutdown (11), unknownFile (12), receiverCantProcess(13), incompleteMessage (14), fileCorrupt (15), invalidPriority (51), invalidFrequency (52), invalidMode (53), invalidDeliveryVerification (54), cantDecrypt (55), accessDenied (56), excessLatency (57), invalidMsgRef (58), timeExpired (59), dataUnavailable (60), dataExpired (61), valueOutOfRange (62)

26. TRMS TO TSIP Detour and Disruption Information Detours/ Disruptions

27. Disruption Information Needs Severity, security, privacy Disruption Type Description Passenger mitigation procedures Passenger instructions for alternate transportation Impact to other routes/lines Time disruption occurred Estimated time to complete mitigation, response, recovery

28. Detour Information Needs Use SDP with Revision as Ad Hoc Schedule

29. MEASURES Data Quality

30. Real Time Quality Measures Quality TypesMeasure Temporal (customer access API) Published (valid, query time) Refreshed Updated Tracking (AVL location informati0n) Accuracy and type of Sensor -- GPS -- dead reckoning and system clock Frequency of updates Detour and disruption information Start time Last update

31. Next Steps Agree on data requirements and exchange procedures (will post early Nov on wiki)  UML Class Diagram and Definitions  UML Context and Sequence Diagrams and descriptions Develop Requirements Document -- composed of API descriptions in XML (due early Dec – will post on wiki)  XML Schema  Plain Old XML (POX)  REST  Or other format