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
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
Task &
Schedule
Task 2 & 3 – 11 Months
 Task 2: SDP Extensions
 Planning Data
 Real Time / Status Data
 Fare Data
Task 4 – about Month 6
 Task 3: TSIP Requirements
Task 5 – 11th Month
 Task 4: External TSIP
Requirements
 Task 5: Procurement Approach
Real-Time Status Extension – RT TWG
(Tasks and Deliverables)
White paper:
-- Industry scan:
Issues,
architectures,
standards
-- Survey on
Situational Data
Needs for region
Input to
TSIP Concept of
Operations
Typical Prediction Use Case
Incident/Disruption Use Case
Architecture, Needs and 3
Use Case Topics
Regional Transfer Scenario Use Case
Functional/Data
Requirements Document
(i) Real-time data from
Providers
(2) Web Service
Specifications for Web
Services / Application
Programming Interfaces
(APIs)
Demonstration
(Technical Support)
Validate SDP XML Documents
with Downstream Applications
Final Deliverables
(1) SDP Guidance Documents
(2) SDP XML Schema and Web Service (final)
(3) Updated Functional Requirements Document
& Conceptual Data Reference Model
TBD
TSIP Project Systems Engineering Approach
Concept of Operations
for
Regional Service Data
Repository & Portal
(includes TSDEA Use Cases,
Portal and SDP Extension
UC)
Trip Planning Use Cases & ConOps Addendum
RT Status Use Case
SDP Extensions
Fare Calculator Use Case
Portal Use Cases
System Requirements
For
TSIP Implementation
Includes family of SDP data
models and XML Schema
SDP / SDP Extension
Requirements
SDP, Calendar and
Extension XML Schema &
open source code
Final Deliverables
(1) SDP and Extension Guidance Documents
(2) SDP XML Schemas
(3) Requirements Document & Conceptual Data
Reference Models for all SDP / SDP Extensions
(4) Demonstration results (conversion software
from native Agency data to SDP to downstream
applications)
Specifications and Request for
Proposal
“Situational Status” Definition
 Estimated impact (estimated arrival, estimated
departure, schedule adherence, etc.) on actual
service at a transit stop.
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)
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.
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
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)
Transfer “AVL” Locations
TRMS TO TSIP VIA RT APPLICATION
“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
API for Data Consumer Access
TSIP TO TRAVELER
TriMet Methods
API
Description
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
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
Arrivals resultSet for “6849” & “6850”
<?xml version="1.0" encoding="UTF-8"?>
<resultSet xmlns="urn:trimet:arrivals" queryTime="1249652690996">
<location desc="SE 17th &amp; Center" dir="Northbound" lat="45.4935714921804"
lng="-122.64825645346" locid="6849" />
<location desc="SE 17th &amp; Center" dir="Southbound" lat="45.4942619500587"
lng="-122.64841793104" locid="6850" />
….
<arrival block="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">
<blockPosition at="1249652656000“ feet="27670“ heading="177“ lat="45.5309937“
lng="-122.6945941">
<trip desc="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
MTC “My 511” Methods
Service Name
Category
EndPoint
Description
GetToken
Security
Transit.asmx
Retrieves a security token for use with service
calls. (Planned)
GetVersion
System
Transit.asmx
Retrieves the version of the service endpoint.
GetAgencyList
Transit
Transit.asmx
Retrieves a list of the transit agencies in the MY
511 system.
GetDeparuteTimeList
Transit
Transit.asmx
Retrieves a list of departure times for a given
set of stop IDs.
GetDirectionList
Transit
Transit.asmx
Retrieves a list of direction entries for an
agency that supports direction information.
GetRouteList
Transit
Transit.asmx
Retrieves a list of routes for a given agency.
GetStopList
Transit
Transit.asmx
Retrieves a list of transit stops for a given route.
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
<?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>
SDP Real Time API Data Needs
Needs
MTC / TriMet
Authorized User
GetToken / request AppID via email
Agency Information
GetAgencyList (no mixed status information
messages) / not applicable (NA)
Service & Route Information
GetDirectionList; 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 Information
NA/ attribute = query time
Estimated Travel Time
Not Available
Specific “train” information
Not Available
Errors / Exceptions
Included in both
Schedule Adherence or raw locations
No / may be derived* from Arrival@block
Supports Multiple Routes at a “Stop”
Current Daily Operator Status
TRMS TO TSIP VIA SDP
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…
Errors & Exceptions
METHODS AND MESSAGES
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)
Detour and Disruption
Information
TRMS TO TSIP
Detours/
Disruptions
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
Detour Information Needs
 Use SDP with Revision as Ad Hoc Schedule
Data Quality
MEASURES
Real Time Quality Measures
Quality Types
Measure
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
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