1 / 31

TSIP: Real Time Situational Status Profile

TSIP: Real Time Situational Status Profile. Real Time & Service RSTWG 23 September 2009. 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.

york
Download Presentation

TSIP: Real Time Situational Status Profile

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. TSIP: Real Time Situational Status Profile Real Time & Service RSTWG 23 September 2009

  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. TSIP Project Purpose “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

  4. 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 Task & Schedule Task 2 & 3 – 11 Months Task 4 – about Month 6 Task 5 – 11th Month

  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. Transfer “AVL” Locations TrMS to TSIP via RT Application

  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. API for Data Consumer Access TSIP to Traveler

  15. TriMet Methods • 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” <?xml version="1.0" encoding="UTF-8"?> <resultSetxmlns="urn:trimet:arrivals" queryTime="1249652690996"> <locationdesc="SE 17th &amp; Center" dir="Northbound" lat="45.4935714921804" lng="-122.64825645346" locid="6849"/> <locationdesc="SE 17th &amp; Center" dir="Southbound" lat="45.4942619500587" lng="-122.64841793104" locid="6850" /> …. <arrivalblock="1708“ departed="true" dir="0“ estimated="1249654360000“ fullSign="17 Holgate to 136th Ave“ piece="1“ route="17“ scheduled="1249654380000“ shortSign="17 To 136th Ave“ status="estimated“ locid="6850“ detour="false"> <blockPositionat="1249652656000“ feet="27670“ heading="177“ lat="45.5309937“ lng="-122.6945941"> <tripdesc="Holgate &amp; 134th Dr" destDist="65898“ dir="0“ pattern="1“ progress="38228“ route="17“ tripNum="1060" /> </blockPosition> </arrival> </resultSet> Note: API supports stop and route persistence

  18. MTC “My 511” Methods

  19. Response to GetDepartureTimeList <?xml version="1.0" encoding="utf-8" ?> <departureTimeList> <stop name="19th St. Oakland" stopID="73214" routeName="RICHMOND | A“> <departureTime>7</departureTime> <departureTime>10</departureTime> <departureTime>14</departureTime> </stop> </departureTimeList> MTC API: GetDepartureTimeList() 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.”

  20. SDP Real Time API Data Needs

  21. Supports Multiple Routes at a “Stop”

  22. Current Daily Operator Status TrMS to TSIP via SDP

  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. Errors & Exceptions Methods and Messages

  25. Errors and ExceptionsPotential 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. Detour and Disruption Information TRMS to TSIP 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. Data Quality Measures

  30. Real Time Quality Measures

  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

More Related