SIRI Handbook & Functional Service Diagrams - Easily...

.

Kizoom Limited, 109-123 Clifton Street, London EC2A 4LD. Tel: +44 207 749 2670

SIRI Handbook

& Functional Service Diagrams

Version 0.13

2008/01/10 Njsk Kizoom

DRAFT

SIRI Functional Services - UML Diagrams

© Copyright Kizoom 2006-2007

Control sheet

Version control

Date Author Version Description of changes

2006/03/02 Nick Knowles, V.01 Previous Draft

2007/04/15 Nick Knowles, V.02 Word Draft

2007/10/11 Nick Knowles, V.07 Word Draft

2008/01/11 Nick Knowles, V.12 Revised Draft

2008/01/11 Nick Knowles, V.14 Revised Draft

Document automation & Copyright notice

Kizoom Ltd 107-109 Clifton Street, London EC2A 4LD

Telephone: 207 749 2670

Company Registration Number : 3745127

© Copyright 2007, 2008 Kizoom Limited:

All rights Reserved.

Author:

Nicholas Knowles



Table of Contents

1. Introduction.................................................................................................................................... 8

Acknowledgements ........................................................................................................................ 8

References ..................................................................................................................................... 8

2. Introduction to SIRI ...................................................................................................................... 10

What is SIRI? ................................................................................................................................ 10

What Functional Services are available? ....................................................................................... 11

3. Use of SIRI Services....................................................................................................................... 13

Separation of Concerns................................................................................................................. 14

Communications & message transport ........................................................................................ 14

Roles & Patterns of Interaction ..................................................................................................... 14

Request/Response for a SIRI Functional SERVICE ........................................................................ 15

Publish/Subscribe for a SIRI Functional SERVICE.......................................................................... 15

Publish/Subscribe with Separate Notification & Fetched Delivery .............................................. 16

XML Example of a SIRI Functional Service Request & Delivery ....................................................... 16

Stop Monitoring Request Example............................................................................................... 17

Stop Monitoring Request Delivery Example................................................................................. 17

Stop Monitoring Subscription Request Example.......................................................................... 18

Stop Monitoring Subscription Delivery Example.......................................................................... 18

SIRI & Transmodel ........................................................................................................................ 20

Relationship of SIRI to TRANSMODEL........................................................................................... 20

Transmodel entities relevant for SIRI........................................................................................... 21

Stop Places - SIRI & IFOPT ............................................................................................................. 23

Participant identifiers, Message & Subscription Management....................................................... 24

Request Response Entities & Message Elements......................................................................... 24

publish Subscribe message elements........................................................................................... 26

Recovery & Restart....................................................................................................................... 28

What does a SIRI Implementation require? ................................................................................... 28

4. Service Descriptions ..................................................................................................................... 29



Organisation................................................................................................................................. 29

Functional Requests & responses.................................................................................................. 29

5. SIRI Stop Monitoring (SM)............................................................................................................ 31

SIRI-SM: Subscription & Request................................................................................................... 31

StopMonitoringRequest Summary ............................................................................................... 31

StopMonitoringRequest Detail ..................................................................................................... 32

SIRI-SM: Delivery .......................................................................................................................... 33

StopMonitoringDelivery Summary ............................................................................................... 33

StopMonitoringDelivery Detail ..................................................................................................... 34

Use of MonitoredVehicleJourney Element for SIRI-SM................................................................ 36

Examples of Live services that USe SIRI-SM................................................................................... 40

Map based web departure boards............................................................................................... 40

WAP mobile departure boards..................................................................................................... 40

SMS departure boards.................................................................................................................. 40

6. SIRI Vehicle Monitoring (VM) ....................................................................................................... 41

SIRI-VM: Subscription & Request .................................................................................................. 41

VehicleMonitoringRequest Summary........................................................................................... 41

VehicleMonitoringRequest Detail................................................................................................. 42

SIRI-VM: Delivery.......................................................................................................................... 43

VehicleMonitoringDelivery Summary........................................................................................... 43

Use of MonitoredVehicleJourney Element for SIRI-VM ............................................................... 44

VehicleMonitoringDelivery Detail................................................................................................. 45

7. SIRI ProductionTimetable (PT) ...................................................................................................... 46

SIRI-PT: Subscription & Request.................................................................................................... 46

ProductionTimetableRequest Summary....................................................................................... 46

ProductionTimetableRequest Detail............................................................................................. 47

SIRI-PT: Delivery ........................................................................................................................... 48

ProductionTimetableDelivery Summary....................................................................................... 48

ProductionTimetableDelivery Detail............................................................................................. 49



8. SIRI EstimatedTimetable (ET) ....................................................................................................... 50

SIRI-ET: Subscription & Request .................................................................................................... 50

EstimatedTimetableRequest Summary ........................................................................................ 50

EstimatedTimetableRequest Detail .............................................................................................. 51

SIRI-ET: Delivery ........................................................................................................................... 51

EstimatedTimetableDelivery Summary ........................................................................................ 52

EstimatedTimetableDelivery Detail .............................................................................................. 53

9. SIRI Stop Timetable (ST)................................................................................................................ 54

SIRI-ST: Subscription & Request .................................................................................................... 54

StopTimetableRequest Summary ................................................................................................. 54

StopTimetableRequest Detail ....................................................................................................... 55

SIRI-ST: Delivery ........................................................................................................................... 56

StopTimetableDelivery Summary ................................................................................................. 56

StopTimetableDelivery Detail ....................................................................................................... 57

10. SIRI ConnectionTimetable (CT) ..................................................................................................... 58

SIRI-CT: Subscription & Request.................................................................................................... 58

ConnectionTimetableRequest Summary ...................................................................................... 58

ConnectionTimetableRequest Detail ............................................................................................ 59

SIRI-CT: Delivery ........................................................................................................................... 60

ConnectionTimetableDelivery Summary ...................................................................................... 60

ConnectionTimetableDelivery Detail ............................................................................................ 61

11. SIRI ConnectionMonitoring (CM).................................................................................................. 62

SIRI-CM: Subscription & Request .................................................................................................. 62

ConnectionMonitoringRequest Summary .................................................................................... 62

ConnectionMonitoringRequest Detail .......................................................................................... 63

SIRI-CM: Delivery.......................................................................................................................... 63

ConnectionMonitoringDelivery Summary .................................................................................... 64

ConnectionMonitoringDelivery Detail .......................................................................................... 65

12. SIRI GeneralMessage (GM)........................................................................................................... 66



SIRI-GM: Subscription & Request .................................................................................................. 66

GeneralMessageRequest Summary.............................................................................................. 66

GeneralMessageRequest Detail ................................................................................................... 67

SIRI-GM: Delivery ......................................................................................................................... 68

GeneralMessageDelivery Summary ............................................................................................. 68

GeneralMessageDelivery Detail ................................................................................................... 69

13. SIRI FacilityMonitoring (FM) DRAFT ............................................................................................. 70

SIRI-FM: Subscription & Request................................................................................................... 70

FacilityMonitoringRequest Summary ........................................................................................... 70

FacilityMonitoringRequest Detail ................................................................................................. 70

SIRI-FM: Delivery .......................................................................................................................... 70

FacilityMonitoringDelviery Summary ........................................................................................... 70

FacilityMonitoringDelviery Detail ................................................................................................. 70

14. SIRI SituationExchange (SX) DRAFT .............................................................................................. 71

SIRI-SX: Subscription & Request.................................................................................................... 71

SituationExchangeRequest Summary........................................................................................... 71

SituationExchangeRequest Detail................................................................................................. 72

SIRI-SX: Delivery ........................................................................................................................... 72

SituationExchangeDelivery Summary........................................................................................... 73

SituationExchangeDelivery Detail................................................................................................. 74

Situation Model............................................................................................................................ 75

15. SIRI Common Data Types ............................................................................................................. 80

Common SIRI Data Types XML Simple Types............................................................................... 80

Common SIRI Data Types .............................................................................................................. 80

Common SIRI SImPLE Data Types Codes & Identifiers ................................................................. 81

Common General SIRI Enumerations............................................................................................. 82

SIRI-SX Enumerations ................................................................................................................... 83

IFOPT Enumerations for SIRI-SX .................................................................................................... 84

TPEG Miscellaneous Enumerations for SIRI-SX ............................................................................... 85



TPEG Mode Enumerations ............................................................................................................ 86

16. Annex A Notation ......................................................................................................................... 87

Entities......................................................................................................................................... 87

Enumerations ............................................................................................................................... 87

Groups ......................................................................................................................................... 87

Notes ........................................................................................................................................... 87

Relationships................................................................................................................................ 87

Use of Colour................................................................................................................................ 88

Serialisation: Containment & Reference........................................................................................ 88

Alternative Representations of XML Strcutures in UML .............................................................. 89

XML Fragment for Example.......................................................................................................... 91

Order of Attributes ....................................................................................................................... 92

Direction of Reading ..................................................................................................................... 92

Simple Data Types ........................................................................................................................ 92

Reusable Complex Data Types ...................................................................................................... 92



1. INTRODUCTION

This SIRI Handbook provides a short overview of the CEN SIRI (Service Interface for Real Time Information) technical specification and of the individual SIRI functional services.

It is intended to provide both an introduction to SIRI for technical readers and a quick reference guide for developers who are already familiar with SIRI, but wish to check particular points of detail. It does not cover a number of more detailed aspects of SIRI (for example capability discovery, access controls, etc).

A particular purpose of the handbook is to illustrate the relationship between SIRI and Transmodel by diagramming the SIRI message content in such a way that the reference to Transmodel elements is explicit.

Another goal of this handbook is make understanding a simple use of SIRI for common applications as accessible as possible. As a technical standard intended to support many different implementations and countries, and many different applications and usages, SIRI has a large number of features and optional capabilities. Consequently it requires a large specification. Nonetheless, commonly required basic real-time services, such as stop departures or timetable exchange can be understood and implemented simply in SIRI, and this guide is intended to highlight such straightforward uses.

The guide assumes a technical knowledge of XML and web services. and of data modelling with UML notation.

ACKNOWLEDGEMENTS

This document is based on the SIRI technical specification which was developed with sponsorship from VDV, RTIG, Department of Transport and other organizations.

This handbook & diagrams have been prepared & provided by Kizoom.

REFERENCES

SIRI Specification Service interface for real-time information relating to public transport operations

o CEN/TS 00278181-1 Part 1: Introduction

o CEN/TS 00278181-2 Part 2: Communications infrastructure

o CEN/TS 00278181-3 Part 3: Functional Service Interfaces

SIRI Schema

o http://www.siri.org.uk/schema/1.2/siri.xsd

SIRI White Paper

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

http://www.siri.org.uk/schema/1.2/siri.xsd

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



Transmodel

o CEN TC 278 ENV 12896 Reference Data Model for Public Transport

IFOPT

o CEN/TS 00278207 Identification of Fixed Objects in Public Transport

TPEG



2. INTRODUCTION TO SIRI

WHAT IS SIRI?

SIRI specifies a European data interface standard for exchanging information about the planned, current or projected performance of real-time public transport operations between different computer systems.

SIRI comprises a modular set of discrete functional services for exchanging data for public transport information systems. Services cover planned and real time timetable exchange; vehicle activity at stops; vehicle movement; and information to assist in the provision of reliable connections between vehicles. Services may be implemented and used individually.

SIRI aims to incorporate of the best of various national and proprietary standards from across Europe and deliver these as web services using a modern XML schema.

The services assume a standard conceptual model for the data to be exchanged, based on the CEN Transmodel data reference model. Element names and data structures are based on this model. SIRI was developed for bus data, but can be used just as well for other modes of transport such as Rail and Air.

All SIRI services are provided over a standardised Communications layer, based on a Web Services Architecture.

o The Communications layer upholds a consistent approach for all the functional services to Security, Authentication, Version Negotiation, Recovery/Restart, and Access Control/Filtering.

o To support different operating requirements, two main patterns of interactions are supported: an immediate Request/Response protocol; and an asynchronous Publish/Subscribe protocol. The Publish/Subscribe can be further elaborated with a fetched delivery interaction to optimise the use of bandwidth.

Figure 2-1 SIRI Services



WHAT FUNCTIONAL SERVICES ARE AVAILABLE?

SIRI currently comprises the following functional services (See Figure 2-1):

Stop Timetable (ST) and Stop Monitoring services (SM) provide stop-centric information about current and forthcoming vehicle arrivals and departures at a nominated stop or Monitoring Point, typically for departures within the next 20-60 minutes for display to the public.

o The SM service is suited in particular for providing departure boards for web services and on all forms of device.

Vehicle Monitoring service (VM) provides information about of the current location and expected activities of a particular vehicle, and can give the current and subsequent Journey and the Calling points on each journey, together with the scheduled and expected arrival times.

o The VM service is suited in particular for onboard displays, and visualisation of vehicle movement, and for exchanging information on roaming vehicles between different control systems. It can be used for example to support a moving image showing the position of a bus on a map.

o It also constitutes a detailed logging feed suitable for collecting historic about performance against schedule.

Production Timetable service (PT) exchanges information about the expected operation of a transport network for a specified day in the near future.

o Typically this is produced a few hours or days before the day in question and incorporates any changes to the timetables known at that stage. It can of course also be used to distributed timetables long in advance.

o A Production Timetable can be filtered by Operator, Line and Date Range, allowing only the section of the timetable of interest to be selected.

o Suited for provisioning AVL systems and smart devices with base timetables.

Estimated Timetable service (ET) provides details of the operation of the transport network for a period within the current day, detailing real time deviations from the timetables and control actions affecting the Timetable (cancellations, additional Journeys and Detours).

o An estimated timetable can be filtered by Operator or by Line, allowing only the section of the timetable that is of interest to be selected.

o Suited for provisioning AVL systems and smart devices with real-time timetables.

o Also suitable for the bulk exchange of data.

Connection Timetable (CT) and Connection Monitoring service (CM) allow transport operators to exchange information about the real-time management of interchanges between feeder and distributor vehicles arriving and departing at a connection point, for example, to let passengers on a delayed train know that a local bus service will wait for them.



o It can be used in particular for Guaranteed Interchange ( Connection protection ) services.

General Messaging Service (GM) provides a structured way to exchange arbitrary informative messages between participants, such as travel news, or operational advice.

o It can be used to link together incident management systems in a store and forward architecture.

Two Further services are under development as SIRI version 1.3

Facilities Monitoring Service (FM) provides a information about changes in availability of equipment.

It can be used to link together equipment and incident management systems in a store and forward architecture.

Situation Exchange Service (SE) provides a fully featured service for exchanging planned and unplanned incidents between control centres and distribution systems.

It includes a structured incident model can be used to integrate incident incident management systems with other SIRI services and with external services



3. USE OF SIRI SERVICES

All the SIRI Functional services follow a common design pattern.

SIRI is for the exchange of data between participant services. The server which provides the data is the Producer. The server which obtains the data is the Consumer.

The same servers may sustain more than one different SIRI functional service, and support either or both Consumer and Producer roles as appropriate. The Producer service itself may be broken down into further roles (e.g. publisher, notification producer) though a Consumer does not need to be aware of these constituent roles.

Each functional service has unique endpoints, the addresses at which the service can be found.

Each Participant, whether consumer or producer, has a unique participant identifier.

Payload content is separated from message management content.

Content may be obtained from a Producer either by an immediate direct request /response interaction, or by an asynchronous publish / subscribe interaction. In both cases the same set of request parameters are supported to specify the desired response content; for a subscription the request is wrapped in an additional subscription request element.

Data exchanged by SIRI services may either be used as input to other computations, or be rendered into end user information views in any one of a number of media: e.g. web (HTML, javascript, etc) , WAP (xHTML), SMS, Smartphones (j2ME, etc) nor Voice (VML etc).

Figure 3-1 illustrates the concept of using multiple SIRI services to connect up different types of PT Information application, for example AVMS, Journey Planners, Incident Capture systems, Web delivery of stop departure and incidents, alerts, etc

5

Example use of SIRI Services

AVMS

JP

ICS ICS Alerts

PTET

STSM

GMSGMS

GMS GMS

PT

AVMS

PTET

STSM

Web& Mobile

SM

ET

SM

SM

GMS

GMS

ETVM

VM

Figure 3-1 Example of use of Services



Another common use of SIRI would be to separate the load of the real-time systems that manage and operate the public transport from the wider passenger information systems that distribute the data. Thus for example, a SIRI push service could send real-time predictions from the AVMS system to a separate service that supports passenger queries by web and mobile. This allows the latter to be scaled without affecting the reliability of the operational system.

SEPARATION OF CONCERNS

SIRI is designed to separate different software architectural concerns, in particular for communications/content and for scaling.

COMMUNICATIONS & MESSAGE TRANSPORT

SIRI separates message content from message transport related elements so that it may be used with different methods of communication, for example XML over http, XML over SOAP/WSDL. Although a default method of http is currently used, it would be possible to use the SIRI content model, with quite different transport for example TCP IP sockets.

In order to specify an individual SIRI functional service (or indeed any web service), three different aspects of the service need to be specified; (i) the data content model for SIRI based on Transmodel; (ii) the Communications Transport protocol used to serialise and exchange messages (for example, http & XML) and; (iii) the exchange behaviour the rules for use of the each functional protocol as a dynamic sequence of messages subject to certain application dependent behaviour. Figure 3-2 illustrates the concept of separation of concerns. In SIRI the Data content is described as XML messages. In addition, the variables controlling the parameterised parts of the exchange behaviour are specified as XML values in a configuration or capability description.

4

Separation of concerns

DataContent

ExchangeBehaviour

TransportProtocol

well-defined interactionswith XML schemaRepresentations

parameterising behaviour

Independent e.g.HTTP POST,

SOAP.

definedXML SchemaFor payload

Figure 3-2 Separation of Concerns

ROLES & PATTERNS OF INTERACTION

SIRI can be regarded as a software framework: all the SIRI Functional Services are based on common patterns of interaction, populated with specific messages and data elements specific to a particular service. These patterns distinguish the various software roles which occur in real-time data exchange, for example Consumer, Producer, Notification Producer, Subscriber - even if these are combined on a single server for a particular implementation. The main patterns can be summarized as follows:

Functional Service Request Response.



Functional Service Subscription with asynchronous Direct Delivery.

Functional Service Subscription with asynchronous Notification & Fetched Delivery.

REQUEST/ RESPONSE FOR A SIRI FUNCTIONAL SERVICE

For the Request / Response interaction, the Consumer makes a Functional Service Request to the Producer, and receives a Functional Service Delivery message in response. The Functional Service Request may state the filtering criteria as Topics (the desired domain element references) and Policies (criteria as to how the results are to be filtered. The Topics and Policies depend on the specific functional service.

Figure 3-3 Sequence Diagram of Request Response Interaction

A Functional Service Request is always for a specific SIRI service, e.g. Stop Monitoring, General Message, etc. Note that the request / response pattern is also widely in SIRI for the exchange of information as pairs of messages, for example for status checking, to create subscriptions, etc.

PUBLISH/ SUBSCRIBE FOR A SIRI FUNCTIONAL SERVICE

For the Publish / Subscribe interaction, a Subscriber makes a Subscription Request to the Producer, which creates a Subscription for a Consumer (usually but not necessarily the same server as the Consumer) for the requested lease period for a specified Functional Service Request and Subscription Policy The Producer will subsequently send one or more asynchronous Delivery messages if the Request criteria are met and continue doing so in accordance with the subscription policy, up to the end of the lease. The Filtering criteria can include change thresholds or hysteresis values. The Subscription will eventually expire or be terminated.



Figure 3-4 Sequence Diagram of Publish Subscribe Interaction

PUBLISH/ SUBSCRIBE WITH SEPARATE NOTIFICATION & FETCHED DELIVERY

In the simplest use, SIRI services follow of the normal web service paradigm of direct delivery, returning content in response to a request or a subscription. To allow additional optimisation of bandwidth and device queuing, and to provide compatibility with legacy systems, SIRI also supports an additional delivery variant of fetched delivery in which data is returned in two steps: first a notification message from Producer to Consumer that data is available, then a Request/ Response interaction from Consumer to Producer to fetch the data using a delivery message. The payload content of the delivery message is the same as for the delivery of a direct response

Subscriber NotificationProducer NotificationConsumer

SubscriptionRequest(XxxSubscription)

Publish / Subscribe With Fetched Delivery

Subscription Manager

terminate

DataReadyResponse

DataReadyNotification

DataSupplyRequest

DataSupplyDelivery

SubscriptionResponse

TerminationRequest

TerminationResponse

Figure 3-5 Sequence Diagram of Publish Subscribe Interaction with Fetched Delivery

XML EXAMPLE OF A SIRI FUNCTIONAL SERVICE REQUEST & DELIVERY

The following two XML code fragments illustrate a request/response message pair for a Functional Service - the SIRI-SM Stop Monitoring service, populated to support a simple departure board.

STOP MONITORING REQUEST EXAMPLE

The following is an example of a StopMonitoringRequest. The request consists of a standard header, which is similar for all SIRI requests, and then Topics and Policies that are specific to the SIRI-SM functional service. The request asks for the departures for a stop HLTST011 . The response is to contain up to seven vehicle journeys at the stop, as set by the policy. If there are more than seven available, then only the first two for each line will be shown.

<ServiceRequest>

<RequestorRef>NADER</RequestorRef>

<RequestTimestamp>2004-12-17T09:30:47-05:00</RequestTimestamp>

<StopMonitoringRequest version= 1.0 >




<MessageIdentifier>NDR06756</MessageIdentifier>



<PreviewInterval>P30M</PreviewInterval>

<MonitoringRef> HLTST011</MonitoringRef>



<MaximumStopVisits>7</MaximumStopVisits>

<MinimumStopVisitsPerLine>2</MinimumStopVisitsPerLine>

<StopMonitoringDetailLevel>normal</StopMonitoringDetailLevel>

</StopMonitoringRequest>

</ServiceRequest>

STOP MONITORING REQUEST DELIVERY EXAMPLE

The following is an example of a StopMonitoringDelivery in response to a StopMonitoringRequest. It shows a single StopVisit for a detail level of Normal. The delivery consists of a standard header, which is similar for all SIRI requests, and then payload that is specific to the functional service.

<ServiceDelivery>



<ResponseTimestamp>2004-12-17T09:30:46-05:00</ResponseTimestamp>

<ProducerRef>KUBRICK</ProducerRef>



<StopMonitoringDelivery version="0.1d">


<RequestMessageRef>NDR06756</RequestMessageRef>



<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>03567</DatedVehicleJourneyRef>

</FramedVehicleJourneyRef>

<PublishedLineName>123</PublishedLineName>

<DestinationName>Paradise Park</DestinationName>

<VehicleRef>VEH987654</VehicleRef>

<! CALL AT STOP -->

<MonitoredCall>

<VisitNumber>0014</VisitNumber>

<VehicleAtStop>false</VehicleAtStop>



<AimedArrivalTime>2004-12-17T09:40:46-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>

<NextStopPointRef>HLTST012</NextStopPointRef>

</MonitoredVehicleJourney>

</MonitoredStopVisit>

</StopMonitoringDelivery>

</ServiceDelivery>

STOP MONITORING SUBSCRIPTION REQUEST EXAMPLE

The following further example shows a StopMonitoringSubscriptionRequest to set up a subscription to be sent updates for a stop asynchronously. It embeds a StopMonitoringRequest which specifies the selection criteria - to see all departures for LINE23 from stop POIT5678 for up to 30 minutes ahead, including the calling pattern. It adds some values to set the subscription policy: updates are only sent if the values have changed by more than 2 Minutes. The producer would return

<SubscriptionRequest>

<RequestorRef>NADER</RequestorRef>




<StopMonitoringSubscriptionRequest>

<SubscriptionIdentifier>000235</SubscriptionIdentifier>

<InitialTerminationTime>2004-12-17T15:30:47-05:01</InitialTerminationTime>

<StopMonitoringRequest version= 1.0 >




<PreviewInterval>PT30M</PreviewInterval>

<MonitoringRef>POIT5678</MonitoringRef>

<LineRef>LINE23</LineRef>



<StopMonitoringDetailLevel>calls</StopMonitoringDetailLevel>

</StopMonitoringRequest>

<! SUBSCRIPTION POLICY -->

<ChangeBeforeUpdates>PT2M</ChangeBeforeUpdates>

</StopMonitoringSubscriptionRequest>

</SubscriptionRequest>

STOP MONITORING SUBSCRIPTION DELIVERY EXAMPLE

The following is an example of a StopMonitoringDelivery in response to a StopMonitoring-SubscriptionRequest. It is almost identical to the earlier response to a StopMonitoringRequest, but also includes subscription identifier data.

<ServiceDelivery>

<ProducerRef>KUBRICK</ProducerRef>



<StopMonitoringDelivery version="0.1d">


<SubscriberRef>NADER</SubscriberRef>

<SubscriptionRef>2004-12-17T09:30:47-05:00</SubscriptionRef>

<ValidUntil>2004-12-17T09:30:47-05:00</ValidUntil>



<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>03567</DatedVehicleJourneyRef>

</FramedVehicleJourneyRef>



<PublishedLineName>123</PublishedLineName>

<DestinationName>Paradise Park</DestinationName>

<VehicleRef>VEH987654</VehicleRef>

<! CALL AT STOP -->

<MonitoredCall>

<VisitNumber>0014</VisitNumber>

<VehicleAtStop>false</VehicleAtStop>




<ExpectedArrivalTime>2004-12-17T09:40:46-05:00</ExpectedArrivalTime>


<ExpectedDepartureTime>2004-12-17T09:40:47-05:00</ExpectedDepartureTime>

</MonitoredCall>

<NextStopPointRef>HLTST012</NextStopPointRef>

</MonitoredVehicleJourney>

</MonitoredStopVisit>

</StopMonitoringDelivery>

</ServiceDelivery>



SIRI & TRANSMODEL

The payload

content of SIRI messages is intended to be compatible with Transmodel, the CEN

Reference Data Model for Public Transport, which sets out common terminology and data abstractions for representing public transport information systems. Thus it should be possible to map data readily from a Transmodel compliant database or application into SIRI messages for data exchange and vice versa, and someone familiar with Transmodel should be able to recognize the application payload elements of the SIRI content model.

SIRI uses Transmodel terms and data elements wherever they exist, and assumes the same cardinalities as Transmodel for any associations between elements.

In some cases, SIRI introduces additional elements or attributes for additional concepts not yet in Transmodel. Mostly this consists of adding additional attributes to existing Transmodel concepts.

In certain other cases, additional elements are introduced in SIRI for convenience to group existing elements, for example, a SIRI Call

element groups the Transmodel entities STOP IN SEQUENCE, various PASSING TIMEs, and other additional attributes. These additional elements do not break conformity with Transmodel but can be regarded as implementation views.

RELATIONSHIP OF SIRI TO TRANSMODEL

Although SIRI is based on Transmodel, there is nonetheless some subtlety involved in understanding the mapping of SIRI content onto Transmodel. Most SIRI functional services are only concerned with exchanging small parts of the information models described by Transmodel - and need to perform this exchange efficiently in real-time. The serialisation of the abstract Transmodel content model into concrete SIRI messages is therefore selective: only those specific elements that are needed for each particular functional service are included; often these will be just the changes to a previously established data set, rather than the full data set. As a consequence, SIRI message content cannot and should not be read as a full or canonical representation of Transmodel, even for the subset of it with which it is concerned. Nor can all the associations of Transmodel be discerned from just their use in SIRI messages.

When exchanging real-time information, there is frequently a need to exchange just one or two properties of an associated entity without exchanging the full definition of that entity. For example, when exchanging information about a vehicle journey it may be useful to know certain attributes of its journey pattern - or of the attributes that can be found though knowledge of that journey pattern by navigating the associations from the vehicle journey to its related entities and onwards. Similarly when exchanging a real-time data for a Call at a stop, it may be useful to include the stop name even though this is properly part of a separate Stop Point entity and could be found through the with a stop point identifier on the call element. To handle this practical requirement, SIRI makes use of groups of elements that include the necessary identifiers of the referenced entities, annotated with selected attributes. In a few cases in SIRI these groupings are implemented as additional entities, for example a SIRI Call. In most other cases the SIRI XMl schema simply includes groups of attributes from associated elements at the appropriate point in payload content (indicated in diagrams by a <<group>> stereotype). Again, such groups should be regarded as implementation artefacts, i.e. views of small parts of the Transmodel model that are



introduced for convenience, derived through Transmodel associations and which can be mapped back to a full Transmodel representation on source and destination systems.

There is also a need to support different levels of detail for population of the message content for different applications and different implementations. For example, some departure boards will show just a single departure time for each service, others will wish to show for each service a full calling pattern for all previous and onwards stops, with arrival and departure times at each destination. Most attributes and associations are therefore optional in SIRI messages, even if they are mandatory in the underlying data model.

Some SIRI services are designed to exchange or differences in values to previously exchanged values, or in some cases differences that differ by more than an agreed amount.

To some extent the ordering and nesting of elements has been constrained by a requirement to enable a straightforward migration from legacy standards, in particular VDV453 and VDV454, upon which many of the SIRI services are based.

Since SIRI was developed as a harmonisation of existing working national standards that reflect many actual real-time implementation requirements, SIRI is not perfectly uniform in its design or its expression of Transmodel concepts. Nonetheless it achieves a close and useful correspondence.

TRANSMODEL ENTITIES RELEVANT FOR SIRI

Figure 3-6 shows some key Transmodel schedule related entities that are relevant for SIRI message content, including a couple of SIRI artefacts (for example, DatedCall, and VehicleJourneyInfo).

TM-Mdl::JourneyPattern

TM-Mdl::Route

TM-Mdl::Block

TM-Mdl::CourseOfJourney

«group»TM-Mdl::StopPointInSequence

0..*

1

at

1

2..*

stops

TM-Mdl::ServicePattern

0..*

0..1

run

0..*

0..1 pattern

0..*

0..1

block

1

*

runs

1

0..*

stops

1

0..*

route 1

0..*

route

1

0..*

line

1

0..1

info

TM-Mdl::PassingTime

Siri Mdl::DatedCall

1

2..*

calls

0..*

0..1

stop point1

* time

1

0..*

passing times

1

*

service pattern

SIRI - Summary of relevant Transmodel entities

© 2007 SIRI

TM-Mdl::VehicleJourney

TM-Mdl::Line

TM-Mdl::DatedVehicleJourney

TM-Mdl::StopPoint

«group»Siri Mdl::VehicleJourneyInfo

0..*

0..1destination

0..*

0..1

origin

Siri Mdl::MonitoredVehicleJourney

Figure 3-6 Transmodel entities relevant for SIRI



See the Transmodel specification for full definitions. The following notes outline the relevance of some key elements:

A VEHICLE JOURNEY describes a timetabled journey on a public transport route that runs regularly at a particular time: a DATED VEHICLE JOURNEY is a planned journey run on a specific date.

A VEHICLE JOURNEY follows a JOURNEY PATTERN, which specifies a particular sequence of stops and timings for covering the links between them. A JOURNEY PATTERN may be a specific instance of a more general SERVICE PATTERN associated with a ROUTE, a particular sequence of stops independent of timing. The sequence of STOP POINTs IN SEQUENCE of such patterns identifies the STOP POINTs and order of visit of stops of the vehicle journey. A VEHICLE JOURNEY will have PASSING TIMEs at each stop point. Most SIRI services are concerned primarily with the individual VEHICLE JOURNEYs (in effect a column of a timetable) rather than with the JOURNEY PATTERN, which is typically shared between many journeys of a timetable. However it is sometimes useful to be able to determine the JOURNEY PATTERN in order to access common shared properties of a service, so SIRI messages generally allow the specification of the identifier of the JOURNEY PATTERN of the VEHICLE JOURNEY.

SIRI groups together the set of passing times and other real-time attributes of a vehicle calling at a stop point as part of a vehicle journey as a Call.

A dated vehicle journey that is being tracked and monitored by an AVL system (and so for which real time data may be available) is a MONITORED VEHICLE JOURNEY.

An important point to note is that the labelling of groups of VEHICLE JOURNEYs as belonging to a named LINE (as marketed to the public) and that make up a timetable is independent of any individual journey and may be quite arbitrary: different journeys of the LINE may follow different journey patterns that follow different branches, or that omit stops on some journeys.

For vehicle and crew scheduling, a DATED VEHICLE JOURNEY may be linked up end-to-end with other dated vehicle journeys to make a BLOCK, comprising one or more runs

or in Transmodel terminology, COURSE OF JOURNEYs. Real-time messages may want to include these references to support operational management systems.

The SIRI VehicleJourneyInfo group is a named subset of particular VEHICLE JOURNEY attributes which are often required in SIRI content to give context to real time data for a journey. It is shown with a <<group>> stereotype to indicate that in concrete implementations they are embedded in-line. Similar groupings exist for JourneyPatternInfo etc

Other variant views of DATED VEHICLE JOURNEY used in SIRI, not shown in Figure 3-6, each including particular subsets of timetabled or real[time attributes include TargetedVehicle-Journey, EstimatedVehicleJourney, and InterchangeJourney.



STOP PLACES - SIRI & IFOPT

The CEN IFOPT (Identification of Fixed objects in Public Transport) technical specification extends Transmodel to describe the structure of STOP PLACEs that is, stations, bus stops, airports, and other points of access to transport. One point it clarifies is the distinction between a reference to a stop in a timetable (as a point in a journey pattern of a vehicle journey) a SCHEDULED STOP POINT, and its possible meanings for a real time application, which may be concerned variously with the STOP PLACE as (i) a group of stops; (ii) an individual QUAY i.e. platform, bay, berth, stop pole, etc within the STOP PLACE; or (iii) a BOARDING POSITION within a QUAY. This is summarised in Figure 3-7, which shows that a stop point in the timetable may be variously associated with different levels of detail within a stop place. In practice assignment of a SCHEDULED STOP POINT to a STOP PLACE is very done implicitly by using the same identifier for both, but it might be done more explicitly by an PASSENGER STOP POINT assignment.

Figure 3-7 IFOPT Stop Assignment

IFOPT was developed after the SIRI specification, but aspects of it are useful as a conceptual model for understanding SIRI s use of reference data. It will typically be up to specific applications and implementations to assign appropriate identifiers of stop points to SIRI message elements to reflect the groupings and correspondences for their own configuration. For example, a MonitoringRef of the SIRI Stop Monitoring service might refer to the STOP PLACE if it shows the whole departure board for a station or pair of stops, or to a QUAY if it shows just departures for a particular platform.

The SIRI-SX service was developed after the IFOPT specification and does make explicit use of IFOPT concepts to distinguish components of a STOP PLACE.



PARTICIPANT IDENTIFIERS, MESSAGE & SUBSCRIPTION MANAGEMENT

The requests and responses of SIRI functional services use a common set of header elements to track messages and subscriptions - see Figure 3-8.

Each Participant system is given a unique identifier. This ParticipantCode is used to provide uniqueness of reference for data entities from each system. It is used as the RequestorRef on request messages and the ProducerRef on response messages.

Each request message can be given an identifier by the requestor (MessageIdentifier) that is echoed back in the response (RequestMessageRef). This allows a requestor to match request and responses.

The Requestor needs to be configured to know the address, i.e. url to which new requests for a SIRI functional service are to be sent. The request can contain an EndPointAddress to which responses are to be sent.

All messages are timestamped with an identifier in UTC.

REQUEST RESPONSE ENTITIES & MESSAGE ELEMENTS

Figure 3-8 Illustrates the common elements involved in SIRI request/response interactions.

SIRI functional service requests are sent from a ConsumerService to a ProducerService, which returns a delivery which satisfies the request Topics and Policies

A ServiceRequest contains one or more SIRI functional requests for specific functional services; each concrete SIRI functional service request (SiriFsXXXRequest) inherits common properties from an AbstractFunctionalServiceRequest.

A ServiceDelivery contains one or more delivery elements for a specific SIRI functional service (SiriXxxFsDelivery) - or ErrorConditions if responses cannot be returned. Each SIRI functional service delivery inherits common properties from an Abstract-FunctionalServiceDelivery. (Note: Subscription attributes are not populated for deliveries for request/response).

The RequestMessageRef on the ServiceDelivery messages references the MessageIdentifier of a ServiceRequest to which it responds. The RequestMessageRef on each individual functional service delivery (SiriXxxFsDelivery) within the ServiceDelivery references a MessageIdentifier on the corresponding functional service request (SiriXxxFsRequest).



Figure 3-8 SIRI Request/Response entities



PUBLISH SUBSCRIBE MESSAGE ELEMENTS

Figure 3-8 Illustrates the common elements involved in SIRI publish/subscribe interactions.

The SubscribingService requests subscriptions from a SubscriptionManager associated with the ProducerService which creates and manages subscriptions.

Each subscription is given a unique identifier (SubscriptionCode) by the subscriber, which is specified on the subscription request for a specific SIRI functional service (SiriXxxFs-SubscriptionRequest) as the SubscriptionIdentifier, and then included on all deliveries sent back in response to that subscription. The identifier must be unique within the ParticipantCode of the subscriber (SubscriberRef).

One or more functional service subscription requests may be submitted at a time as part of a single SubscriptionRequest. All must be for the same type of service. In response to the subscription request, a SubscriptionResponse message is returned with a ResponseStatus containing the identifier of each functional service subscription (SubscriptionRef) and whether it has been successfully created.

A subscription request includes an InitialTerminationTime which specifies a desired lease period. This will be echoed back as the ValidUntil time on responses.

The ProducerService subsequently monitors the real-time feed and if the request criteria of the subscription are matched, creates deliveries that are sent by the ProducerService to the ConsumerService nominated on the subscription request. Each delivery message includes the subscription identifier (SubscriptionRef) and the ParticipantCode of the subscriber, termed the SubscriberRef.

The subscriber, consumer and producer service keep mirrored representations of the active subscriptions. Recovery from system failure or loss of connection is discussed separately below.

The SubscribingService requests needs to be configured to know the address i.e. url of the system to which new subscription requests are to be sent. The request can contain a ConsumerEndPointAddress to which delivery responses are to be sent and a distinct SubscriberEndPointAddress to which an acknowledgement for the subscription request is to be sent.

An optional capability of SIRI is to have a SubscriptionFilter that will group subscriptions from the same participant for the same type of service so that notifications and delivery data can be sent as a single message. Otherwise each subscription will give rise to separate notification and delivery messages.

All messages are timestamped with an identifier in UTC.



RequestTimestamp[1] : dateTimeMessageIdentifier[0..1] : MessageQualifier

AbstractFunctionalServiceRequest

ParticipantCode[1]LastUsedSituationNumber[0..1]

Siri Mdl::Participant

SubscriberRef[1] : ParticipantCodeSubscriptionIdentifier[1] : SubscriptionCodeInitialTerminationTime[1] : dateTime

AbstractFunctionalSubscriptionRequest

1

0..*

subscriber

SubscriberRef[1] : ParticipantCodeSubscriptionIdentifier[1] : SubscriptionCodeSubscriberEndPoint[1] : EndPointAddressConsumerEndPoint[1] : EndPointAddressValidUntil[1] : dateTime

SubscriptionResponseTimeStamp[1] : dateTimeRequestMessageRef[0..1] : MessageQualifierSubscriberRef[0..1] : ParticipantCodeSubscriptionFilterRef[0..1] : SubscriptionFilterCodeSubscriptionRef[0..1] : SubscriptionCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierStatus[0..1] : booleanErrorCondition[0..1] : ErrorConditionValidUntil[0..1] : dateTimeShortestPossibleCycle[0..1] : positiveDuration

AbstractFunctionalServiceDelivery

0..1

0..*

subscriber

0..1

0..*

fulfils

0..*

1

subscription

SiriXxxFsRequest

Topics, Policies

SubscriptionManager

ProducerRef[1] : ParticipantCodeEndPoint[1] : EndPointAddressLastUsedIdentifier[0..1] : MessageQualifier

ProducerService

10..*

manager for

1

0..*

subscriptions

creates

1

1serves

SiriXxxFsSubscriptionRequest

SiriXxxFsRequest, SubscriptionPolicy

FilterCode[1] : SubscriptionFilterCodeSubscriberRef[1] : ParticipantCode

SubscriptionFilter

1

*

filters

0..1

0..*

filter 0..1

0..*

filtered by

1

0..*

subscriber

1

0..*

producer

SubscriberRef[1] : ParticipantCodeEndpoint[1] : EndPointAddressLastUsedSubscription[1] : SubscriptionCode

SubscribingService

1

1

request

11

request

creates

* *

subscriber

SiriXxxFsDelivery

payload

SIRI Publish Subscribe Entities& Generic messages

© 2007 SIRI

matches

ConsumerRef[1] : ParticipantCodeConsumerEndPoint[1] : EndPointAddressLastUsedMessageIdentifier[1] : MessageQualifier

ConsumerService

0..1

1

consumer for

RecordedAtTime[1] : dateTime

AbstractItem

1

0..*

subscriptions

subscriber, consumer and producer serviceseach keep their own subscription store of active subscriptions.

SiriXxxItem

payload

1

*

contents

ResponseTimeStamp[1] : dateTimeAddress[0..1] : EndPointAddressResponderRef[0..1] : ParticipantCodeRequestMessageRef[0..1] : MessageQualifierResponseStatus[0..1] : ResponseStatusSubscriptionManagerAddress[0..1] : EndPointAddressServiceStartedTime[0..1] : dateTimeExtensions[0..1] : any

SubscriptionResponse

ResponseTimeStamp[1] : dateTimeRequestMessageRef[0..1] : MessageQualifierSubscriberRef[0..1] : ParticipantCodeSubscriptionFilterRef[0..1] : SubscriptionFilterCodeSubscriptionRef[0..1] : SubscriptionCodeStatus[0..1] : booleanErrorCondition[0..1] : ErrorConditionValidUntil[0..1] : dateTimeShortestPossibleCycle[0..1] : positiveDuration

ResponseStatus

1 *

statuses

1

1

granted for

1

1

status for

returns

RequestTimestamp[1] : dateTimeAddress[0..1] : EndPointAddressRequestorRef[1] : ParticipantMessageIdentifer[0..1] : MessageQualifierConsumerAddress[0..1] : EndPointAddressSubscriptionFilterIdentifier[0..1] : nmtokenSubscriptionContext[0..1] : SubscriptionContext

SubscriptionRequest

1

0..*

requests

1

*

requests

Figure 3-9 SIRI Publish/Subscribe entities



RECOVERY & RESTART

A SIRI Publish/subscribe interaction involve a long running continuous flow of data from a Producer to a Consumer. Mechanisms are needed to allow recover from system failure of either producer, consumer or communications link. These are described in Part 2 of the SIRI specification. In brief:

A CheckStatus request can be sent between any two participants to see if the other is still working. The response includes a ServiceStartedTime which can be used to detect if the producer has failed and been restarted

A heartbeat message can be sent from Producer to Consumer at regular intervals to indicate the service is still functioning, even if there is no new real-time data. This includes a ServiceStartedTime that can be used to detect interruption of service.

it is up to the subscribing service to detect interruptions of service and if necessary to terminate and restart subscriptions.

WHAT DOES A SIRI IMPLEMENTATION REQUIRE?

The deployment of a concrete SIRI implementation entails the following:

The choice of one or more appropriate SIRI Functional Services to meet the application needs.

A country and or local profile that will set out delivery method, the capabilities to be supported, the data reference system for stop identifiers, etc.

Allocation of unique Participant Identifiers to identify the different systems.

A Producer application for the functional service deployed to a server at a known endpoint URL.

A Consumer application for the functional service deployed to a client.

A Status service to check that the service is available and working correctly and that there has not been an interruption.



4. SERVICE DESCRIPTIONS

The rest of this guide presents the Subscription, Request & Delivery elements of the SIRI Functional Services described in Part3 of the SIRI specification as UML Class diagrams.

ORGANISATION

The UML Notation and use of colour is summarised in ANNEX A. Note the use of a <<group>> stereotype on classes that represent a reusable group of related attributes.

For each SIRI Functional service we show:

1. A brief introduction describing the purpose and typical use of the service.

2. A simplified summary of the Subscription & Request elements for the functional service. Note that both are shown on the same diagram, since a subscription embeds a request, though in practice they will be sued separately.

3. A more detailed view of the Subscription & Request elements, including data types and abstract supertypes.

4. A simplified summary of the Delivery elements, including payload content that based relevant parts of Transmodel.

5. A more detailed view of the Delivery elements, including data types and abstract supertypes.

For certain Services (SIRI-SM, SIRI-VM and SIRI-SX) we provide additional summary diagrams of the model elements contained within the delivery.

Note that to allow for compatibility with VDV, for some services the XML schema supports two representations

a nested one and a flattened one that omits the nesting tags. The diagrams in this handbook show only the nested representation, which is the normative CEN one.

Services are discussed in the following order:

1. SM Stop Monitoring, VM Vehicle Monitoring.

2. PT Production Timetable., ET Estimated Timetable., ST Stop Timetable.

3. CT Connection Timetable, CM Connection Monitoring.

4. FM Facility Monitoring.

5. GM General Message, SX-Situation Exchange

FUNCTIONAL REQUESTS & RESPONSES

Figure 4-1 shows a summary of the various SIRI functional service requests. One or more functional service requests can be contained within a SIRI ServiceRequest. One or more functional service subscription requests can be contained within a SIRI SubscriptionRequest; each also includes a corresponding functional service request.



Figure 4-1 Summary of SIRI Functional Service Requests

Figure 4-2 shows a summary of the various SIRI functional service delivery messages produced in response to functional service requests. One or more functional service delivery can be contained within a SIRI ServiceDelivery.

Figure 4-2 Summary of SIRI Functional Service Deliveries



5. SIRI STOP MONITORING (SM)

The SIRI Stop Monitoring Service provides a stop-centric view of vehicle arrivals and departures at a designated stop. It can be used by displays and other delivery services to provide departure board and other presentations of timetabled and real-time journey information both at stops and remotely. The choice of data elements to display and the presentation format is up to the client system. The service can be used in conjunction with the SIRI Stop Timetable service, which provides scheduled data.

The Topics allow a Consumer system to specify that only stop departures and arrivals for a specific Monitoring point, Operator, Line, or Direction are to be returned.

The Request Policies allow a Consumer system to control the amount of data returned, both in terms of the number of elements and level of detail.

The Subscription Policies allow a Consumer system to control the change threshold for returning an update, so that for example an update is only sent if prediction has changed by more than a given amount.

The Delivery message can include not only service arrival and departure times, but also text notices and the identifiers of Situation elements associated with the stop and/or line.

SIRI-SM: SUBSCRIPTION & REQUEST

STOPMONITORINGREQUEST SUMMARY

Figure 5-1 StopMonitoringRequest - Summary



STOPMONITORINGREQUEST DETAIL

The StopMonitoringRequest is used to request stop arrival and departure data for a given stop or stops identified by a MonitoringRef - which will normally correspond to the identifier of a physical stop or platform, but might also be a logical stop which groups several departure boards.

Other criteria that can be used to filter results include Line (e.g. N45 ), Direction, Operator and Destination.

Figure 5-2 StopMonitoringRequest - Detail



SIRI-SM: DELIVERY

The StopMonitoringDelivery (Figure 5-3) is returned by the SIRI-SM service and normally contains one or more MonitoredStopVisit elements for each monitored stop, each recording a MonitoredVehicle-Journey with a MonitoredCall at the stop with passing times. The level of detail to include may vary considerably; for example the full calling pattern of previous and onward calls may be included for each journey. It may also include StopLineNotices associated with the stop. Previous stop visits or line notices may be retracted with a StopVisitCancellation or StopLineNoticeCancellation.

STOPMONITORINGDELIVERY SUMMARY



MonitoringRef[1]CleardownRef[0..1]MonitoredVehicleJourney[1]StopVisitNote[0..1]Extensions[0..1]

MonitoredStopVisit

MonitoringRef[1]VisitNumber[1]LineRef[1]DirectionRef[1]VehicleJourneyRef[0..1]ClearDownRef[0..1]JourneyPatternInfo[0..1]Reason[0..1]Extensions[0..1]

MonitoredStopVisitCancellation

MonitoringRef[1]LineRef[1]DirectionRef[1]LineNote[0..1]SituationRef[0..1]Extensions[0..1]

StopLineNotice

MonitoringRef[1]LineRef[1]DirectionRef[1]Extensions[0..1]

StopLineNoticeCancellation0..*

0..1

montor

SIRI-SM Summary StopMonitoringDelivery

© 2006 SIRI

version[1]Note[0..1]Extensions[0..1]

StopMonitoringDelivery

1

0..*

line notices

1

0..*

visits

1

0..*

notice cancellations

1

0..*cancellations

0..1 1

cancels

0..1 1

cancels

0..*

0..1montor

1

0..1

1

0..*

line

ServiceDelivery ErrorCondition

1 0..1

errors

Monitor

Direction

1

*

deliveries

MonitoredVehicleJourneyIdentity[1]JourneyPatternInfo[1]VehicleJourneyInfo[1]DisruptionInfo[0..1]JourneyProgress[0..1]TrainBlockPart[0..1]OperationalInfo[0..1]PreviousCalls[0..*]MonitoredCall[0..1]OnwardCalls[0..*]IsCompleteCallSequence[0..1]Extensions[0..1]

MonitoredVehicleJourney

VehicleAtStop[0..1]ArrivalTimes[0..1]DepartureTimes[0..1]Extensions[0..1]

PreviousCall

1

0..*

previous

Line

VehicleAtStop[0..1]VehicleLocationAtStop[0..1]ReversesAtStop[0..1]PlatformTraversal[0..1]SignalStatus[0..1]CallNote[0..1]Disruption[0..1]ArrivalTimes[0..1]ArrivalInfo[0..1]DepartureTimes[0..1]DepartureInfo[0..1]HeadwayInfo[0..1]Extensions[0..1]

MonitoredCall

1

0..1

current

VehicleAtStop[0..1]TimingPoint[0..1]AimedArrivalTimes[0..1]ArrivalInfo[0..1]AimedDepartureTimes[0..1]DepartureInfo[0..1]HeadwayInfo[0..1]Extensions[0..1]

OnwardCall

1

0..*

onward

LineRef[0..1]DirectionRef[0..1]FramedVehicleJourneyRef[1..1]

«group»MonitoredJourneyIdentity

SituationRef[0..1]FacilityChange[0..1]

«group»DisruptionInfo

1

0..1

disruption

1

0..1

disruption

DataFrameRef[1]DatedVehicleJourneyRef[1]

«group»FramedVehicleJourneyRef

DatedVehicleJourney

1

0..*

journey

1

1 journey

JourneyPatternRef[0..1]VehicleMode[0..1]RouteRef[0..1]PublishedLineName[0..1]DirectionName[0..1]ExternalLineRef[0..1]

«group»JourneyPatternInfo

10..1 pattern

1

0..1pattern info

«group»ServiceInfo

JourneyPattern

StopPointRef[0..1]VisitNumber[0..1]Order[0..1]StopPointName[0..1]

AbstractMonitoredCall

StopPoint

Route

0..*

0..1

route

0..*

0..1

pattern

0..1

0..*line

1

1..1

identity

0..*

0..1

stop

AbstractProducerResponse Participant

10..* producer

See MonitoredVehicle Journey Diagrams for details

1

1

journey

«group»VehicleJourneyInfo

«group»ProgressInfo

10..1 progress

1

0..1

info

10..1journey info

Location

1

0..1

location

«group»SituationReference

1

0..1

reference

Figure 5-3 StopMonitoringDelivery - Summary

STOPMONITORINGDELIVERY DETAIL

Figure 5-4 shows detailed attributes of a Stop Monitoring delivery further details of the MonitoredVehicleJourney are described in further diagrams below.




Siri Rqs::AbstractItem

IdentifiedItemCode[0..1] : IdentifiedItemCode

Siri Rqs::AbstractIdentifiedItem IdentifiedItemRef[0..1] : IdentifiedItemCode

Siri Rqs::AbstractReferencedItem

1

1

journey

SIRI-SM StopMonitoringDelivery

© 2006 SIRI

Siri Mdl::Monitor

0..*

0..1monitor

1

0..*

line

1

0..1situation

1

0..*directions

Error[1] : AbstractErrorDescription[1] : ErrorDescription

Siri Rqs::ErrorCondition

ResponseTimeStamp[1] : dateTimeRequestMessageRef[0..1] : MessageQualifierSubscriberRef[0..1] : ParticipantCodeSubscriptionFilterRef[0..1] : SubscriptionFilterCodeSubscriptionRef[0..1] : SubscriptionCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierStatus[0..1] : booleanErrorCondition[0..1] : ErrorConditionValidUntil[0..1] : dateTimeShortestPossibleCycle[0..1] : positiveDuration

Siri Rqs::AbstractFunctionalServiceDelivery

Status : booleanErrorCondition : ErrorConditionMoreData : boolean

Siri Rqs::ServiceDelivery

10..*

errors


MonitoredVehicleJourneyIdentity[1] : MonitoredJourneyIdentityJourneyPatternInfo[1] : JourneyPatternInfoVehicleJourneyInfo[1] : VehicleJourneyInfoDisruptionInfo[0..1] : DisruptionInfoJourneyProgress[0..1] : ProgressInfoTrainBlockPart[0..1] : TrainBlockPartOperationalInfo[0..1] : OperationalInfoPreviousCalls[0..*] : PreviousCallMonitoredCall[0..1] : MonitoredCallOnwardCalls[0..*] : OnwardCallIsCompleteCallSequence[0..1] : booleanExtensions[0..1] : any


DataFrameRef[1] : DataFrameCodeDatedVehicleJourneyRef[1] : DatedVehicleJourneyCode

«group»Siri Mdl::FramedVehicleJourneyRef

TM-Mdl::Line

TM-Mdl::Direction

SX-Mdl::AbstractSituationElement

LineRef[0..1] : LineCodeDirectionRef[0..1] : DirectionCodeFramedVehicleJourneyRef[1..1] : FramedVehicleJourneyRef

«group»Siri Mdl::MonitoredJourneyIdentity

1

1

journey0..1

0..*

line1

1..1

identity

Siri Mdl::PreviousCall

10..*

previous

Siri Mdl::OnwardCall

10..*

onward

Siri Mdl::MonitoredCall

1

0..1

current


10..*journey

TM-Mdl::DataFrame

0..1

0..*frame

10..1 errors

0..1

0..*

subscriber

ResponseTimeStamp : dateTimeProducerRef : ParticipantCodeAddress : EndPointAddressResponseMessageIdentifier : MessageQualifierRequestMessageRef : MessageQualifier

Siri Rqs::AbstractProducerResponse

1 0..*

producer


MonitoringRef[1] : MonitoringCodeCleardownRef[0..1] : CleardownCodeMonitoredVehicleJourney[1] : MonitoredVehicleJourneyStopVisitNote[0..1] : populatedStringExtensions[0..1] : any

MonitoredStopVisit

0..*

0..1

montor

MonitoringRef[1] : MonitoringCodeVisitNumber[1] : VisitNumberLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeVehicleJourneyRef[0..1]ClearDownRef[0..1] : CleardownCodeJourneyPatternInfo[0..1] : JourneyPatternInfoReason[0..1] : populatedStringExtensions[0..1] : any


0..1 1

cancels

MonitoringRef[1] : MonitoringCodeLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeExtensions[0..1]

StopLineNoticeCancellation

MonitoringRef[1] : MonitoringCodeLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeLineNote[0..1] : populatedStringSituationRef[0..1] : SituationCodeExtensions[0..1]

StopLineNotice

1

0..1

direction

0..1 1

cancels

1

0..*

line notices

1

0..*

visits

1

0..*


1

* deliveries

1

0..*

cancellations

version[1] : versionStringNote[0..1] : populatedStringExtensions[0..1]


Figure 5-4 StopMonitoringDelivery Detail



USE OF MONITOREDVEHICLEJOURNEY ELEMENT FOR SIRI-SM

LEVELS OF DETAIL

The MonitoredVehicleJourney element represents an individual vehicle journey that is being monitored: it can be populated with different amounts of data for different applications. For example, for the Stop Monitoring service, it might contain just information about the time of the vehicle at the monitored stop (if say the requested DetailLevel=normal), or it might also included predicted times at all the subsequent stops along the route (if say DetailLevel=calls).

Detail Level

Definition. Purpose

minimum Return only minimum data: a single MonitoredCall with a stop ids and passing time

Used for exchanging just real-time data between systems that are not concerned with other details.

basic Return useful basic minimum data. A single MonitoredCall for each MonitoredVehicleJourney visiting the Stop, with passing times, and line id.

Used to drive simple displays with limited space that show just lines and passing times and line numbers.

normal Return a single MonitoredCall at the stop for each MonitoredVehicleJourney, populated with with times, stop id, Stop name, DestinationDisplay values (i.e. headings), status etc.

Use for normal departure boards that show arrival/departure times for each vehicle along with names (but not a calling pattern).

calls Return additional information including Onwards and Previous elements with the previous and onward calling pattern, modulated by the NumberOfCalls on the request.

Use for departure boards that need to show the full calling pattern or the onward calling pattern.

full Return all information including full calling pattern, operational data (BlockRef, VehicleRef, etc), progress data, journey pattern references etc

Used for data exchange between operational services, or for advanced display services.

Table 5-1 StopMonitoringRequest Detail Levels

For train services, where there may be different carriages going to different places representing different vehicle journeys, train block parts can be used to identify which section of the train is involved. There will be separate deliveries for each vehicle journey.

PASSING TIMES

The times that are included on each call may include an arrival or departure time or both (depending whether it is the start, end or middle of a route), and planned (Aimed), predicted (Expected) or observed (Actual) - (depending whether it has reached the stop yet. Times are always absolute (i.e. in UTC): it is up to the delivery system to render these often they will be shown on signs as relative e.g. in two minutes . Some systems only return average or predicted headway intervals instead of times.

Event Time Arrival Time Departure Time

Target Aimed Arrival Time Aimed Departure Time

Estimated Expected Arrival Time Expected Departure Time

Observed Actual Arrival Time Actual Departure Time



Table 5-2 Transmodel Passing Time Terminology

STOP IDENTIFIERS

Each point for which a MonitoredStopVisit is returned is given a unique identifier, the MonitoringRef. Normally this will be the same as the stop point, but may be different.

For at stop use, the service can support cleardown identifiers to drive direct wireless cleardown of the displays signalled by the vehicle in proximity.

LOCATION

The ProgressInfo group of a MonitoredVehicelJourney can include a vehicle location in a set of coordinates of a specified data reference system, e.g. WGS84. The static coordinates of stops are part of the STOP PLACE model and are not normally included in messages.

QUALITY OF AVMS DATA

The ProgressInfo group of a MonitoredVehicelJourney also includes various attributes that can be used to judge the certainty level of any real-time predicitions.



MONITOREDVEHICLEJOURNEY SUMMARY

The MonitoredVehicleJourneyElement (Figure 5-5) represents a vehicle journey that is being monitored in real-time and for which predictions are being generated. It is used in both the SIRI-SM and SIRI-VM services. Not all elements will usually be populated.

MonitoredCall records the time at the monitored point. PreviousCall and OnwardsCall can be used optionally to record the times at previous and onward stops.

JourneyPatternInfo, VehicleJourneyInfo provide information describing the journey.

Progress Info groups real-time properties such as location, congestion status, occupancy etc.

MonitoredVehicleJourneyIdentity[1]JourneyPatternInfo[1]VehicleJourneyInfo[1]DisruptionInfo[0..1]JourneyProgress[0..1]TrainBlockPart[0..1]OperationalInfo[0..1]PreviousCalls[0..*]MonitoredCall[0..1]OnwardCalls[0..*]IsCompleteCallSequence[0..1]Extensions[0..1]

MonitoredVehicleJourney

LineRef[0..1]DirectionRef[0..1]FramedVehicleJourneyRef[1..1]

«group»MonitoredJourneyIdentity



ServiceInfo[0..1]OriginRef[0..1]DestinationName[0..1]OriginShortName[0..1]Via[0..*]DestinationRef[0..1]DestinationName[0..1]DestinationShortName[0..1]VehicleJourneyNote[0..1]JourneyNote[0..1]HeadwayService[0..1]OriginAimedDepartureTime[0..1]DestinationAimedDepartureTime[0..1]




StopPointRef[0..1]VisitNumber[0..1]Order[0..1]StopPointName[0..1]

AbstractMonitoredCall

VehicleAtStop[0..1]VehicleLocationAtStop[0..1]ReversesAtStop[0..1]PlatformTraversal[0..1]SignalStatus[0..1]CallNote[0..1]Disruption[0..1]ArrivalTimes[0..1]ArrivalInfo[0..1]DepartureTimes[0..1]DepartureInfo[0..1]HeadwayInfo[0..1]Extensions[0..1]

MonitoredCall



VehicleAtStop[0..1]ArrivalTimes[0..1]DepartureTimes[0..1]Extensions[0..1]

PreviousCall

AimedArrivalTime[0..1]ExpectedArrivalTime[0..1]

«group»AimedArrivalTimes

AimedDepartureTime[0..1]ExpectedDepartureTime[0..1]

«group»AimedDepartureTimes

VehicleAtStop[0..1]TimingPoint[0..1]AimedArrivalTimes[0..1]ArrivalInfo[0..1]AimedDepartureTimes[0..1]DepartureInfo[0..1]HeadwayInfo[0..1]Extensions[0..1]

OnwardCall

ArrivalStatus[0..1]ArrivalPlatformName[0..1]ArrivalBoardingActivity[0..1]

«group»ArrivalInfo

DepartureStatus[0..1]DeparturePlatformName[0..1]DepartureBoardingActivity[0..1]

«group»DepartureInfo

AimedHeadWayInterval[0..1]ExpectedHeadwayInterval[0..1]

«group»HeadwayInfo

Monitored[0..1]MonitoringError[0..1]InCongestion[0..1]InPanic[0..1]PredictionInaccurate[0..1]DataSource[0..1]ConfidenceLevel[0..1]VehicleLocation[0..1]Bearing[0..1]ProgressRate[0..1]Occupancy[0..1]Delay[0..1]ProgressStatus[0..1]

«group»ProgressInfo

BlockRef[0..1]CourseOfJourneyRef[0..1]VehicleRef[0..1]

«group»OperationalInfo

NumberOfBlockParts[0..1]TrainPartRef[0..1]PositionOfTrainBlockPart[0..1]

TM-Mdl::TrainBlockPart

SIRI SummaryMonitoredVehicleJourney

© 2006 SIRI

TimingPoint[0..1]BoardingStretch[0..1]RequestStop[0..1]DestinationDisplay[0..1]

«group»CallInfo

AimedArrivalTime[0..1]ActualArrivalTimes[0..1]ExpectedArrivalTime[0..1]

«group»ArrivalTimes

AimedDepartureTime[0..1]ActualDepartureTimes[0..1]ExpectedDepartureTime[0..1]

«group»DepartureTimes

TM-Mdl::TrainPart

OperatorRef[0..1]ProductCategoryRef[0..1]ServiceFeatureRef[0..*]VehicleFeatureRef[0..*]


TM-Mdl::Route


TM-Mdl::Line


TM-Mdl::Block

TM-Mdl::Operator

TM-Mdl::Vehicle


TM-Mdl::StopPoint

1

1

journey

0..1

0..*

line

11..1

identity

1

0..*

journey

0..*

0..1

block

1

0..1

pattern info0..*

0..1route

0..*

0..1

pattern

1

0..1

pattern

1

0..1

call

1

0..1

headway

1

0..1

headway

1*

arrival

1

0..1

departure

1

0..1

departure

10..1

departure

1

0..1 arrival times

1

0..1

times

1

0..1

times

10..1departure times

0..*

0..1

origin

0..*

0..1 stop

0..*0..1

operator

1

0..1

info

1

0..1

arrival

1

0..1

arrival

ServiceFeature

VehicleFeature

0..*

0..*0..1

0..*0..1

1

0..*

1

0..1

operational

0..*

0..1

0..*

0..1

0..*

0..1

0..*0..1

0..*

0..1

destination

1

0..1

10..1

train block

0..* 0..1train

fullseatsAvailablestandingAvailable

«enumeration»OccupancyEnum

10..1

progress1

0..1

disruption

1 0..1

disruption

boardingnoBoardingpassThru

«enumeration»DepartureActivityEnum early

onTimedelayedarrivedcancellednoReport

«enumeration»TimeStatusEnum

alightingnoAlightingpassThru

«enumeration»ArrivalActivityEnum

TM-Mdl::DataFrame

noProgressslowProgressnormalProgressfastProgressunknown

«enumeration»ProgressRateEnum

Loc Mdl::Location1

0..1location


1

0..1

reference

Figure 5-5 Monitored VehicleJourney - Summary



MONITOREDVEHICLEJOURNEY DETAIL

Figure 5-6 shows the detailed data attributes for a MonitoredVehicleJourney.

Figure 5-6 Monitored vehicle Journey detail



EXAMPLES OF LIVE SERVICES THAT USE SIRI-SM

MAP BASED WEB DEPARTURE BOARDS

http://www.leicestertravel.info.

.

WAP MOBILE DEPARTURE BOARDS

SMS DEPARTURE BOARDS

UK National SMS service SMS to 84268

http://www.leicestertravel.info



6. SIRI VEHICLE MONITORING (VM)

The SIRI Vehicle Monitoring Service reports the position and other real-time properties of a vehicle or group of vehicles making monitored journeys in real-time. It can be used for example to monitor the progress of vehicles; to provide information for systems which present visualisations of the movement of vehicles, for instance on maps, lists or line diagrams; and to exchange information about roaming vehicles between control centres. A particular use is to log data.

SIRI-VM: SUBSCRIPTION & REQUEST

VEHICLEMONITORINGREQUEST SUMMARY

The VehicleMonitoringRequest (Figure 6-1) is used to request real-time data for a vehicle or vehicles. The vehicles can be identified by an arbitrary prearranged grouping, a VehicleMonitoringRef or other criteria such a Line (e.g. N45 ), Direction, or individual VehicleRef.

The Topics allow a Consumer system to specify that only vehicle movements for a specific Vehicle Monitoring group, Line, or Line Direction or Vehicle are to be returned.

The Request Policies allow a Consumer system to control the amount of data returned.

The Subscription Policies allow a Consumer system to control the change threshold for update.

Figure 6-1 VehicleMonitoringRequest - Summary



VEHICLEMONITORINGREQUEST DETAIL

Figure 6-2 shows detailed attributes for a VehicleMonitoring request.

Figure 6-2 VehicleMonitoringRequest - Detail



SIRI-VM: DELIVERY

VEHICLEMONITORINGDELIVERY SUMMARY

The VehicleMonitoringDelivery (Figure 5-3) is returned by the SIRI-VM service and normally contains one or more VehicleActivity elements for each monitored vehicle, each recording a MonitoredVehicleJourney with at least some ProgressInfo, such as the current Location. The level of detail to include may vary considerably; for example, the calling pattern of previous, current and onward calls may be included for each journey. Previously active vehicles may be removed with a VehicleActivityCancellation.

Figure 6-3 VehicleMonitoringDelivery - Summary



USE OF MONITOREDVEHICLEJOURNEY ELEMENT FOR SIRI-VM

See also discussion of Passing times and Stop Identifiers under the SIRI-SM service

LEVELS OF DETAIL

The MonitoredVehicleJourney element represents an individual vehicle journey that is being monitored: it can be populated with different amounts of data for different applications. For example, for a simple tracking use Vehicle Monitoring service, it might contain just information about the location of the vehicle at the monitored stop (if say the requested DetailLevel=normal), or it might also included predicted times at all the subsequent stops along the route (if say DetailLevel=calls).

DetailLevel Definition. Purpose

minimum Return only minimum data: Location Used for exchanging just real-time data between systems that are not concerned with other details.

basic Return useful basic minimum data to identify the vehicle journey

e.g. Line id - and supply simple ProgressInfo such as a current location,

Used to drive simple movement displays displays with limited space that show just lines and passing times and line numbers.

normal Return a single MonitoredCall at the current or next stop for each MonitoredVehicleJourney, populated with times, stop id, Stop name, DestinationDisplay values (i.e. headings), status etc.

Use for on and off board next stop displays and visualisations.

calls Return additional information including current MonitoredCall, Onwards, and Previous elements with the previous and onward calling pattern, modulated by the NumberOfCalls on the request.

Use for exchanging data for roaming, or for replicating current vehicle prediction data to distribution systems. Also can be used to feed historical logging services that want to record all the predictions at a given moment in time.

full Return all information including full calling pattern, operational data (BlockRef, VehicleRef, etc), progress data, journey pattern references etc

Used for sending data to consumer systems that do not have all the reference data already

Table 6-1 VehicleMonitoringRequest Detail Levels

LOCATION

The ProgressInfo group of a MonitoredVehicelJourney can include the vehicle s current location as a set of coordinates of a specified data reference system, e.g. WGS84.

The static coordinates of stops are part of the STOP PLACE model and are not normally included in messages.



VEHICLEMONITORINGDELIVERY DETAIL

Figure 6-4 shows more detailed attributes of VehicleMonitoringDelivery, many of which are concerned with supplying references to associated entities. The detailed model of a MonitoredVehicleJourney is the same as for the StopMonitoring service, but will be populated differently




Siri Rqs::AbstractIdentifiedItem IdentifiedItemRef[0..1] : IdentifiedItemCode


1

1

journey

SIRI-SM StopMonitoringDelivery

© 2006 SIRI

Siri Mdl::Monitor

0..*

0..1monitor

1

0..*

line

1

0..1situation

1

0..*directions





Status : booleanErrorCondition : ErrorConditionMoreData : boolean


10..*

errors


MonitoredVehicleJourneyIdentity[1] : MonitoredJourneyIdentityJourneyPatternInfo[1] : JourneyPatternInfoVehicleJourneyInfo[1] : VehicleJourneyInfoDisruptionInfo[0..1] : DisruptionInfoJourneyProgress[0..1] : ProgressInfoTrainBlockPart[0..1] : TrainBlockPartOperationalInfo[0..1] : OperationalInfoPreviousCalls[0..*] : PreviousCallMonitoredCall[0..1] : MonitoredCallOnwardCalls[0..*] : OnwardCallIsCompleteCallSequence[0..1] : booleanExtensions[0..1] : any


DataFrameRef[1] : DataFrameCodeDatedVehicleJourneyRef[1] : DatedVehicleJourneyCode


TM-Mdl::Line

TM-Mdl::Direction

SX-Mdl::AbstractSituationElement

LineRef[0..1] : LineCodeDirectionRef[0..1] : DirectionCodeFramedVehicleJourneyRef[1..1] : FramedVehicleJourneyRef

«group»Siri Mdl::MonitoredJourneyIdentity

1

1

journey0..1

0..*

line1

1..1

identity

Siri Mdl::PreviousCall

10..*

previous

Siri Mdl::OnwardCall

10..*

onward

Siri Mdl::MonitoredCall

1

0..1

current


10..*journey

TM-Mdl::DataFrame

0..1

0..*frame

10..1 errors

0..1

0..*

subscriber

ResponseTimeStamp : dateTimeProducerRef : ParticipantCodeAddress : EndPointAddressResponseMessageIdentifier : MessageQualifierRequestMessageRef : MessageQualifier


1 0..*

producer


MonitoringRef[1] : MonitoringCodeCleardownRef[0..1] : CleardownCodeMonitoredVehicleJourney[1] : MonitoredVehicleJourneyStopVisitNote[0..1] : populatedStringExtensions[0..1] : any

MonitoredStopVisit

0..*

0..1

montor

MonitoringRef[1] : MonitoringCodeVisitNumber[1] : VisitNumberLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeVehicleJourneyRef[0..1]ClearDownRef[0..1] : CleardownCodeJourneyPatternInfo[0..1] : JourneyPatternInfoReason[0..1] : populatedStringExtensions[0..1] : any


0..1 1

cancels

MonitoringRef[1] : MonitoringCodeLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeExtensions[0..1]

StopLineNoticeCancellation

MonitoringRef[1] : MonitoringCodeLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeLineNote[0..1] : populatedStringSituationRef[0..1] : SituationCodeExtensions[0..1]

StopLineNotice

1

0..1

direction

0..1 1

cancels

1

0..*

line notices

1

0..*

visits

1

0..*


1

* deliveries

1

0..*

cancellations

version[1] : versionStringNote[0..1] : populatedStringExtensions[0..1]


Figure 6-4 VehicleMonitoringDelivery - Detail



7. SIRI PRODUCTIONTIMETABLE (PT)

The SIRI Production Timetable Service transmits daily timetables that include any planned updates that are known about at the time of transmission. The service is used typically to communicate between Scheduling systems and AVMS systems, and also between AVMS systems and intelligent clients of the AVMS system to distributed the latest timetables. The timetables exchanged should cover all lines covered by the AVMS system. SIR-PT may be used in conjunction with the SIRI Estimated Timetable service to provide a base timetable.

The SIRI Production Timetable Service is also used to transmit the planned interchanges between journeys, including information about the linking of vehicle parts through the interchange, such as whether passengers are able to remain seated in the vehicle.

The Request Topics allow a Consumer system to specify that only timetables for a specific timetable version. Operator, line, or direction are to be returned.

The Delivery can include the times at stops, block and journey pattern information, and information about available connections.

SIRI-PT: SUBSCRIPTION & REQUEST

PRODUCTIONTIMETABLEREQUEST SUMMARY

ServiceRequest

SubscriptionRequestParticipant SIRI-PT SummaryProductionTimetableSubscription

& ProductionTimetableRequest© 2007 SIRI

ProductionTimetableSubscriptionRequest

ProductionTimetableRequest

ValidityPeriod[0..1]TimetableVersionRef[0..1]OperatorRef[0..1]LineRef[0..1]DirectionRef[0..1]

ProductionTimetableTopicsLanguage[0..1]IncrementalUpdates[0..1]

ProductionTimetablePoliciesTimetableVersion

Operator

Line Direction StartTime[1]EndTime[1]

ValidityPeriod

ProductionTimetableSubscriptionPolicies1

0..*

requests

1

0..*

requestor1 0..*

requestor

0..1 0..*

operator

1

0..1

topics

0..1

0..*

version

0..1

0..*direction0..1

0..*

line

1 0..1

period

1 0..1

policies

1

1

request1 0..1

policies

1

0..*

requests

Figure 7-1 ProductionTimeTableRequest - Summary



PRODUCTIONTIMETABLEREQUEST DETAIL

Figure 7-2 shows the detailed attributes of the ProductionTimetableRequest which is used to request the timetable of a given service or services

Timetables may be requested by operator, Line Direction, Operator and Destination.

RequestContext[1] : RequestContextRequestTimestamp[1] : dateTimeAddress[1] : EndPointAddressRequestorRef[1] : ParticipantCodeMessageIdentifer[1] : string

Siri Rqs::ServiceRequest


Siri Rqs::SubscriptionRequest Siri Rqs::SubscriptionContext

Siri Rqs::RequestContext

Siri Mdl::Participant 10..1

context

1 0..*

requestor

1

0..*

requests

1

0..1

context

1

0..*

requestor

1

0..1

topics

1

0..1

policies

0..1

0..*

version

0..1

0..*

operator

0..1

0..*line

SIRI-PT ProductionTimetableSubscription

& ProductionTimetableRequest© 2007 SIRI

ProductionTimetableRequest[1] : ProductionTimetableRequestProductionTimetableSubscriptionPolicies[0..1] : ProductionTimetableSubscriptionPoliciesExtensions[0..1] : any

ProductionTimetableSubscriptionRequest

ProductionTimetableTopics[0..1] : ProductionTimetableTopicsProductionTimetablePolicies[0..1] : ProductionTimetablePoliciesExtensions[0..1] : any

ProductionTimetableRequest

ValidityPeriod[0..1]TimetableVersionRef[0..1] : TimetableVersionCodeOperatorRef[0..1] : OperatorCodeLineRef[0..1] : LineCodeDirectionRef[0..1] : DirectionCode

ProductionTimetableTopics Language[0..1] : langIncrementalUpdates[0..1] : boolean

ProductionTimetablePolicies

0..1

0..*

direction

1

0..1

period


Siri Rqs::AbstractFunctionalServiceRequest


Siri Rqs::AbstractFunctionalSubscriptionRequest

TM-Mdl::TimetableVersion

TM-Mdl::Operator

TM-Mdl::Line

TM-Mdl::Direction

1

0..*

directions

StartTime[1] : dateTimeEndTime[1] : dateTime

Siri Mdl::ValidityPeriod

ProductionTimetableSubscriptionPolicies

1

0..*

subscriber

1

1

request

1

0..1

policies

1

0..*

requests

Figure 7-2 ProductionTimetableRequest - Detail



SIRI-PT: DELIVERY

PRODUCTIONTIMETABLEDELIVERY SUMMARY

In essence the ProductionTimetableDelivery returns a timetable as a Versioned set of DatedVehicleJourney instances, each having two or more DatedCalls, as shown in Figure 7-3 which also shows attributes and associated entity references, for example that that a DatedVehicleJourney may have JourneyPatternInfo and ServiceInfo. DatedCalls may also have TargetedInterchange elements giving information about timetabled connections.

Figure 7-3 ProductionTimetableDelivery - Summary



PRODUCTIONTIMETABLEDELIVERY DETAIL

Figure 7-4 shows attribute types for a ProductionTimetableDelivery as well.

SIRI-PTProductionTimetableDelivery

© 2006 SIRI

version[1] : versionStringExtensions[0..1] : any

ProductionTimetableDelivery

VersionRef[0..1] : TimetableVersionCodeLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeJourneyPatternInfo[0..1] : JourneyPatternInfoServiceInfo[0..1] : ServiceInfoDatedVehicleJourneyInfo[0..1] : DatedVehicleJourneyInfoExtensions[0..1] : any

PT-Mdl::DatedTimetableVersionFrame

10..*

timetables

1

0..*

deliveries

1

0..1

default

1

0..1default

DatedVehicleJourneyCode[0..1] : DatedVehicleJourneyCodeVehicleJourneyRef[0..1] : VehicleJourneyCodeExtraJourney[0..1] : booleanCancellation[0..1] : booleanJourneyPatternInfo[0..1] : JourneyPatternInfoServiceInfo[0..1] : ServiceInfoVehicleJourneyNote[0..1] : populatedStringJourneyNote[0..1] : populatedStringBlockRef[0..1] : BlockCodeCourseOfJourneyRef[0..1] : CourseOfJourneyCodeCalls[0..*] : DatedCallExtensions[0..1] : AllowedResourceUsageExceeded

PT-Mdl::DatedVehicleJourney

1

0..*

journeys

DestinationDisplay[0..1] : populatedStringLineNote[0..1] : populatedStringHeadwayService[0..1] : booleanMonitored[0..1] : boolean

«group»PT-Mdl::DatedVehicleJourneyInfo

1

0..1

default

1

0..1

pattern1

0..1

10..1

journey info

StopPointInSequence[1]CallInfo[0..1] : CallInfoCallNote[0..1] : populatedStringFacilityChange[0..1] : FacilityChangeAimedArrivalInfo[0..1] : AimedArrivalInfoAimedDepartureInfo[0..1] : AimedDepartureInfoAimedHeadwayInterval[0..1] : positiveDurationExtensions[0..1] : any

PT-Mdl::DatedCall

1

2..*calls

AimedArrivalTime[0..1] : dateTimeArrivalPlatformName[0..1] : populatedStringArrivalBoardingActivity[0..1] : ArrivalActivityEnum

«group»PT-Mdl::AimedArrivalInfo

AimedDepartureTime[0..1] : dateTimeDeparturePlatformName[0..1] : populatedStringDepartureBoardingActivity[0..1] : DepartureActivityEnum

«group»PT-Mdl::AimedDepartureInfo

1

0..1

1

0..1

0..*0..1

stop point

InterchangeCode[0..1] : InterchangeCodeDistributorVehicleJourneyRef[1] : DatedVehicleJourneyCodeDistributorConnectionLinkRef[0..1] : ConnectionLinkCodeDistributorConnectionLink[0..1] : ConnectionLinkDistributorVisitNumber[0..1] : VisitNumberDistributorOrder[0..1] : positiveIntegerStaySeated[0..1] : booleanGuaranteed[0..1] : booleanAdvertised[0..1] : booleanMaximumWaitTime[0..1] : positiveDurationExtensions[0..1] : any

PT-Mdl::TargetedInterchange

1

0..1

ref

0..* 0..1

1

0..* connection

10..1 call

0..*

0..1

block

0..*0..1 run

1

0..*

to stop

0..*

0..1


0..*0..1



1

0..1

errors



Status[0..1] : booleanErrorCondition[0..1] : ErrorConditionMoreData[1] : boolean

Siri Rqs::ServiceDelivery10..1errors






JourneyPatternRef[0..1] : JourneyPatternCodeVehicleMode[0..1] : ModeRouteRef[0..1] : RouteCodePublishedLineName[0..1] : populatedStringDirectionName[0..1] : populatedStringExternalLineRef[0..1] : LineCode

«group»Siri Mdl::JourneyPatternInfo

0..*

0..1

pattern

TM-Mdl::Mode TM-Mdl::Route

0..*

0..1route

OperatorRef[0..1] : OperatorCodeProductCategoryRef[0..1] : ProductCategoryCodeServiceFeatureRef[0..*] : ServiceFeatureCodeVehicleFeatureRef[0..*] : VehicleFeatureCode

«group»Siri Mdl::ServiceInfo

TimingPoint[0..1] : booleanBoardingStretch[0..1] : booleanRequestStop[0..1] : booleanDestinationDisplay[0..1] : populatedString

«group»Siri Mdl::CallInfo

ConnectionLinkCode[0..1] : ConnectionLinkCodeStopPointRef[0..1] : StopPointCodeStopPointName[0..1] : nlStringDefaultDuration[0..1] : durationFrequentTravellerDuration[0..1] : durationOccasionalTravellerDuration[0..1] : durationImpairedAccessDuration[0..1] : duration

TM-Mdl::ConnectionLink

StopPointRef[1] : StopPointCodeVisitNumber[0..1] : VisitNumberOrder[0..1] : positiveIntegerStopPointName[0..1] : populatedString


1

2..*

stops

TM-Mdl::StopPoint

0..* 1stop

TM-Mdl::Block


1

*

runs

0..1

0..*

subscriber

ResponseTimeStamp[1] : dateTimeProducerRef[0..1] : ParticipantCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierRequestMessageRef[0..1] : MessageQualifier


1 0..*

producer

TM-Mdl::Line

10..*

line

1

0..* line

Figure 7-4 ProductionTimetableDelivery - Detail



8. SIRI ESTIMATEDTIMETABLE (ET)

The SIRI Estimated Timetable service is used by an AVMS or real-time hub to inform interested systems of the current status of all known vehicle journeys. This enables schedule information systems to provide up-to-the-minute information for short-term journey planning. It can also be used to support intelligent displays that calculate the deviations from the timetables themselves using a timetable and a real time difference delay by the SIRI Stop Monitoring Service. A further use is the historic logging of changes to journey times. It can be used to exchange changes to a timetable established by the SIRI Production timetable service.

The Request Topics allow a Consumer system to specify that only timetables for a specific timetable version. Operator, Line, or Direction are to be returned.

The Subscription Policies allow a subscriber to specify the amount of change to allow before sending an update.

The Delivery returns predicted real-time changes to the timetable.

SIRI-ET: SUBSCRIPTION & REQUEST

ESTIMATEDTIMETABLEREQUEST SUMMARY

EstimatedTimetableSubscriptionRequest

IncrementalUpdates[0..1]ChangeBeforeUpdate[0..1]

EstimatedTimetableSubscriptionPolicies

EstimatedTimetableRequest

Language[0..1]

EstimatedTimetablePolicies

PreviewInterval[0..1]TimetableVersionRef[0..1]OperatorRef[0..1]LineRef[0..1]DirectionRef[0..1]

EstimatedTimetableTopics

SIRI-ET SummaryEstimatedTimeTableSubscription

& EstimatedTimeTableRequest© 2006 SIRI

Direction

Line

Operator

TimetableVersion

ServiceRequest

SubscriptionRequest

Participant

1

0..*

requestor

1

0..*

requestor

10..1

policies

1

*

subscriptions

1

0..*

topics

0..*0..1 operator

0..*0..1 version

0..*0..1

direction

0..*0..1

line

10..1

policies

1 0..*

requests

1

*

request

Figure 8-1 EstimatedTimetableRequest - Summary



ESTIMATEDTIMETABLEREQUEST DETAIL

Figure 8-2 shows the detailed attributes of the EstimatedTimetableRequest which is used to request the real-time timetable of a given service or services.

Timetables may be requested by operator, Line, Direction, Operator and Destination.

Figure 8-2 EstimatedTimetableRequest - Detail

SIRI-ET: DELIVERY



ESTIMATEDTIMETABLEDELIVERY SUMMARY

Figure 7-3 shows the attributes of an EstimatedTimetableDelivery, which the SIRI-ET service uses to return a timetable as a versioned set of EstimatedVehicleJourney instances, each having an ordered collection of EstimatedCalls. These structures are similar to those of a TargetedVehicleJourney elements of the SIRI-PT service but additionally include expected times i.e. real-time predictions as well.

SIRI-PT - SummaryEstimatedTimeTableDelivery

© 2006 SIRI

VersionRef[0..1]Extensions[0..1]

EstimatedJourneyVersionFrame

EstimatedTimetableDelivery

LineRef[1]DirectionRef[1]DatedVehicleJourneyRef[0..1]DatedVehicleJourneyIndirectRef[0..1]EstimatedVehicleJourneyCode[0..1]ExtraJourney[0..1]Cancellation[0..1]JourneyPatternInfo[0..1]ServiceInfo[0..1]VehicleJourneyName[0..1]JourneyNote[0..1]HeadwayService[0..1]DisruptionInfo[0..1]Monitored[0..1]PredictionInaccurate[0..1]Occupancy[0..1]OperationalInfo[0..1]EstimatedCalls[2..*]IsCompleteStopSequence[0..1]Extensions[0..1]

EstimatedVehicleJourney

StopPointInSequence[0..1]ExtraCall[0..1]Cancellation[0..1]CallInfo[0..1]DestinationDisplay[0..1]CallNote[0..1]FacilityChange[0..1]AimedArrivalTimes[0..1]ArrivalInfo[0..1]AimedDepartureTimes[0..1]DepartureInfo[0..1]HeadwayInterval[0..1]Extensions[0..1]

EstimatedCall

OriginRef[1]AimedDepartureTime[1]DestinationRef[1]AimedArrivalTime[1]

«group»DatedVehicleJourneyIndirectRef

ErrorConditionServiceDelivery







StopPointRef[1]VisitNumber[0..1]Order[0..1]StopPointName[0..1]

«group»StopPointInSequence

AimedArrivalTime[0..1]ExpectedArrivalTime[0..1]

«group»AimedArrivalTimes

ArrivalStatus[0..1]ArrivalPlatformName[0..1]ArrivalBoardingActivity[0..1]

«group»ArrivalInfo

DepartureStatus[0..1]DeparturePlatformName[0..1]DepartureBoardingActivity[0..1]

«group»DepartureInfo

AimedDepartureTime[0..1]ExpectedDepartureTime[0..1]

«group»AimedDepartureTimes

AimedHeadWayInterval[0..1]ExpectedHeadwayInterval[0..1]

«group»HeadwayInfo

TimingPoint[0..1]BoardingStretch[0..1]RequestStop[0..1]DestinationDisplay[0..1]

«group»CallInfo

earlyonTimedelayedarrivedcancellednoReport

«enumeration»TimeStatusEnum

StopPoint

Vehicle

CourseOfJourney

Block

Operator

JourneyPatternDirection

Line

Route

Mode



TimetableVersion




«enumeration»DepartureActivityEnum

ServiceFeature

0..* 0..1

feature

ProductCategory0..*

0..1

category

0..*0..1

operator

VehicleFeature

0..*

0..1feature

1

0..*

delivery

1

0..*

deliveries1 0..1

errors

1

0..1

call info

1 0..1

disruption

0..*

0..1

vehicle

1

*

runs

0..*

0..1

run

1

0..1

departure info

1

0..1 arrival

1

0..1 arrival times

1

0..1

headway1

0..1

departure times

0..*

1 stop

0..*

1

at

1

2..*

stops

1

0..1

between

0..*

1

from

10..1pattern info

0..*

0..1

route

0..*

0..1

mode

0..*

0..1pattern

0..*

0..1

line

0..*

1

direction

0..11

Association1

10..*

journeys

1

0..1

service

1

0..1

operational info

0..* 0..1

block

1

0..*

calls

AbstractProducerResponse Participant

10..* producer


1

0..1

reference

Figure 8-3 EstimatedTimetableDelivery - Summary



ESTIMATEDTIMETABLEDELIVERY DETAIL

Figure 7-4 shows the detailed attributes of an EstimatedTimetableDelivery.

SIRI-PT EstimatedTimeTableDelivery

© 2006 SIRI

VersionRef[0..1] : TimetableVersionCodeExtensions[0..1] : any

ET-Mdl::EstimatedJourneyVersionFrame

version[1] : versionStringExtensions[0..1] : any

EstimatedTimetableDelivery

10..* delivery

LineRef[1] : LineCodeDirectionRef[1] : DirectionCodeDatedVehicleJourneyRef[0..1] : DatedVehicleJourneyCodeDatedVehicleJourneyIndirectRef[0..1] : DatedVehicleJourneyIndirectRefEstimatedVehicleJourneyCode[0..1] : EstimatedVehicleJourneyExtraJourney[0..1] : booleanCancellation[0..1] : booleanJourneyPatternInfo[0..1] : JourneyPatternInfoServiceInfo[0..1] : ServiceInfoVehicleJourneyName[0..1] : populatedStringJourneyNote[0..1] : populatedStringHeadwayService[0..1] : booleanDisruptionInfo[0..1] : DisruptionInfoMonitored[0..1] : booleanPredictionInaccurate[0..1] : booleanOccupancy[0..1] : OccupancyEnumOperationalInfo[0..1] : OperationalInfoEstimatedCalls[2..*] : EstimatedCallIsCompleteStopSequence[0..1] : booleanExtensions[0..1] : any

ET-Mdl::EstimatedVehicleJourney

1

0..*

1

0..1

pattern info

1

0..1service

10..1

1

0..1

operational info

StopPointInSequence[0..1] : StopPointInSequenceExtraCall[0..1] : booleanCancellation[0..1] : booleanCallInfo[0..1] : CallInfoDestinationDisplay[0..1] : populatedStringCallNote[0..1] : populatedStringFacilityChange[0..1] : FacilityChangeAimedArrivalTimes[0..1] : ArrivalTimesArrivalInfo[0..1] : ArrivalInfoAimedDepartureTimes[0..1] : DatedVehicleJourneyIndirectRefDepartureInfo[0..1] : DepartureInfoHeadwayInterval[0..1] : HeadwayInfoExtensions[0..1] : any

ET-Mdl::EstimatedCall

1

0..1

1

0..1

1

0..1

departure info

10..*

deliveries

0..*

1

stop

1 0..11

0..1arrival times

OriginRef[1] : StopPointCodeAimedDepartureTime[1] : dateTimeDestinationRef[1] : StopPointCodeAimedArrivalTime[1] : dateTime

«group»Siri Mdl::DatedVehicleJourneyIndirectRef

1

0..*

calls

0..*

0..10..*

10..*1

1

0..*

0..11

1

0..1



-RecordedAtTime : dateTime


-Error : AbstractError-Description : ErrorDescription


10..1

errors-Status : boolean-ErrorCondition : ErrorCondition-MoreData : boolean

Siri Rqs::ServiceDelivery1

0..1errors





OperatorRef[0..1] : OperatorCodeProductCategoryRef[0..1] : ProductCategoryCodeServiceFeatureRef[0..*] : ServiceFeatureCodeVehicleFeatureRef[0..*] : VehicleFeatureCode

«group»Siri Mdl::ServiceInfo

BlockRef[0..1] : BlockCodeCourseOfJourneyRef[0..1] : CourseOfJourneyCodeVehicleRef[0..1] : VehicleCode

«group»Siri Mdl::OperationalInfo



-AimedArrivalTime : dateTime-ExpectedArrivalTime : dateTime

«group»Siri Mdl::AimedArrivalTimes

ArrivalStatus[0..1] : TimeStatusEnumArrivalPlatformName[0..1] : populatedStringArrivalBoardingActivity[0..1] : ArrivalActivityEnum

«group»Siri Mdl::ArrivalInfo

DepartureStatus[0..1] : TimeStatusEnumDeparturePlatformName[0..1] : populatedStringDepartureBoardingActivity[0..1] : DepartureActivityEnum

«group»Siri Mdl::DepartureInfo

AimedDepartureTime[0..1] : dateTimeExpectedDepartureTime[0..1] : dateTime

«group»Siri Mdl::AimedDepartureTimes

AimedHeadWayInterval[0..1] : positiveDurationExpectedHeadwayInterval[0..1] : positiveDuration

«group»Siri Mdl::HeadwayInfo

TimingPoint[0..1] : booleanBoardingStretch[0..1] : booleanRequestStop[0..1] : booleanDestinationDisplay[0..1] : populatedString

«group»Siri Mdl::CallInfo

earlyonTimedelayedarrivedcancellednoReport

«enumeration»Siri Enm::TimeStatusEnum

TM-Mdl::StopPoint

0..*1

TM-Mdl::Vehicle

0..*

0..1

vehicle


0..*0..1run

TM-Mdl::Block

TM-Mdl::Operator


0..*

0..1

pattern

1

2..*

stops

TM-Mdl::DirectionTM-Mdl::Line

TM-Mdl::Route0..*0..1

TM-Mdl::Mode

0..*

0..1


1

0..*

producer

1

0..1

SituationRef[0..1] : SituationReferenceFacilityChange[0..1] : FacilityChange

«group»Siri Mdl::DisruptionInfo


0..*0..1

operator

0..*0..1block

0..*

1

from

0..1

0..* subscriber

«group»SX-Mdl::SituationReference

1 0..1

reference

Figure 8-4 EstimatedTimetableDelivery - Detail



9. SIRI STOP TIMETABLE (ST)

The SIRI Stop Timetable Service provides a timetabled for vehicle arrivals and departures at a designated stop. It can be used to reduce the amount of information that needs to be transmitted in real-time to stops and displays, as reference data for a Stop Monitoring Service; and provides a data feed of the static timetables.

The Request Topics allow a Consumer system to specify that only stop timetables for a specific monitoring point, line, or direction are to be returned.

The Delivery returns departures from the stop for a specified window.

SIRI-ST: SUBSCRIPTION & REQUEST

STOPTIMETABLEREQUEST SUMMARY

Figure 9-1 StopTimetableRequest - Summary



STOPTIMETABLEREQUEST DETAIL

The StopTimetableRequest (Figure 9-1) is used to request stop arrival and departure data for a given stop or stops identified by a MonitoringRef - which will normally correspond to the identifier of a physical stop or platform, but might also be a logical stop which groups several departure boards.


1

0..1

policies

1

0..*

requests

10..1

policies

10..1

topics

SIRI-STStopTimetableSubscription

& StopTimetableRequest© 2007 SIRI

StopTimetableTopics[0..1] : StopTimetableTopicsStopTimetablePolicies[0..1] : StopTimetablePoliciesExtensions[0..1] : any

StopTimetableRequest

StopTimetableRequest[1] : StopTimetableRequestStopTimetableSubscriptionPolicies[0..1] : StopTimetableSubscriptionPoliciesExtensions[0..1] : any

StopTimetableSubscriptionRequest

StopTimetableSubscriptionPolicies

MonitoringWindow[0..1] : HalfOpenTimestampRangeMonitoringRef[0..1] : MonitoringCodeLineRef[0..1] : LineCodeDirectionRef[0..1] : DirectionCode

StopTimetableTopics

Language[0..1] : lang

StopTimetablePolicies

0..*

0..1

direction0..*

0..1

monitor

0..*

0..1

line




Siri Rqs::SubscriptionRequest

Siri Rqs::SubscriptionContext


11..1

context

Siri Mdl::Participant 1

0..*

requests


Siri Rqs::AbstractFunctionalServiceRequest


Siri Rqs::AbstractFunctionalSubscriptionRequest

TM-Mdl::Line TM-Mdl::Direction1 0..*

directions

1 0..*

subscriber

1 0..1

context

1

0..*

requestor

1

0..*

requestor

Siri Mdl::Monitor

1

1

request

Figure 9-2 StopTimetableRequest - Detail



SIRI-ST: DELIVERY

The StopTimetableDelivery (Figure 5-3) is returned by the SIRI-ST service and normally contains one or more TargetedStopVisit elements for each monitored stop, each recording a TargetedVehicle-Journey with a TargetedCall at the stop with passing times.

STOPTIMETABLEDELIVERY SUMMARY

StopTimetableDelivery

MonitoringRef[1]TargetedVehicleJourney[1]Extensions[1]

TimetabledStopVisit

VehicleJourneyIdentity[1]JourneyPatternInfo[0..*]VehicleJourneyInfo[0..1]MonitoringRef[0..1]Extensions[0..1]

TargetedVehicleJourney

MonitoringRef[1]VisitNumber[0..1]VehicleJourneyIdentity[1]JourneyPatternInfo[0..1]Extensions[0..1]

TimetabledStopVisitCancellation

LineRef[1]DirectionRef[1]FramedVehicleJourneyRef[0..1]

«group»VehicleJourneyIdentity

StopPointRef[0..1]VisitNumber[1]Order[0..1]TimingPoint[0..1]ServiceInfo[0..1]AimedArrivalInfo[0..1]AimedDepartureInfo[0..1]AimedHeadwayInterval[0..1]Extensions[0..1]

TargetedCall

AimedArrivalTime[0..1]ArrivalPlatformName[0..1]ArrivalBoardingActivity[0..1]

«group»AimedArrivalInfo

SIRI-ST SummaryStopTimetableDelivery

© 2006 SIRI

AimedDepartureTime[0..1]DeparturePlatformName[0..1]DepartureBoardingActivity[0..1]

«group»AimedDepartureInfo

Monitor





Operator

VehicleFeature






«enumeration»DepartureActivityEnum

ProductCategory

Line

Route

JourneyPattern

airbuscoachferrymetrorailtramunderground

«enumeration»VehicleModesEnum



StopPoint

ProducerResponse

ServiceDeliveryErrorCondition

ServiceFeature

DataFrame 0..*

0..1 frame



0..*

1

at

1

2..*

stops

Mode0..*

0..1

mode

1

1

cancels

1

1

journey

1

*

visits

1 0..1

errors

1 0..*

cancellations

1

0..1

departure info

0..*

0..1

stop

1

0..1

arrival info

1

0..*

calls

1 0..1

service info

0..*0..1

feature

0..*

0..1

operator

0..*

0..1

category

0..*

0..1

feature

1

0..1

info

0..*

0..1

route

1

0..1

line

0..*

0..1

monitor

0..*

0..1

monitoring point

1

1

for

0..11

journey

1

1

identity

0..*

0..1

destination

0..*0..1

origin

0..*

0..1pattern

1

0..*

deliveries

Figure 9-3 StopTimetableDelivery - Summary



STOPTIMETABLEDELIVERY DETAIL

Figure 9-4 Figure 7-4 shows attribute types for a StopTimetableDelivery as well.

Figure 9-4 StopTimetableDelivery - Detail



10. SIRI CONNECTIONTIMETABLE (CT)

The SIRI Connection Timetable Service is used for the exchange of schedule data for potential feeder vehicle journeys to a connection zone. It is normally used in conjunction with the SIRI Connection Monitoring Service to establish the reference data of planned connections to be monitored by the real time systems. The service is location-related, i.e. all requests and replies relate to specific connection links, as identified by connection link identifiers.

The Topics allow a Consumer system to specify that only Connection Timetables for a specific Connection Link, Line, or Line Direction or Vehicle are to be returned.

The Delivery returns planned connections as InterchangeJourneys

SIRI-CT: SUBSCRIPTION & REQUEST

CONNECTIONTIMETABLEREQUEST SUMMARY

Figure 10-1 ConnectionTimetableRequest - Summary



CONNECTIONTIMETABLEREQUEST DETAIL

The ConnectionTimetableRequest (Figure 10-2) is used to request stop arrival and departure data for a given stop or stops identified either by a ConnectionTimeFilter or by a ConnectionJourneyFilter - - which will normally correspond to the identifier of a physical stop or platform, but might also be a logical stop which groups several departure boards.


Figure 10-2 ConnectionTimetableRequest - Detail



SIRI-CT: DELIVERY

CONNECTIONTIMETABLEDELIVERY SUMMARY

The ConnectionTimetableDelivery (Figure 10-3Figure 5-3) is returned by the SIRI-CT service and normally contains one or more TimetabledFeedArrival elements for each monitored connection link, each recording a InterchangeJourney.

ConnectionTimetableDelivery

InterchangeRef[0..1]ConnectionLinkRef[1]StopPointInSequence[0..1]FeederJourney[1]AimedArrivalTime[1]Extensions[0..1]

TimetabledFeederArrival

InterchangeRef[0..1]ConnectionLinkRef[1]StopPointInSequence[0..1]LineRef[1]DirectionRef[1]VehicleJourneyRef[1]JourneyPatternInfo[0..1]Reason[0..1]Extensions[0..1]

TimetabledFeederArrivalCancellation

LineRef[1]DirectionRef[1]FramedVehicleJourneyRef[0..1]JourneyPatternInfo[0..1]VehicleJourneyInfo[0..1]DisruptionInfo[0..1]Monitored[0..1]AimedDepartureTime[0..1]OperationalInfo[0..1]Extensions[0..1]

InterchangeJourney

ErrorConditionServiceDelivery

ParticipantProducerResponse SIRI-CT SummaryConnectionTimetableDelivery

© 2006 SIRI









StopPoint

Interchange

ConnectionLink



Operator





Vehicle

CourseOfJourney

Block

Mode RouteSituation

DataFrame

Direction

Line

JourneyPattern

DatedVehicleJourney

1 0..1

errors

1

0..*

arrivals

1 0..*

cancellations

1 0..*

deliveries

0..* 0..1

interchange1

0..1

visit

10..1 visit

0..*

1

at

1

2..*

stops

VehicleFeature

0..*

0..1

feature

ProductCategory

0..*

0..1

categoryServiceFeature

1

0..1

operational info

0..*

0..1

vehicle

0..*

0..1

run0..*

0..1

block

1

0..1

info

0..*0..1destination 0..*

0..1 origin

1 0..1

journey info

0..*

0..1

operator

1

0..1 disruption

0..*

0..1

situation

1

0..1

pattern

0..*

0..1

route0..*

0..1

mode

0..*

0..1

pattern

1

0..1 pattern

0..*0..1 line

10..*

directions

0..*0..1 direction

10..*

journey

1

0..*

journey

0..*

0..1 frame0..1

0..*to stop

0..10..*

link

0..*

0..1

feature

10..* producer

1

1

feeder

1

0..* directions

Figure 10-3 ConnectionTimetableDelivery - Summary



CONNECTIONTIMETABLEDELIVERY DETAIL

Figure 10-4 shows attribute types for a ConnectionTimetableDelivery as well.

Figure 10-4 ConnectionTimetableDelivery - Detail



11. SIRI CONNECTIONMONITORING (CM)

The SIRI Connection Monitoring Service exchanges information between different AVMS to coordinate the real-time arrival and departure of PTVs at an interchange through which passengers may make connecting journeys. The departure time of the outgoing distributor

(or fetcher from )

service may be adjusted to accommodate delays in the incoming feeder to service.

The service ensures that the AVMS are in a position to receive all the necessary data concerning the feeder vehicles to allow connection monitoring and dispatch to be carried out, and to inform passengers of changes. The operational methods of dispatch remain unaffected.

The Service can be used in conjunction with the SIRI Connection Timetable Service to exchange scheduled arrival times in the target connection links.

The Topics allow a Consumer system to specify that only Connection Timetables for a specific Connection Link, Line, or Line Direction or Vehicle are to be returned.

The Delivery can return information about both changes to feeder (e.g. late arrival) and departure (e.g. late departure, platform change)

SIRI-CM: SUBSCRIPTION & REQUEST

CONNECTIONMONITORINGREQUEST SUMMARY

Figure 11-1 ConnectionMonitoringRequest - Summary



CONNECTIONMONITORINGREQUEST DETAIL

The ConnectionMonitoringRequest (Figure 11-2) is used to request information about real-time changes to connecting feeder or distributor journeys, specified either by a ConnectionTimeFilter (identifying a ConnectionLink where changes take place), or by a ConnectionJourneyFilter (identifying a specific journey), which will normally correspond to the identifier of a physical stop or platform, but might also be a logical stop which groups several departure boards.


Figure 11-2 ConnectionMonitoringRequest - Detail

SIRI-CM: DELIVERY



CONNECTIONMONITORINGDELIVERY SUMMARY

The SIRI-CM service returns two types of delivery (Figure 10-3Figure 5-3) that provide information about real-time changes at a monitored connection link.

A ConnectionMonitoringFeedeDelivery contains one or more MonitoredFeedArrival instances, each with an a InterchangeJourney describing the real-time arrival time of a feeder.

A ConnectionMonitoringDistributorDelivery contains different types of change to the departing distributor: a delay (WaitProlongedDeparture); a cancellation (Distributure-DepartureCancellation) or a platform change (StoppingPositionChangedRecording).

Figure 11-3 ConnectionMonitoringDelivery - Summary



CONNECTIONMONITORINGDELIVERY DETAIL

Figure 11-4 shows attribute types for a ConnectionMonitoringDelivery.




Siri Rqs::AbstractIdentifiedItemIdentifiedItemRef[0..1] : IdentifiedItemCode








Siri Mdl::Participant-ResponseTimeStamp : dateTime-ProducerRef : ParticipantCode-Address : EndPointAddress-ResponseMessageIdentifier : MessageQualifier-RequestMessageRef : MessageQualifier

Siri Rqs::ProducerResponse

version[1] : versionStringExtensions[1] : BaseSituation

ConnectionMonitoringFeederDelivery

InterchangeRef[0..1] : InterchangeCodeConnectionLinkRef[1] : ConnectionLinkCodeStopPointInSequence[0..1] : StopPointInSequenceClearDownRef[0..1] : CleardownCodeFeederJourney[1] : InterchangeJourneyVehicleAtStop[1] : booleanNumberOfTransferPassengers[0..1] : integerExpectedArrivalTime[1] : dateTimeExtensions[0..1] : any

CM-Mdl::MonitoredFeederArrival InterchangeRef[0..1] : InterchangeCodeConnectionLinkRef[1] : ConnectionLinkCodeStopPointInSequence[0..1] : StopPointInSequenceLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeVehicleJourneyRef[1] : VehicleJourneyCodeJourneyPatternInfo[0..1] : JourneyPatternInfoReason[0..1] : populatedStringExtensions[0..1] : any

MonitoredFeederArrivalCancellation

1

1

feeder

11

version[1] : versionStringExtensions[1] : any

ConnectionMonitoringDistributorDelivery1

0..*

arrvals

1

0..*cancellations

InterchangeRef[0..1] : InterchangeCodeConnectionLinkRef[1] : ConnectionLinkCodeStopPointRef[0..1] : StopPointCodeDistributorVisitNumber[0..1] : VisitNumberDistributorOrder[0..1] : positiveIntegerDistributorJourney[1] : InterchangeJourneyFeederVehicleJourneyRef[0..1] : FramedVehicleJourneyRefExtensions[0..1] : any

CM-Mdl::AbstractDistributorItem

ExpectedDepartureTime[0..1] : dateTimeExtensions[0..1] : any

CM-Mdl::WaitProlongedDeparture

ChangeNote[0..1] : populatedStringNewLocation[0..1] : LocationExtensions[0..1] : any

CM-Mdl::StoppingPositionChangedDeparture

Reason[0..1] : populatedStringExtensions[0..1] : any

DistributorDepartureCancellation

11

distributor

1

0..1

1

0..*

1

0..*

1

0..*

See ConnectionTimetableService for details

SIRI-CM ConnectionMonitoringDelivery

© 2007 SIRI

10..1

0..1

0..*

1

0..1distributor

0..*0..1 feeder

0..1

1

10..1errors

1

0..*

deliveries

10..* deliveries

LineRef[1] : NetworkCodeDirectionRef[1] : DirectionCodeFramedVehicleJourneyRef[0..1] : FramedVehicleJourneyRefJourneyPatternInfo[0..1] : JourneyPatternInfoVehicleJourneyInfo[0..1] : VehicleJourneyInfoDisruptionInfo[0..1] : DisruptionInfoMonitored[0..1] : booleanAimedDepartureTime[0..1] : dateTimeOperationalInfo[0..1] : OperationalInfoExtensions[0..1] : any

Siri Mdl::InterchangeJourney





1

0..1

pattern

TM-Mdl::Line

0..*0..1 line

TM-Mdl::Direction

0..*

0..1

direction

TM-Mdl::StopPoint

0..*

1at


1 0..*journey

TM-Mdl::Route

TM-Mdl::Mode

0..* 0..1mode


0..*

0..1

pattern

TM-Mdl::Interchange


1 0..*

producer0..1

0..*

subscriber

0..1

0..*to stop

0..*0..1route

0..*

0..1link

Figure 11-4 ConnectionMonitoringDelivery - Detail



12. SIRI GENERALMESSAGE (GM)

The SIRI General Message service is used to transmit messages between the participants. The data to be published will typically be informative messages such as travel news and other operational advice, entered or forwarded into the system - normally by a control centre. The General Message service can segregate different types of informative message into separate information channels; each info channel can be assigned to a different operational message group type (errors, messages, warnings, traffic information, operational messages, etc.).

The Topics allow a Consumer system to specify that only specific categories of message are to be returned.

The service allows arbitrary content to be embedded. To exchange structured messages see the SIRI-SX service.

SIRI-GM: SUBSCRIPTION & REQUEST

GENERALMESSAGEREQUEST SUMMARY

Figure 12-1 GeneralMessageRequest - Summary



GENERALMESSAGEREQUEST DETAIL

The GeneralMessageRequest (Figure 12-2) is used to request message data.

Data may be filtered by an InfoChannel.

Figure 12-2 GeneralMessageRequest - Detail



SIRI-GM: DELIVERY

GENERALMESSAGEDELIVERY SUMMARY

The GeneralMessageDelivery (Figure 12-3) is returned by the SIRI-GM service and normally contains one or more GeneralMessage elements, each recording a Content message in a specified format.

Figure 12-3 GeneralMessageDelivery - Summary



GENERALMESSAGEDELIVERY DETAIL

Figure 12-4 shows attribute types for a GeneralMessageDelivery.



-Error[1] : AbstractError-Description[1] : ErrorDescription

SIRI Requests::ErrorCondition

10..1

1

0..1

version[1] : versionStringExtensions[0..1]

GeneralMessageDelivery

InfoMessageIdentifier[1] : InfoMessageIdentifierInfoMessageVersion[0..1] : InfoMessageVersionInfoChannelRef[0..1] : InfoChannelCodeValidUntilTime[0..1] : dateTimeSituationRef[0..1] : SituationCodeContent[1] : Content

GeneralMessage

«datatype»GM-Mdl::InfoMessageIdentifier

«datatype»GM-Mdl::InfoMessageVersion

«datatype»GM-Mdl::InfoChannelCode

InfoMessageIdentifier[1] : InfoMessageIdentifierInfoMessageVersion[0..1] : InfoMessageVersionInfoChannelRef[0..1] : InfoChannelCodeValidUntilTime[0..1] : dateTimeSituationRef[0..1] : SituationCodeExtensions[0..1]

GeneralMessageCancellation

1

0..1

1

0..1

format[0..1] : nmtokenvalue[0..1] : string

Content

1

1

SIRI-GM GeneralMessageDelivery

© 2007 SIRI

GM-Mdl::InfoChannel

0..1

0..*

info channel

1 0..1

cancels


Siri Rqs::AbstractIdentifiedItemIdentifiedItemRef[0..1] : IdentifiedItemCode


-RecordedAtTime[1] : dateTime





10..*

producer



1

0..* deliveries

0..10..*

subscriber

«group»SX-Mdl::SituationReference

0..1

1

situation

Figure 12-4 GeneralMessageDelivery - Detail



13. SIRI FACILITYMONITORING (FM) DRAFT

SIRI-FM: SUBSCRIPTION & REQUEST

FACILITYMONITORINGREQUEST SUMMARY

[TODO]

Figure 13-1 ProductionTimeTableRequest - Summary

FACILITYMONITORINGREQUEST DETAIL

[TODO]

Figure 13-2 ProductionTimetableRequest - Detail

SIRI-FM: DELIVERY

FACILITYMONITORINGDELIVERY SUMMARY

[TODO]

Figure 13-3 ProductionTimetableDelivery - Summary

FACILITYMONITORINGDELIVERY DETAIL

[TODO]

Figure 13-4 ProductionTimetableDelivery - Detail



14. SIRI SITUATIONEXCHANGE (SX) DRAFT

The SIRI-SX Service is for exchanging Situation content in real-time. It uses a structured Situation model for describing disruptions to services. The structured model includes element references that relate directly to the entities of other SIRI services. Incidents can thus be directly linked to stop points, lines, journeys, pathways, etc: and provide an explanation of the disruption. The service can be used to exchange incident information between control systems, and to distribute to journey planners and alert systems that wish to process and match incidents based on structured elements.

The Topics allow a Consumer system to specify that only specific categories of message are to be returned.

The Delivery embeds Structured incidents and updates.

SIRI-SX: SUBSCRIPTION & REQUEST

SITUATIONEXCHANGEREQUEST SUMMARY

Figure 14-1 Summarises the SIRI-SX request elements.

SIRI-SX SummarySituationExchangeSubscription

& SituationExchangeRequest© 2007 SIRI

ServiceRequest

1

*

requests

SubscriptionRequest

SituationExchangeRequestLanguage[0..1]MaximumNumberOfSituations[0..1]

SituationExchangePolicies

PreviewInterval[1]StartTime[0..1]VehicleMode[0..1]AffectedSubMode[0..1]AccessMode[1]Severity[0..1]Predictability[0..1]Keywords[0..*]SituationNetworkFilter[0..1]SituationStopPlaceFilter[0..1]SituationJourneyFilter[0..1]AccessibilityNeedFilter[0..1]

SituationExchangeTopics

SituationExchangeSubscriptionRequest

UserNeed[0..1]

AccessibilityNeedsFilter

IncrementalUpdates[0..1]

SituationExchangeSubscriptionPolicies

1 0..1

policies

10..1

topics

unknownverySlightslightnormalsevereverySeverenoImpactundefined

«enumeration»TpegSeverityEnum

OperatorRef[0..1]OperationalUnitRef[0..1]NetworkRef[0..1]LineRef[0..1]StopPointRef[0..1]ConnectionLinkRef[0..1]

SituationNetworkFilter

0..1

0..*operator


«enumeration»VehicleModesEnum

OperationalUnit

1

0..1

filter

VehicleJourneyRef[0..1]InterchangeRef[0..1]VehicleRef[0..1]

SituationJourneyFilter

Vehicle

InterchangeVehicleJourney0..1

1unit

0..*

0..1

vehicle

0..*

0..1

interchange0..*

0..1

journey

1

0..*

filter

0..*

0..1

stop point

0..*0..1network

ConnectionLink

0..*

0..1

connection

0..1

0..*

user need

1 0..*

participant

10..*

participant

footbicyclecartaxishuttle

«enumeration»AccessModesEnum

StopPoint

Operator

plannedunplannedboth

«enumeration»PredictabilityEnum

Line

Network

Participant

1

0..*

line

UserNeed

1

0..1

filter

StopPlaceRef[0..1]FacilityRef[0..1]

SituationStopPlaceFilter

10..1

places

StopPlace

1

0..*stop place

10..*

subscriptions

1

1

request1

*policies

Figure 14-1 SituationExchangeRequest - Summary



SITUATIONEXCHANGEREQUEST DETAIL

The SituationExchangeRequest (Figure 12-2) is used to request message data.

Data may be filtered by various structured message attributes such as a Severity, Mode, etc as well as filters for the Network, Line Stop place, etc.

SIRI-SX SituationExchangeSubscription

& SituationExchangeRequest© 2007 SIRI




Siri Rqs::SubscriptionRequest

SituationExchangeTopics[0..1] : SituationExchangeTopicsSituationExchangePolicies[0..1] : SituationExchangePoliciesExtensions[0..1] : any

SituationExchangeRequest

Language[0..1] : langMaximumNumberOfSituations[0..1] : integer

SituationExchangePolicies

PreviewInterval[1] : durationStartTime[0..1] : dateTimeVehicleMode[0..1] : VehicleModesEnumAffectedSubMode[0..1] : AccessModesEnumAccessMode[1] : AccessModesEnumSeverity[0..1] : TpegSeverityEnumPredictability[0..1] : booleanKeywords[0..*] : stringSituationNetworkFilter[0..1] : SituationNetworkFilterSituationStopPlaceFilter[0..1] : SituationStopPlaceFilterSituationJourneyFilter[0..1] : SituationJourneyFilterAccessibilityNeedFilter[0..1] : AccessibilityNeedsFilter

SituationExchangeTopics

SituationExchangeRequest[1] : SituationExchangeRequestSituationExchangeSubscriptionPolicies[0..1] : SituationExchangeSubscriptionPoliciesExtensions[0..1] : any

SituationExchangeSubscriptionRequest

AccessibilityNeedsFilter

IncrementalUpdates[0..1] : boolean

SituationExchangeSubscriptionPolicies



OperatorRef[0..1] : OperatorCodeOperationalUnitRef[0..1] : OperationalUnitCodeNetworkRef[0..1] : NetworkCodeLineRef[0..1] : LineCodeStopPointRef[0..1] : StopPointCodeConnectionLinkRef[0..1] : ConnectionLinkCode

SituationNetworkFilter


«enumeration»Siri Enm::VehicleModesEnum

TM-Mdl::OperationalUnit

StopPlaceRef[0..1] : StopPlaceCodeFacilityRef[0..1] : FacilityCode

SituationStopPlaceFilter

VehicleJourneyRef[0..1] : VehicleJourneyCodeInterchangeRef[0..1] : InterchangeCodeVehicleRef[0..1] : VehicleCode

SituationJourneyFilter

TM-Mdl::Vehicle



1

0..1

requestor

footbicyclecartaxishuttle

«enumeration»Siri Enm::AccessModesEnum

TM-Mdl::StopPoint

TM-Mdl::Operatorplannedunplannedboth

«enumeration»SX-Enm::PredictabilityEnum

TM-Mdl::Line

TM-Mdl::Network


ACSB-Mdl::UserNeed

10..1

1

0..*

filter1

0..* journey

10..*

1

0..1filter

1

0..* stop

1

0..* network

TM-Mdl::Interchange

1

0..1

filter

1

*

requests

1

*

policies

1

*

needs

1

0..*connection

10..*stop place

1

0..*

interchange

1

0..*

vehicle

1

0..1

topic

1

0..*

operator

10..*

unit

Siri Rqs::SubscriptionContext


1

0..1

context

1

0..1

context

1

0..*

to stop

10..*

requestor

iFOPT-Mdl::StopPlace

1

0..*

subscriptions

1

*

policies

11 request

Figure 14-2 SituationExchangeRequest - Detail

SIRI-SX: DELIVERY



SITUATIONEXCHANGEDELIVERY SUMMARY

The SituationExchangeDelivery (Figure 14-3) is returned by the SIRI-SX service and normally contains one or more SituationElement instances; these will either be a BaseSituationElement or an UpdateSituationElement. A Series of one ore more SituationElements describes a Situation. Each SituationElement has a body (either of type PtSItuationBody or RoadSituationBody not shown) which is itself made up of a number of groups of attributes and child elements (eg SituationSource, Consequence). For a further summary of the structured model, see below.

AbstractProducerResponse

ServiceDelivery1 0..1

errors

SituationExchangeDelivery

1

0..*

deliveries

SituationSource[1]SituationStatus[1]TemporalGroup[1]ClassifierGroup[1]DescriptionGroup[0..1]Affects[0..1]Consequences[0..*]PublishingActions[0..1]Extensions[0..1]

«group»PtSituationBody

AffectsScope

AffectedLine

AffectedOperator

AffectedScheduledStop

AffectedVehicleJourneyStartTime[1]EndTime[1]

ValidityPeriod

SituationContext

1

*

situations

1

0..1

context

10..*

operators 1

0..* lines1

0..*

stops

1

0..*

journeys

SIRI-SX Summary PTSituationExchangeDelivery

© 2006 SIRI

Operator

StopPoint

0..*

0..1

stop

CreationTime[1]CountryRef[0..1]ParticipantRef[1]SituationNumber[1]RelatedTo[0..*]VersionedAtTime[0..1]SituationBody[1]

AbstractSituationElement

SituationVersion[0..1]UpdateParticipantCountry[0..1]UpdateParticipantRef[0..1]

UpdateSituationElement

CreationTime[1]SituationRef[1]RelatedAs[1]Extensions[0..1]

RelatedSituation

BaseSituationElement

Country[0..1]SourceType[1]SourceMethod[0..1]Email[0..1]Phone[0..1]Fax[0..1]Web[0..1]Other[0..1]AgentReference[0..1]TimeOfObservation[1]TimeOfCommunication[1]ExternalCode[0..1]Extensions[0..1]

SituationSource

causeeffectcorrectssupercedessupercededByassociation

«enumeration»RelatedEnum

1 0..*

related to

ValidityPeriod[1]Repetitions[0..*]PublicationWindow[1]

«group»TemporalGroup

1

*

when

Reason[1]ReasonName[0..1]PublicEvent[0..1]Severity[1]Priority[0..1]Sensitivity[0..1]Audience[0..1]ReportType[0..1]ScopeType[0..*]Planned[0..1]Keywords[0..*]

«group»ClassifierGroup

1

1

classifiers

Summary[0..1]Description[0..1]Detail[0..1]Advice[0..1]Internal[0..1]Images[0..*]InfoLink[0..*]

«group»DescriptionGroup

11 description

Participant

1

0..*

places

DatedVehicleJourney

Line

0..*

0..1

line

PublishingActions

1

0..1

actions

1

0..*journeyAffectedNetwork

1

0..*

networksNetwork

1 0..*

network

Reason

0..*1reason 1

0..1

source

AffectedPlace

1

0..*

places

Place

0..* 0..1

place

Period[0..1]Condition[0..1]Severiity[1]Affects[0..1]Suitabilities[0..*]Advice[1]Blocking[0..1]Boarding[0..1]Delays[0..1]Casualties[0..1]Easements[0..*]Extensions[0..1]

Consequence

1

0..1

affects

1

0..*

made by

ErrorCondition

AffectedStopPlace

1

0..1

applies

0..*

0..1

operator

0..1

1

affects

1

0..*

consequence

StopPlace

0..*

0..1 stop placeStopPlaceComponent

0..*

0..1

stop place

1 0..*

updates *0..*updated by

AffectedRoute

1

0..*

routes

Route

1

0..*

routes

CountryRef[0..1]ParticipantRef[0..1]


1 1

identifier

Verification[1]Progress[1]Quality[0..1]Reality[0..1]Likelihood[0..1]

«group»SituationStatus

1

1

status

SituationNumber[1]UpdateCountryRef[0..1]UpdateParticipantRef[0..1]SituationVersion[0..1]

«group»SituationElementReference

1 0..*reference to

Reference[1]

ExternalReference

AffectedRoads

1

0..1

roads

GroupOfLocations1

0..1locations

SituationBody

1 1

body

Figure 14-3 SituationExchangeDelivery - Summary



SITUATIONEXCHANGEDELIVERY DETAIL

Figure 14-6 shows attribute types for a SituationExchangeDelivery. For a further summary of the structured model, see below.

Figure 14-4 SituationExchangeDelivery Detail



SITUATION MODEL

SITUATION

Figure 14-4 shows the main elements and attributes of the SituationElementl. It has four three basic groups of elements: the TemporalGroup (the time over which that Situation applies), ClassifierGroup (a categorisation of the situation) and a DescriptionGroup (human readable textual descriptions) and SituationStatus . Child elements describe the origin (SituationSource),Consequence and scope of effect (Affects).

Figure 14-5 Situation Main elements



SITUATION BODY

The PtSituationBody (Figure 14-6Figure 14-5) shows detailed attributes of a SituationElement.

SituationSource[1] : SituationSourceSituationStatus[1] : SituationStatusTemporalGroup[1] : TemporalGroupClassifierGroup[1] : ClassifierGroupDescriptionGroup[0..1] : DescriptionGroupAffects[0..1] : AffectsScopeConsequences[0..*] : ConsequencePublishingActions[0..1] : PublishingActionsExtensions[0..1] : any

«group»PtSituationBody

AffectsScope

StartTime[1] : dateTimeEndTime[1] : dateTime

ValidityPeriod

SIRI PT Situation Body© 2006 SIRI AbstractSituationElement

Country[0..1] : CountryEnumSourceType[1] : SourceEnumSourceMethod[0..1] : SourceMethodEnumEmail[0..1] : emailPhone[0..1] : phoneNumberFax[0..1] : phoneNumberWeb[0..1] : anyURIOther[0..1] : stringAgentReference[0..1] : stringTimeOfObservation[1] : dateTimeTimeOfCommunication[1] : dateTimeExternalCode[0..1] : stringExtensions[0..1] : any

SituationSource

ValidityPeriod[1] : ValidityPeriodRepetitions[0..*] : DayTypePublicationWindow[1] : ValidityPeriod

«group»TemporalGroup

Reason[1] : ReasonReasonName[0..1] : nlStringPublicEvent[0..1] : PublicEventTypeEnumSeverity[1] : TpegSeverityEnumPriority[0..1] : integerSensitivity[0..1] : SensitivityEnumAudience[0..1] : AudienceEnumReportType[0..1] : TpegReportEnumScopeType[0..*] : ScopeTypeEnumPlanned[0..1] : booleanKeywords[0..*] : string

«group»ClassifierGroup

Summary[0..1] : DefaultedTextDescription[0..1] : DefaultedTextDetail[0..1] : DefaultedTextAdvice[0..1] : DefaultedTextInternal[0..1] : DefaultedTextImages[0..*] : ImageInfoLink[0..*] : InfoLink

«group»DescriptionGroup

PublishingActions

ReasonCode[1] : ReasonEnumSubReasonCode[0..1] : SubReasonEnum

Reason

Consequence

emailphonefaxpostfeedradiotvwebpagertextother

«enumeration»SourceEnum

Verification[1] : VerificationEnumProgress[1] : SituationProgressEnumQuality[0..1] : QualityIndexEnumReality[0..1] : InformationStatusEnumLikelihood[0..1] : ProbabilityOfOccurenceEnum

«group»SituationStatus

unknownunverifiedverifiedverifiedAsDuplicate

«enumeration»VerificationEnum draft

draftPendingApprovalapprovedDraftopenclosingclosed

«enumeration»SituationProgressEnum

certainveryReliablereliableunreliableunconfirmed

«enumeration»QualityIndexEnum

veryHighhighmediumlowveryLow

«enumeration»SensitivityEnum

generaloperatornetworkroutelineplacestopPlacestopPlaceComponentstopPointvehicleJourneydatedVehicleJourneyconnectionLinkinterchange

«enumeration»ScopeTypeEnum

publicstaffemergencyServicesmanagementstationStaffinfoServicesauthoritiestransportOperators

«enumeration»AudienceEnum

unknownnetworkroutepointindividualServiceundefined

«enumeration»TpegReportEnum

DayType


«enumeration»Tpeg-Mdl::TpegSeverityEnum

Image

10..1

image

InfoLink10..1image

1

0..1

image

1

1

classifiers

11status

10..1

actions

1

*

when

1

0..1source

1

0..*

body

1

1

description

10..*

consequence

1

0..*

days1

0..1

applies

0..*

1

reason

10..1 affects0..11affectsrealsecurityExercisetechnicalExercisetest

«enumeration»InformationStatusEnum

certainprobableriskOfimprobable

«enumeration»ProbabilityOfOccurenceEnum

Figure 14-6 SituationExchangeDelivery - SituationBody



SITUATION AFFECTS SCOPE

The AffectsScope element is used to specify which part sof the network and which services are affected.

AffectsScope

AffectedLine

AffectedOperator

AffectedScheduledStop

AffectedVehicleJourney

Operator

DatedVehicleJourney

Line

AffectedNetwork

Network

Consequence«group»PtSituationBody

AffectedConnectionLink

AffectedCall

AffectedInterchange

Interchange

Route

LineSection

Direction

AffectedStopPlace

Mode

AccessibilityDisruption

SIRI-SX SummarySituation Affects

Scope© 2007

AffectedRoute

RouteLink

10..1

affects1 0..*

consequence

0..11

affects

TopographicPlace

1

0..*

calls

1

0..*

disruptions

1

*

destinations

1

0..*

operator

10..*

journeys

StopPoint

0..*

0..1

stop

Place

AffectedPlace

1

0..*

places

0..*0..1

place

1

0..*

connections

10..*

places

ConnectionLink

1 0..*to stop

0..1

1

link

1

0..*

interchanges

1

0..*

journey

0..*

0..1

line

1

0..*

routes

1

0..*

lines

0..*0..1

direction

0..1 0..1

at

0..*

0..*

mode

1

0..* networks

1

0..*

operators

0..*0..1

operator

1

0..*

operators

1

0..*

network

1

0..*

directions

1

0..*

lines

1

0..*

stops

AffectedStopPlaceComponent

1 0..*components

1

0..*routes

1 0..*

links

1

0..*

links

StopPlace

0..*

0..1

stop place

StopPlaceComponent0..*0..1component

0..1

0..*

section

1

0..*

component

0..*

0..*

mode

0..*

1

interchange0..*

0..1 stop

1

0..*

journey

0..10..*

link

1

0..*

lines

0..*

0..*

affected stops

1

0..*disruptions10..*

accessibility

1

0..*

routes

1

0..1roads

AffectedRoads

Figure 14-7 SIRI-SX Affects Summary



SITUATION AFFECTS SCOPE

SCHEDULED JOURNEYS

Figure 14-8 shows detailed attributes for the scope elements used to relate Situations to parts of the network and to specific journeys.

Figure 14-8 Affects Scope - Scheduled Journeys



SITUATION AFFECTS SCOPE STOP PLACE

Figure 14-9 shows detailed attributes for the scope elements used to relate SituationElements to parts of the stop place. These can include accessibility properties

PlaceRef[1] : PlaceIdPlaceName[0..1] : nlStringPlaceType[0..1]Location[0..1] : LocationAccessibilityDisruption[0..1] : AccessibilityDisruptionExtensions[0..1] : any

AffectedPlace

ComponentRef[1] : ComponentIdComponentName[0..1] : nlStringComponentType[1] : ComponentTypeEnumAccessFeatureType[0..1]Extensions[0..1]

AffectedStopPlaceComponent

MobilityImpairedAccess[1] : booleanLiimitations[0..1] : LimitationSuitabilities[0..*] : Suitability

ACSB-Mdl::AccessibilityDisruption

0..*

0..1

component

UserNeed[1] : nmtokenSuitable[1] : SuitableEnum

ACSB-Mdl::Suitability

StopPlaceRef[1] : StopPlaceCodePlaceName[0..1] : nlStringStopPlaceType[1] : StopPlaceTypeEnumComponents[0..*] : AffectedStopPlaceComponentNavigationPaths[0..*] : ComponentIdExtensions[0..1] : any

AffectedStopPlace

1

0..*

components

SIRI-SX Situation Affects

Scope - Stop Place© 2007

AccessibilityDisruption[0..1] : AccessibilityDisruption

AffectedStopPlaceElement

iFOPT-Mdl::QuayiFOPT-Mdl::AccessSpace

AbstractStopPlaceSpace

iFOPT-Mdl::StopPathLink

iFOPT-Mdl::StopPlaceComponent

1

0..*suitabilities

WheelchairAccess[0..1] : AccessibilityEnumStepFreeAccess[0..1] : AccessibilityEnumEscalatorFreeAccess[0..1] : AccessibilityEnumLiftFreeAccess[0..1] : AccessibilityEnumAudibleSignsAvailable[0..1] : AccessibilityEnumVisualSignsAvailable[0..1] : AccessibilityEnum

ACSB-Mdl::Limitation

1

0..*

limitation

iFOPT-Mdl::BoardingPosition

iFOPT-Mdl::Level

AbstractPathLink

0..* 1

level

0..*

0..1

stop place

1

0..1accessibility

truefalseunknown

«enumeration»ACSB-Mdl::AccessibilityEnum

1

0..*

stops

1

0..*

accessibility

airportrailStationmetroStationcoachStationbusStationshipPortferryPortferryStoponStreetBusonStreetTramskiLiftother

«enumeration»iFOPT-Mdl::StopPlaceTypeEnum

quayaccessSpaceboardingPositionstoppingPlacestoppingPositionentrancestopPathLinkaccessPathLinkother

«enumeration»iFOPT-Mdl::ComponentTypeEnum

iFOPT-Mdl::AccessPathLink

unknownliftescalatortravelatorrampstairsshuttlenarrowEntrancebarrierlowFloorAccess

«enumeration»iFOPT-Mdl::AccessFacilityEnum

AreaOfInterest[0..1] : AreaOfInterestEnumOperators[0..*] : AffectedNetworkNetworks[0..*] : AffectedOperatorLines[0..*] : AffectedLineStopPlaces[0..*] : AffectedStopPlaceStopPoints[0..*] : AffectedScheduledStopPlaces[0..*] : AffectedPlaceVehicleJourneys[0..*] : AffectedVehicleJourneyRoads[0..1] : AffectedRoadsExtensions[0..1] : any

AffectsScope

1

0..*

places

TM-Mdl::Place

0..*

0..1

suitablenotSuitableunknown

«enumeration»ACSB-Mdl::SuitableEnum

iFOPT-Mdl::StopPlace

continentWidenationalneighbouringCountriesnotSpecifiedregional

«enumeration»DX2-DTs::AreaOfInterestEnum

AffectedRoads

1

0..1

DX2-Mdl::GroupOfLocations

1

0..1

locations

Figure 14-9 Affects Scope - Stop Place



15. SIRI COMMON DATA TYPES

COMMON SIRI DATA TYPES

XML SIMPLE TYPES

The SIRI-SX services use XML data types for primitive data types where possible (Figure 15-1).

Figure 15-1 XML simple data types

COMMON SIRI DATA TYPES

The SIRI-SX services use a number of common SIRI complex data types (Figure 15-2).

CapabilityCode[1]

Errors::CapabilityNotSupportedError Errors::OtherError

-ErrorText[1] : string

Errors::AbstractError-Error[1] : AbstractError-Description[1] : ErrorDescription


1 1

Errors::NoInfoForTopicErrorErrors::AccessNotAllowedError

SIRI Simple ErrorTypes

© 2006 SIRI

id[0..1] : nmtokensrsName[0..1] : stringLongitude[0..1] : LongtitudeLatitude[0..1] : LatitudeCoordinates[0..1] : CoordinatesPrecision[0..1] : distance

Loc Mdl::Location

SIRI Complex Data Types

© 2006 SIRI

Errors::AllowedResourceUsageExceeded

EquipmentAvailability[0..1]SituationRef[0..1] : SituationCodeMobilityDisruption[0..1]

FacilityChange

EquipmentRef[0..1] : EquipmentCodeDescription[0..1] : populatedStringEquipmentStatus[1] : EquipmentStatusValidityPeriod[0..1] : HalfOpenTimestampRangeEquipmentTypeRef[0..1] : EquipmentTypeCodeEquipmentFeatures[0..*] : EquipmentFeatureCode

EquipmentAvailability

MobilityImpairedAccess[0..1]MobilityFacility[0..1] : MobilityFacility

MobilityDisruption

1

0..1

1

0..1

StartTime[1] : dateTimeEndTime[0..1] : dateTime

HalfOpenTimestampRange

nlString[1] : nlStringoverridden[0..1]

SX-Mdl::DefaultedTextUri[1] : anyURILabel[1] : nlStringImage[1] : ImageLinkContent[1] : LinkContentEnum

InfoLink

ImageRef[0..1]ImageBinary[0..1]ImageContent[0..1] : ImageContentEnum

Image

1 0..1

image

mapgraphiclogo

«enumeration»Siri Enm::ImageContentEnum

detailsadvicetimetablerelatedSiteother

«enumeration»Siri Enm::LinkContentEnum

-Mode[1]-SubMode[0..1] : TpegSubMode

TM-Mdl::ModeTpegSubMode

-DataFrameRef : DataFrameCode-DatedVehicleJourneyRef : DatedVehicleJourneyCode


Figure 15-2 UML Diagram of Common SIRI Data Types



COMMON SIRI SIMPLE DATA TYPES

CODES & IDENTIFIERS

As well as the XML simple data types, SIRI uses a number of additional simple data types see Figure 15-3. Many of these are just explicitly typed identifiers for entities These have primitive type of string or NMTOKEN).

Figure 15-3 Common SIRI Simple Data types

Figure 15-4 shows simple data types use din SIRI to identify Transmodel entities.

«datatype»DataFrameCode

«datatype»OperationalUnitCode

«datatype»OperatorCode

«datatype»DirectionCode

«datatype»ConnectionLinkCode

«datatype»JourneyPatternCode

«datatype»NetworkCode

«datatype»StopPointCode

«datatype»CourseOfJourneyCode

«datatype»BlockCode

«datatype»DatedVehicleJourneyCode

«datatype»VehicleJourneyCode

«datatype»InterchangeCode

«datatype»VehicleCode

«datatype»RouteCode

«datatype»LineCode

«datatype»PlaceId

«datatype»TrainPartCode

SIRIIdentifier Simple DataTypes

For Transmodel entities© 2006 SIRI

«datatype»IFOPT-DTs::ComponentId

«datatype»IFOPT-DTs::StopPlaceCode

«datatype»TimetableVersionCode

«datatype»TrainPartCode

«datatype»ZoneCode

«datatype»IFOPT-DTs::StopPlaceId

Figure 15-4 Common Identifier types used in SIRI for Transmodel entities



COMMON GENERAL SIRI ENUMERATIONS

The SIRI-SX services use a number of common SIRI enumerations. The common SIRI enumerations are listed in Figure 15-5

Figure 15-5 UML Diagram of SIRI enumerations



SIRI-SX ENUMERATIONS

Figure 15-6 summaries the enumerations that are specific to SIRI-SX. These also appear in context on individual diagrams.

unknownunverifiedverifiedverifiedAsDuplicate

«enumeration»VerificationEnum

certainveryReliablereliableunreliableunconfirmed

«enumeration»QualityIndexEnum

draftdraftPendingApprovalapprovedDraftopenclosingclosed

«enumeration»SituationProgressEnum

publicstaffemergencyServicesmanagementstationStaffinfoServicesauthoritiestransportOperators

«enumeration»AudienceEnum

veryHighhighmediumlowveryLow

«enumeration»SensitivityEnum

bothfromto

«enumeration»ConnectionDirectionEnum

SIRI-SX Enumerations

© 2006 SIRI

plannedunplannedboth

«enumeration»PredictabilityEnum

generaloperatornetworkroutelineplacestopPlacestopPlaceComponentstopPointvehicleJourneydatedVehicleJourneyconnectionLinkinterchange

«enumeration»ScopeTypeEnum

causeeffectcorrectssupercedessupercededByassociation

«enumeration»RelatedEnum

emailphonefaxpostfeedradiotvwebpagertextother

«enumeration»SourceEnum

editableversionedreleased

«enumeration»ElementStatusEnum

continentWidenationalneighbouringCountriesnotSpecifiedregional

«enumeration»DX2-DTs::AreaOfInterestEnum

automobileClubPatrolcameraObservationfreightVehicleOperatorinductionLoopMonitoringStationmicrowavedMonitoringStationmobileTelephoneCallernonPoliceEmergencyServicesPatrolotherInformationotherOfficialVehiclepolicePatrolprivateBreakdownServicepublicAndPrivateUtilitiesregisteredMobileObserverroadAuthoritiesroadOperatorPatrolroadsideTelephoneCallerspotterAircrafttrafficMonitoringStationtransitOperatorvehicleProbeMeasurementvideoProcessingMonitoringStation

«enumeration»DX2-DTs::RoadSourceMethodEnum

realsecurityExercisetechnicalExercisetest

«enumeration»DX2-DTs::InformationStatusEnum

SIRI-SX / Datex2 Enumerations

© 2008 SIRI

«enumeration»SX-Enm-DTX::SourceMethodEnum

certainprobableriskOfimprobable

«enumeration»DX2-DTs::ProbabilityOfOccurenceEnum

delayLongerThanSixHoursdelayBetweenThreeHoursAndSixHoursdelayBetweenOneHourAndThreeHoursdelayBetweenThirtyMinutesAndOneHoursdelayLessThanThirtyMinutesnegligble

«enumeration»DX2-DTs::DelayBandEnum

delaysdelaysOfLongDurationlongDelaysveryLongDelays

«enumeration»DX2-DTs::DelayTypeEnum

athleticsMeetingballGamebaseballGamebasketballGamebycycleRaceboatRaceboxingTournamentbullFightceremonialEventconcertcricketMatchexhibitionfairfestivalfilmTVMakingfootballMatchfunfairgolfTournamenthockeyGamehorseRaceMeetinginternationalSportsMeetingmajorEventmarathonmarketmatchmotorSportRaceMeetingparaderaceMeetingrugbyMatchseveralMajorEventsshowshowJumpingsportsMeetingstateOccassiontennisTournamenttournamenttradeFairwaterSportsMeetingwinterSportsMeetingother

«enumeration»DX2-DTs::PublicEventTypeEnum

Figure 15-6 UML Diagram of SIRI-SX Enumerations



IFOPT ENUMERATIONS FOR SIRI-SX

Figure 15-7 summarises the IFOPT STOP PLACE enumerations that are used in SIRI-SX. These mostly also appear in context on individual UML diagrams.

Figure 15-7 UML Diagram of IFOPT Stop Place Enumerations



TPEG MISCELLANEOUS ENUMERATIONS FOR SIRI-SX

Figure 15-8 summarises the miscellaneous TPEG enumerations that are used in SIRI-SX. These mostly also appear in context on individual UML diagrams.

unknownalteredcancelleddelayeddivertednoServicedisruptedadditionalServicespecialServiceonTimenormalServiceintermittentServiceshortFormedServicefullLengthServiceextendedServicesplitingTrainreplacementTransportarrivesEarlyshuttleServicereplacementServiceundefinedServiceInformation

«enumeration»TpegServiceConditionEnum



TPEG MiscellaneousEnumerations

© 2007 SIRI

unknownmondaytuesdaywednesdaythursdayfridaysaturdaysundaymondayToFridaymondayToSaturdayweekendspublicHolidayholidayregionalHolidaynationalHolidaysundaysAndPublicHolidaysschooldayseverydayundefinedDayType

«enumeration»TpegDayTypeEnum

TPEG pti_34

Tpeg pti-26

unknownallTicketClassesValidfullFareOnlycertainTicketsOnlyticketWithReservationspecialFareonlyTicketsOfSpecifiedOperatornoRestrictionsnoOffPeakTicketsnoWeekendReturnTicketsnoReducedFareTicketsunknwonTicketRestriction

«enumeration»TpegTicketRestrictionEnum

tpeg pti_25

tpeg pti_13

unknownnetworkroutepointindividualServiceundefined

«enumeration»TpegReportEnum

tpeg pti_27

unknownstartPointdestinationstopvianotStoppingtemporaryStoptemporarilyNotStoppingexceptionalStopadditionalStoprequestStopfrontTrainDestinationrearTrainDestinationthroughServiceDestinationnotViaalteredStartPointalteredDestinationundefinedRoutePoint

«enumeration»TpegRoutePointEnum

tpeg pti_5

unknownconnectionreplacementalternativeconnectionNotHeldconnectionHeldstatusOfConnectionUndecidedundefined

«enumeration»TpegInterchangeStatusEnum

tpeg pti 31

Figure 15-8 UML Diagram of TPEG Enumerations



TPEG MODE ENUMERATIONS

Figure 15-9 summarises the TPEG mode enumerations that are used in SIRI-SX. These mostly also appear in context on individual UML diagrams.

Figure 15-9 UML Diagram of Tpeg submodes



16. ANNEX A NOTATION

The diagrams in this document follow normal UML notation for class diagrams with the addition of colour (see below), and the use of certain conventions to represent composition as used in XML.

ENTITIES

Classes are indicated by square boxes with the name of the class across the top. Operations and Visibility are omitted. The attributes types, or all of the attributes may be suppressed in summary diagrams, or to show a summary reference.

ENUMERATIONS

Enumerations are generally shown as data types a square box with an <<enumeration>> stereotype. They are included in diagrams in context if space permits, using a dependency relationship (dotted line) from the class with attributes that are constrained by the enumeration. They are also summarised on separate diagrams at the end. Visibilities are omitted.

GROUPS

As well as the normal use of Classes to indicate the entities of the model, classes are also used for named groups of reusable elements which occur on more than one entity, for example AimedArrivalInfo, or ServiceInfo

see discussion of serialisation and containment below. In this case a steorotype of <<group>> is shown. These can be considered as complex data types.

NOTES

Notes are indicated as boxes with turned up corners, generally connected to the class or relationship they annotate with a dotted dependency line.

RELATIONSHIPS

Normal UML relationships are used:

1. Inheritance: line with white arrow from subtype to supertype. The subtype has all the attributes and operations of the supertype.

2. Association: other unbroken lines.

Cardinalities of associations are marked using UML conventions for multiplicities and optionality, i.e. min:max, for example [ 0:1] indicates there may be a minimum of zero and a maximum of one, [1:*] indicates there must be a minimum of one and there can be many. [1] by itself means [1:1]. [*] by itself means [0:*]. The multiplicities indicate if there are one or many. The optionality indicates whether the end must be populated if the relationship is present.

Aggregation is indicated by a black diamond (this typically corresponds to direct containment in an XML document): indicating the part is created and destroyed with the whole.



A shared composition is indicated by a white diamond, in which case the child element is integral to the parent component, but the child exists independently (and typically will have a unique identifier).

Direction of Navigability is indicated by an arrow head in the direction of navigability.

3. Dependency: Dotted Line. These are also used to show enumerated values

USE OF COLOUR

To facilitate reading, Classes are coloured to indicate their nature. This is purely a local Handbook convention (not part of UML) and is used as follows

Purple: Common Abstract Message Transport Framework elements. Typically these are the request & response wrapper elements. E.g. ServiceDelivery and are the same for all Functional services.

Salmon: Common Abstract Transport Framework elements, Typically these are supertypes. E.g. AbstractItem

Orange: Functional Service Elements. E.g. StopMonitoringDelivery. These are specific and different for each service, but populated to a common pattern, e.g. with xxxTopics. xxxPolicies, xxxDeliveries etc

Yellow: Domain model elements that correspond to the main payload content of deliveries: typically these are views of Transmodel entities. Dark yellow indicates the concrete container class, e.g. MonitoredVehicleJourney. Light Yellow indicates an embedded reusable element that makes up part of a concrete composite (And may correspond to a Transmodel Entity).

White: References to the identifiers domain model entities, corresponding to the Transmodel concepts.

SERIALISATION: CONTAINMENT & REFERENCE

The primary concrete expression of SIRI is as an XML schema, for which object references must be serialised either through containment (i.e. expressing an aggregation by embedding a child entity within a parent element s tags) or reference (i.e. serialising an association by including a reference to the identifier of the associated entity. It is therefore useful to adopt diagramming and naming conventions that indicate whether a particular relationship is expressed in the SIRI XML schema by containment or by reference.

An explicit attribute is shown on the UML diagrams to indicate an aggregation relationship is implemented as physical containment, using the element name indicated by the attribute. The attribute name will be in the plural if the multiplicity is many . The data type of the attribute will be that of the contained element. For example, the DatedCalls attribute in Figure 16-2 below holds multiple instances of DatedCall..

An explicit attribute is shown on the UML diagrams to indicate that an association is serialised as a reference. The attribute name on the referring entity generally ends in Ref to indicate a reference to another entity, and the data type name generally ends in Code or Id . The data type of the attribute will be the unique identifier of the referenced element.



For example, the StopPointRef attribute in Figure 16-2 below which implements the reference from DatedCall to StopPoint is of type StopPointCode.

In addition, Where attribute values are constrained to particular values a dotted line to a enumeration is shown. E.g. the line to ArrivalActivityEnum in Figure 16-2 below.

Where attributes are grouped as XML groups and used to compose different entities, a class is used to indicate the group. Such classes are usually shown in a lighter shade of colour with a stereotype of <<group>>. For example the AimedArrivalInfoclass in Figure 16-2 below.

ALTERNATIVE REPRESENTATIONS OF XML STRUCTURES IN UML

Note that to depict a pure object model in UML one does not strictly need to show an explicit attribute in the parent for a child component (it could be represented just by an association to the contained element), but doing so helps to make clear the order in which attributes appear in the XML and the name of any wrapper tag used to group multiple child instances. Similarly other associations do not strictly need to show the implementing attribute. In the UML diagrams for SIRI we therefore generally show an attribute with which to implement each association.

UML supports a variety of ways for depicting the reuse of data structures, corresponding to different OO programming mechanisms, for example, by inheritance (single or multiple) using either class inheritance or interface conformance; or by aggregation, embedding complex data types in more than one entity. XML allows only single parent class inheritance, so the SIRI XML schema makes greater use of composition than of inheritance, assembling standard data structures (encoded as Groups in XML) into concrete classes. For clarity, we therefore often show these groups in the diagrams as distinct classes with a <<group>> stereotype, even though in the concrete XML they are repeated inline.

We illustrate these differences in Figure 16-1 and Figure 16-2 below, which show two different representations in UML of the same model of a timetable (this is a simplified version of the SIRI Dated Journey).

In Figure 16-1, no attributes are shown to implement the aggregation, and all the attributes are shown in-line. References to external entities are shown as attributes though these too might be omitted (JourneyPatternRef, BlockRef, CourseOfJourneyRef, StopPointRef).



Figure 16-1 Simple Object model

In Figure 16-2, an attribute Calls is shown on DatedVehicleJourney to implement the DatedCalls aggregation. Furthermore, certain of the attributes which occur in groups that are reused elsewhere are shown as separate view classes (JourneyPatternInfo, AimedArrivalInfo, AimedDepartureInfo, StopPointInSequence), with a <<group> stereotype. These are inlined in the XML. Points where extensions may be added are indicated by an Extensions attribute. Operations are not shown.

The data structures are functionally equivalent.

Figure 16-2 Explicit representation of references and of groups

XML FRAGMENT FOR EXAMPLE

The following XML fragment shows a serialisation of some data in an XML document in accordance with Figure 16-2, (This is a simplified version of the actual SIRI DatedVehicleJourney entity)

<DatedVehicleJourney>



<JourneyPatternRef>JP56789T</JourneyPatternRef>



<DatedVehicleJourneyCode>DVC0008767</DatedVehicleJourneyCode>

<! Journey Pattern Info -->

<RouteRef>RT0004</RouteRef >

<DirectionRef>Northbound</DirectionRef >

<ExtraJourney>false</ExtraJourney>

<! Association to Block -->

< BlockRef>013564</BlockRef

<! Contained children - Callss -->

<Calls>



<DatedCall>

<! Stop point in sequence Group -->

<StopPointRef>HLTS00101</StopPointRef>

<StopName>Market Place</StopName >

<DestinationDisplay>Hospital</DestinationDisplay>



<AimedDepartureTime>2001-12-17T09:32:47-05:00</AimedDepartureTime >

<DeparturePlatformName>Stance 1</DeparturePlatformName>

</DatedCall>



<DatedCall>



<StopName>Hospital</StopName>

<DestinationDisplay>Station</DestinationDisplay>






</DatedCall>



<DatedCall>



< StopName>Main Station</ StopName >






<DepartureBoardingActivity>NoBoarding</DepartureBoardingActivity>

</DatedCall>

..

</Calls>

</DatedVehicleJourney>

</DatedTimetableVersionFrame>



ORDER OF ATTRIBUTES

Attributes appear within classes within the same order as in the XML.

DIRECTION OF READING

Where possible a convention is followed to places parent elements above or left and child elements below, or to the right.

SIMPLE DATA TYPES

XML simple types are used, along with a number of common types such as string tagged with a language attribute. These are generally shown in lower Camel Case, e.g. dateTime.

Simple data type names that are defined for SIRI are shown in Upper Camel case.

REUSABLE COMPLEX DATA TYPES

A small number of basic complex type: Location, FacilityChange, HalfOpenDate FramedVehicleJourneyRef are used extensively and are not repeated on individual pages. They are shown on a separate page

SIRI Handbook & Functional Service Diagrams - Easily...

Documents

Transcript of SIRI Handbook & Functional Service Diagrams - Easily...