© 2004Kizoom

1

SIRI - Service Interface for Real Time Information

(CEN-OO278181 ) http://www.siri.org.uk

27- 29 Cursitor StreetLondon, EC4A 1LT

nick_knowles@kizoom.com

Siri 0.1g v3.6c

© 2004Kizoom

2

Topics

• Overview– Key Points – Motivation– Underlying standards

• Specific Functional Services• Transport & Communications • What do you need to do to Implement Siri?• Roadmap

– Some Possible Future Work Items

© 2004Kizoom

3

SIRIOverview

© 2004Kizoom

4

SIRI – Introduction• Real-time Server-to-Server Services for

Public Transport– Defines a Service Interface for exchanging real-

time information of public transport networks.– Complements an underlying static information

model for network and timetable description (TRIDENT,VDV, TransXChange)

– Provides information on any change on the timetabled information, from original publication to the actual & predicted transport running times.

© 2004Kizoom

5

Gene Pool

© 2004Kizoom

6

Based on• Underlying Standards

– Public Transport Data• TransModel : Terminology, model (isomorphic)• VDV 453, 454, Trident, RTIG-XML

– Real systems & experience!• GML, WGS84

– Technology• XML, XSD• WS-Soap, WS-PubSub Web Service enabled• UML, ISO 24531, RFC

• Participants– Germany (VDV453, VDV 454)– France (Trident, TransModel)– UK (RTIG-XML, Trident, TransModel)– Denmark, Sweden, Norway, (PubTrans)– Czechoslovakia

© 2004Kizoom

7

SIRI Key Points• Approach

– Defines Functional services (real-time)– Defines an independent communication layer

(may be reused elsewhere)– SIRI does not define the underlying object

structure and data-model (Stop Points, Lines, Route, etc.) :

• Assumed to be TransModel compliant

• Practical / Pragmatic– SIRI is a tool box, well designed for an

incremental implementation– It is not a Panacea ….– Compromises to accomodate real systems

• Includes compromises to facilitate migration

© 2004Kizoom

8

Motivation - Uses of SIRI Services

• Rapid growth in real-time info - makes Public Transport more efficient to operate & more attractive to use.– Provision of Real time Service Information to Passengers.

• At Stop, On board, tethered & mobile internet– Provision of Information to Journey Planners.

• Real-time augmented– Facilitating Connections for Passengers. – PT Fleet and Network Management.– General Business Communication.

• E.g. Adherence to schedule

• Growth of mobile & internet – On-line, real time data. Roaming!– Ubiquitous embedded computing

© 2004Kizoom

9

Motivation – Linking up• Orchestrating Multiple Actors in federated

systems– Passenger information services involving multiple

providers• Connection/interchange information• Stop Point/Station operated by several transport operators• etc.

– Services between different operators• Single PT line – several operators• Connection management

– Services with other content providers• To provide information to content providers• To get information from content providers

© 2004Kizoom

10

Motivation - Standards• Value to Passenger Transport Executives and Authorities /

Operators as Customers– Open, modular architectures & supplier independence.– Protection of investment.– Efficient tender specification criteria.

• Value to Suppliers– European economies of scale & markets.– Reduced complexity & deployment costs– More reuse, Cheaper integration– Simplified tendering, quality differentiator.

• Value to Both– Enables new types of services– European economies of scale– Lowers costs - creating new markets– Modern, Modular, scaleable architectures– Harnesses open internet standards

© 2004Kizoom

11

The SIRI Specifications

• SIRI Documents (Completed 2005)– Technical Standard

Part 1: Context and Framework

Part 2: Communications Infrastructure

Part 3: Functional Service Interfaces

– Supporting XML Schema – W3C .XSD• Modular package structure, one per service• Support WSDL /SOAP binding using same xsd schema

• Migration path from existing standards– Country Profiles & Guidance Notes

© 2004Kizoom

12

Web Site

http://www.siri.org.ukhttp://www.siri.org.uk

© 2004Kizoom

13

SIRI Approach & Services

• Separation of Concerns– Transport layer is separate – Web Service architecture (http &/or SOAP…..)– SIRI General Communications Services

• Common to all types of Functional Service• Robust, scaleable, architecture for Real-Time• Tuneable for efficient deployment

– SIRI Functional Services • Timetables & Timetable Changes • Stop Events (Arrivals & Departures) • Vehicle Movement • Connection Protection (Timetables, Events)• General Informative Messages

© 2004Kizoom

14

Support Different Operation Models

• The same Interfaces can be used for different operational models

Vehicle tracking and management

Information for

passengers

Bus 1 Bus 2

RTI core data model

Prediction generator

(a) UNITARY single control and information centre

Information for

passengers

Bus 1

Vehicle tracking and management

RTI core data model

Prediction generator

(b) INTEGRATORseparate control and information centres

Bus 2

Vehicle tracking and management

© 2004Kizoom

15

Support Different Environments

• Able to optimise for different operational characteristics– High/Low bandwidth– Fast/slow processors – Hi/Low traffic– Large/small networks– Sparse /dense usage– Central or distributed

• Evolvable– Able to implement on different generations of

technology– Allow modular, incremental implementation: roadmap

© 2004Kizoom

16

SIRI Functional Services

© 2004Kizoom

17

SIRI Timetable Services

• Production Timetable (PT)– Distribute latest timetable

• Schedule to AVMS• AVMS to client

• Estimated Timetable (ET)– Distribute latest timetable including real-time

• Cancellations, additions, short working• Realtime-predictions

© 2004Kizoom

18

SIRI Stop Services

• Stop Timetable (ST)– Distribute latest timetable

• Stop Centric Timetables• Provisions Clients with latest data.

• Stop Monitoring (SM)– Real time Arrival & Departure Boards

• Arrivals, Departures, pass-throughs• At stop, onboard, away

© 2004Kizoom

19

SIRI Connection Services

• Connection Timetable (CT)– Distribute planned interchanges

• Stop Centric • Provisions Clients.

• Connection Monitoring (CM)– Connection management– Guaranteed connection support

© 2004Kizoom

20

SIRI General Message Services

• General Message (GM)– Exchange Structured Messages

• Simple or embedded structures (eg TPEG, Trident etc)

• Situation, operational, and general info messages

© 2004Kizoom

21

PT Systems & SIRI Interfaces

a a

Generic model of PT operations, showing exchange points for RTI

© 2004Kizoom

22

Example 1: Hamburg

• Federated Modes & Regions

© 2004Kizoom

23

Example 2: Copenhagen

• Integrator

© 2004Kizoom

24

Example: Isle de France

• Hybrid

© 2004Kizoom

25

Transport & General

Communications

© 2004Kizoom

26

Transport & Communications

• Common Protocols for all SIRI Functional Services– Independent of Functional Message Content– Based on new Web services standard Ws-

PubSub, Ws-Address etc (W3C) – Communications Transport Independent

• XML + http POST, • WSDL SOAP Binding

© 2004Kizoom

27

SIRI Communications Layer

• Common to all Functional Services

SIRI interface

Service 1 –used

Organisation 1or System 1

Organisation 2or System 2

Communications Service Layer – common

Service 2 –not used

Service n –used

Service 3 –not used

)…

sends receives

© 2004Kizoom

28

Common Communications Services

• General Functions Common to all SIRI Service Types– Subscription Management– Recovery & Restart– Access Controls – Who is allowed to access?– Versioning – Allows distributed upgrades– Discovery – Which systems have which data?

• Some Capabilities are Optional

© 2004Kizoom

29

Communications Framework Patterns

• Alternate Patterns of Interaction1. Request/Response vs. Publish/Subscribe

• Choose for scaleability & responsibility

2. Direct Delivery vs. Fetched Delivery• Allows efficient implementation choices

3. Notification Mediation• Reduces traffic for publish subscribe

– Last Update, Change Threshold,– Subscriber Groups

© 2004Kizoom

30

Interaction 1- Request/Response

© 2004Kizoom

31

Interaction 2- Publish/Subscribe

© 2004Kizoom

32

Delivery - Direct

© 2004Kizoom

33

Delivery - Direct & Fetched

© 2004Kizoom

34

Mediation

• Filtering of Data & Notifications to Reduce data traffic– Incremental Data Changes:

• Only send data changes since last update

– Change threshold • Only notify if change is more than a certain amount

– Grouping of subscriptions • One notification for changes to many subscriptions

in a group

© 2004Kizoom

35

Mediation - Efficiency

• Reducing Traffic

© 2004Kizoom

36

Mediation

• Interaction of simple patterns can be quite complex.

© 2004Kizoom

37

SIRI What do you need to do to implement

SIRI ?

© 2004Kizoom

38

How to Implement SIRI #1

• Select the parts of SIRI you need, – Timetables, Stop Monitoring, etc– Discovery, Access Control

• Select your transport protocol (SOAP, HTTP post, XML anything else…) – Select additional Web Service (encryption,

authentication, etc.)

• Select non-mandatory fields (XSD)• Define any needed extensions

– Embeddable any data types

© 2004Kizoom

39

How to Implement SIRI #2

• Agree Local Reference data – Identify partipant « peers » – Line Ids– Stop Point Ids (and Stop Point kind…)– Connections Ids– Supported values (ServiceCategory,

ProductCategory, VehicleFeature)

– Geospatial Coordinate System

© 2004Kizoom

40

How to Implement SIRI #3• Agree Local Communication & Mediation Options

– Interaction Patterns• Request / Response• Publish / Subscribe

– Delivery Pattern• Direct only (or Fetched delivery DE)• Multiple Subscriber Delivery

– Transport & Comms• http POST / WSDL

– Recovery• Heartbeat for PubSub• Acknowledgement of notifications – or not

– Mediation• Simple or multiple subscriber filters,• “Stop VisitNumber”

© 2004Kizoom

41

SIRI Further Roadmap

© 2004Kizoom

42

SIRI – Status

• Final Draft Awaiting Vote

• Next WG Meeting Feb 6/7 2006

• Possible Work Items

• Interoperability / Datex?

• Some Services live already!

© 2004Kizoom

43

Possible Additional Work Items• Real-time Facility Changes Service FR

– Allows changes to availability of facilities and equipment of stop, vehicle and service to be exchanged in real time . This can be used for example to communicate equipment changes affecting impaired access to PT such as lift or escalator changes. Information is of use to real-time journey-planning and alert services. Should consider interchange aspects.

• Situation/Event Structured Incident model UK/FR– Enhance GMS to have preferred structured incident model for describing

disruptions to services, model relates to SIRI, Based on TPEG + TransModel

• Control Actions Server Interface SE – Service for distributing control actions amongst participants, for example

for coordinating management of late services. • Traffic Status / Prioritisation Interface for UTMC UK/DE

– Allows real-time public transport management systems to exchange information with road UTMC systems, eg to provide real time delay information a road speed information to the road traffic management system, or to allow for the exchange of signal priority options.

© 2004Kizoom

44

SIRI

DataContent

ExchangeBehaviour

TransportProtocol

well-defined interactionswith XML schemarepresentations

Mainstream Internet•HTTP POST,•SOAP.

definedXML SchemaFor payload

XML XML Http Post

SOAP

TransModel WS-PubSub

http get ?

IP

© 2004Kizoom

45

DATEX II

DataContent

ExchangeBehaviour

TransportProtocol

defined XML schema (draft, work in progress)

D2 deliverablespecifies…may be revised?

in progress for2006 publicationHTTP GET, POST,SOAP.

© 2004Kizoom

46

Some Conclusions

• TransModel invaluable– Vocabulary & concepts– Tool for harmonisation legacy standards

• Message architectures critical for real time efficiency– Based on proven architectures

• Modularity for legacy migration– Incremental implementations, optional features– XML allows flexible coupling– Road map for additional features

© 2004Kizoom

47

SIRI Further Technical Points

© 2004Kizoom

48

SIRI XSD Packages – Layered Reuse

Common

Request Management

Common

Request Management

SIRI Functional Services

SIRI Functional Services

Low Level TypesLow Level Types SIRISIRICommon

ModelCommon Model

© 2004Kizoom

49

Recovery & Restart

• Subscriber is responsible for recreating subscriptions on restart,

• Consumer is responsible for Detecting Loss– Check Status– Heartbeat

• Consumer must know Subscriber!

© 2004Kizoom

50

Subscription Management

• Roles “Stateful pattern of interaction”– Subscriber assigns identifier– Notification Producer grants new subscriptions– Subscription manager handles any changes

• Notification Producer & Manager know each other

• Management Messages– SubscriptionRequest

• SubscriptionIdentifier

– SubscriptionResponse• Granted or refused

– TerminateSubscriptionRequest

© 2004Kizoom

51

Extensions

• Access Control– Well defined Capabilities– Request based Checking

• Discovery– Capability– Coverage

• Stops• Lines• Product, Service, Vehicle - Features /Attributes ?

© 2004Kizoom

52

Access Controls

• Optional Capability on Requests– By ParticipantCode

• Configuration Matrix• Restrict By

– By Function &/or Capability (Static)• E.g. Stop Events, Vehicle Movements

– E.g. Subscribe, detail level – By Topic (Dynamic)

• E.g. Certain Stops, Certain Lines

– By Resource level (Dynamic)

© 2004Kizoom

53

Appendix

© 2004Kizoom

54

Technical Challenges

• How to give migration path from existing standards– VDV, RTIG, TRIDENT– Allow alternative delivery patterns– Allow alternative formats for some detailed response messages

where necessary. Semantically identical.– Allow modular, incremental implementation: roadmap

• What is canonical TransModel XML?– Trident XML not being kept current

• Further improvements in TransModel since Trident• New developments/standards in XML / WS technology• Further application requirements for SIRI

• What real-time efficiency optimisations are needed?– Principle of strict Transmodel Isomorphism ?– Allow different message patterns and tradeoffs

© 2004Kizoom

55

Acceptable Optimisations =TransModel Isomorphic?

A

B

F

C

D

*

*

Bs

Cs

E

G *

1 1

A

X(C+D+E)

* Cs

G

1

1

1

1

*

A

B

C

D

*

*

Bs

Cs

E

G

*

1

1

1

1

OK NOT OK

Compression

Compounding

*

© 2004Kizoom

56

SIRI Data Models • TransModel based; Small Subset • Common Concepts& Elements

– Participants (Systems)– StopPoints (Pluggable to national systems)– Lines, Directions– Journeys,

• VehicleJourneys & Calls• DatedVehicleJourneys & Calls• MonitoredVehcielJourneys & Calls• ConnectingJourneys

– Features• Service• Vehicle• Product

• Common Structures– Isomorphic optimisations of TransModel for use in

interface

© 2004Kizoom

57

Example Stop Monitoring Request

<ServiceRequest> • <RequestorRef>NADER</RequestorRef>• <RequestTimestamp>2004-12-17T09:30:47-05:00</RequestTimestamp>• <StopMonitoringRequest version=“1.0”>• <!-- All services from stop EH00001 in the next 30 mins-->• <RequestTimestamp>2004-12-17T09:30:47-05:00</

RequestTimestamp>• <!--=======TOPIC ======= -->• <PreviewInterval>P30M</PreviewInterval>• <MonitoringRef>EH00001</MonitoringRef>• <!--=======POLICY===========-->• <MaximumStopVisits>7</MaximumStopVisits>• <MinimumStopVisitsPerLine>2</MinimumStopVisitsPerLine>• <StopMonitoringDetailLevel>normal</StopMonitoringDetailLevel>• </StopMonitoringRequest></ServiceRequest>

© 2004Kizoom

58

Example Stop Monitoring Delivery• <StopMonitoringDelivery version="0.1d">• <ResponseTimestamp>2004-12-17T09:30:47-05:00</ResponseTimestamp>• <SubscriberRef>NADER</SubscriberRef>• <SubscriptionRef>2004-12-17T09:30:47-05:00</SubscriptionRef> • <!--====FIRST ARRIVAL ============================================ -->• <MonitoredStopVisit>• <RecordedAtTime>2004-12-17T09:25:46-05:00</RecordedAtTime>• <MonitoringRef>HLTST011</MonitoringRef>• <MonitoredVehicleJourney> • <LineRef>Line123</LineRef>• <DirectionRef>Out</DirectionRef>• <FramedVehicleJourneyRef>• <DataFrameRef>2004-12-17</DataFrameRef>• <DatedVehicleJourneyRef>034567</DatedVehicleJourneyRef>• </FramedVehicleJourneyRef> • <PublishedLineName>123</PublishedLineName>• <DestinationName>Paradise Park</DestinationName> • <VehicleRef>VEH987654</VehicleRef>• <MonitoredCall>• <VisitNumber>0014</VisitNumber>• <VehicleAtStop>false</VehicleAtStop> • <AimedArrivalTime>2004-12-17T09:40:44-05:00</AimedArrivalTime>• <ExpectedArrivalTime>2004-12-17T09:40:46-05:00</ExpectedArrivalTime>• <AimedDepartureTime>2004-12-17T09:42:47-05:00</AimedDepartureTime>• <ExpectedDepartureTime>2004-12-17T09:40:47-05:00</ExpectedDepartureTime>• </MonitoredCall> • </MonitoredVehicleJourney>• </MonitoredStopVisit>• ……..• </StopMonitoringDelivery>