Handbookv 15

.
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
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 © Copyright 2007, 2008 Kizoom Limited:

107-109 Clifton Street,
London EC2A 4LD All rights Reserved.
Telephone: 207 749 2670
Company Registration Number : 3745127
Author:
Nicholas Knowles
© Copyright Kizoom 2006-2007 Page 2

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/

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
Example use of SIRI Services
PT
ET
AVMSST PT
SM PT ET
GMS ET JP
VM SM
SM ET
Web
VM SM& Mobile
AVMSST GMS
SM
GMS GMS GMS

GMS
ICS ICS Alerts
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.
Separation of concerns
Data Exchange Transport

Content Behaviour Protocol
defined well-defined interactions Independent e.g.

XML Schema with XML schema HTTP POST,
For payload Representations SOAP.
parameterising behaviour
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)
SubscriptionResponse
DataReadyNotification
DataReadyResponse
DataSupplyRequest
Subscription Manager DataSupplyDelivery
TerminationRequest
terminate
Publish / Subscribe
TerminationResponse
With Fetched Delivery
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).
1 SIRI - Summary of relevant

route
TM-Mdl::Route Transmodel entities
route 1 TM-Mdl::Line © 2007 SIRI
1 TM-Mdl::Block
0..*
service pattern 1 0..1 pattern line
TM-Mdl::JourneyPattern 1
0..1
runs
0..* * 1
0..* 0..*
TM-Mdl::ServicePattern info 1
TM-Mdl::VehicleJourney
1 block
stops *
0..1 1
stops
«group» TM-Mdl::CourseOfJourney
0..* 2..* Siri Mdl::VehicleJourneyInfo
origin
0..1
«group» 0..* 0..*
TM-Mdl::StopPointInSequence passing times
run
0..* 0..* 0..*
0..1
at
0..1 destination
0..1 TM-Mdl::DatedVehicleJourney
TM-Mdl::StopPoint 1
1 0..*
calls
* time
TM-Mdl::PassingTime Siri Mdl::MonitoredVehicleJourney
2..* 1
stop point 0..*
Siri Mdl::DatedCall
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.

subscriber, consumer and producer services

each keep their own subscription
store of active subscriptions.
subscriber
Siri Mdl::Participant
* producer
* ParticipantCode[1] 0..1 subscriber
1 LastUsedSituationNumber[0..1]
SubscribingService 1
1 manager for
SubscriberRef[1] : ParticipantCode 1 0..*
1
Endpoint[1] : EndPointAddress
LastUsedSubscription[1] : SubscriptionCode 1 serves
SubscriptionManager 0..*
1
0..1
consumer for 1
ProducerService
1 1 filters
ProducerRef[1] : ParticipantCode
subscriber EndPoint[1] : EndPointAddress
ConsumerService subscriber
* LastUsedIdentifier[0..1] : MessageQualifier
ConsumerRef[1] : ParticipantCode
ConsumerEndPoint[1] : EndPointAddress
subscriptions SubscriptionFilter
LastUsedMessageIdentifier[1] : MessageQualifier
FilterCode[1] : SubscriptionFilterCode creates
SubscriberRef[1] : ParticipantCode
1
subscriptions
creates 0..1 matches
0..* filter 0..1
filtered by
AbstractFunctionalSubscriptionRequest 0..*
0..* 0..* 0..*
SubscriberRef[1] : ParticipantCode 0..*
SubscriptionIdentifier[1] : SubscriptionCode
InitialTerminationTime[1] : dateTime AbstractFunctionalServiceDelivery
Subscription
SubscriberRef[1] : ParticipantCode ResponseTimeStamp[1] : dateTime
requests 0..* RequestMessageRef[0..1] : MessageQualifier
0..* SubscriptionIdentifier[1] : SubscriptionCode
subscription SubscriberEndPoint[1] : EndPointAddress SubscriberRef[0..1] : ParticipantCode
ConsumerEndPoint[1] : EndPointAddress SubscriptionFilterRef[0..1] : SubscriptionFilterCode
ValidUntil[1] : dateTime SubscriptionRef[0..1] : SubscriptionCode
request 1 Address[0..1] : EndPointAddress
fulfils ResponseMessageIdentifier[0..1] : MessageQualifier
0..1 Status[0..1]
1 1
1 returns : boolean
ErrorCondition[0..1] : ErrorCondition
SiriXxxFsRequest, SubscriptionPolicy 0..* ValidUntil[0..1] : dateTime
ShortestPossibleCycle[0..1] : positiveDuration
SiriXxxFsSubscriptionRequest
request payload
1
AbstractFunctionalServiceRequest granted for SiriXxxFsDelivery
RequestTimestamp[1] : dateTime
MessageIdentifier[0..1] : MessageQualifier
1
contents
SubscriptionRequest AbstractItem
RequestTimestamp[1] : dateTime RecordedAtTime[1] : dateTime
Address[0..1] : EndPointAddress
0..* *
RequestorRef[1] : Participant
MessageIdentifer[0..1] : MessageQualifier payload
ConsumerAddress[0..1] : EndPointAddress
SubscriptionFilterIdentifier[0..1] : nmtoken SiriXxxItem
Topics, Policies
SubscriptionContext[0..1] : SubscriptionContext 1
requests SiriXxxFsRequest
1
status for SIRI Publish Subscribe Entities
* 1
1
SubscriptionResponse 1
& Generic messages
© 2007 SIRI
ResponseTimeStamp[1] : dateTime
Address[0..1] : EndPointAddress ResponseStatus
ResponderRef[0..1] : ParticipantCode
RequestMessageRef[0..1] : MessageQualifier
ResponseStatus[0..1] : ResponseStatus
SubscriberRef[0..1] : ParticipantCode
SubscriptionManagerAddress[0..1] : EndPointAddress
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
ServiceStartedTime[0..1] : dateTime
SubscriptionRef[0..1] : SubscriptionCode
Extensions[0..1] : any statuses Status[0..1] : boolean
1 ValidUntil[0..1] : dateTime
*
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 M ONITORING (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

0..* producer 1
AbstractProducerResponse Participant SIRI-SM Summary
errors
StopMonitoringDelivery
© 2006 SIRI
ServiceDelivery ErrorCondition
1 0..1
1
notice cancellations
StopMonitoringDelivery
deliveries
version[1]
1
Note[0..1]
* Extensions[0..1]
visits cancellations
0..*
1 1 1
MonitoredStopVisitCancellation
cancels
MonitoringRef[1]
VisitNumber[1]
0..* 0..1 0..1 1 LineRef[1]
DirectionRef[1]
line notices Direction
VehicleJourneyRef[0..1] 0..*
MonitoredStopVisit 1 ClearDownRef[0..1]
MonitoringRef[1] JourneyPatternInfo[0..1]
CleardownRef[0..1] montor
0..* StopLineNotice Reason[0..1]
MonitoredVehicleJourney[1] MonitoringRef[1] Extensions[0..1] StopLineNoticeCancellation
StopVisitNote[0..1] LineRef[1] MonitoringRef[1]
Extensions[0..1] 0..*
DirectionRef[1] cancels LineRef[1]
LineNote[0..1] DirectionRef[1]
0..1 SituationRef[0..1] Extensions[0..1]
1 0..1 Extensions[0..1] 0..* 0..1
montor 1
Route route Monitor
0..*
0..1 journey 1
JourneyPattern line line
0..*
Line 0..*
0..1 0..1
«group» 0..1 pattern 1
pattern JourneyPatternInfo journey «group»
MonitoredJourneyIdentity
0..* JourneyPatternRef[0..1] DatedVehicleJourney
VehicleMode[0..1] LineRef[0..1]
1 DirectionRef[0..1]
RouteRef[0..1] 0..1 1
PublishedLineName[0..1] pattern info 0..* FramedVehicleJourneyRef[1..1]
DirectionName[0..1]
ExternalLineRef[0..1] MonitoredVehicleJourney «group» 1
1..1
«group» 1 MonitoredVehicleJourneyIdentity[1] FramedVehicleJourneyRef 1 journey
ServiceInfoinfo JourneyPatternInfo[1] DataFrameRef[1]
1
VehicleJourneyInfo[1] DatedVehicleJourneyRef[1]
0..1 0..1
journey info1 DisruptionInfo[0..1]
«group» JourneyProgress[0..1] identity
VehicleJourneyInfo TrainBlockPart[0..1]
OperationalInfo[0..1] 1
0..1 progress 1 PreviousCalls[0..*] disruption
location 1 «group»
MonitoredCall[0..1]
ProgressInfo
OnwardCalls[0..*]
0..1 IsCompleteCallSequence[0..1] 1 See Monitored
AbstractMonitoredCall Extensions[0..1] Vehicle Journey
StopPointRef[0..1] onward Diagrams for
Location
VisitNumber[0..1] details
1 1 current1 0..1
Order[0..1]
StopPointName[0..1] previous
«group»
0..1 0..* DisruptionInfo
stop 0..*
0..* SituationRef[0..1] reference
MonitoredCall FacilityChange[0..1] 1
OnwardCall
PreviousCall VehicleAtStop[0..1]
VehicleLocationAtStop[0..1] VehicleAtStop[0..1]
VehicleAtStop[0..1] TimingPoint[0..1] 0..1
ReversesAtStop[0..1]
0..1 ArrivalTimes[0..1] AimedArrivalTimes[0..1]
PlatformTraversal[0..1]
DepartureTimes[0..1] ArrivalInfo[0..1] 0..1
SignalStatus[0..1]
Extensions[0..1] AimedDepartureTimes[0..1]
StopPoint CallNote[0..1]
Disruption[0..1] DepartureInfo[0..1] «group»
ArrivalTimes[0..1] HeadwayInfo[0..1] SituationReference
ArrivalInfo[0..1] Extensions[0..1] disruption
DepartureTimes[0..1]
DepartureInfo[0..1] 1
HeadwayInfo[0..1]
Extensions[0..1]
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.

0..1 producer Siri Rqs::AbstractProducerResponse

SIRI-SM
Siri Mdl::Participant ResponseTimeStamp : dateTime
StopMonitoringDelivery 1 0..* ProducerRef : ParticipantCode
© 2006 SIRI
Address : EndPointAddress
ResponseMessageIdentifier : MessageQualifier
subscriber RequestMessageRef : MessageQualifier
Siri Rqs::AbstractFunctionalServiceDelivery
ResponseTimeStamp[1] : dateTime 0..*
0..1 1 Siri Rqs::ServiceDelivery
RequestMessageRef[0..1] : MessageQualifier errors
SubscriberRef[0..1] : ParticipantCode Status : boolean
errors
SubscriptionFilterRef[0..1] : SubscriptionFilterCode ErrorCondition : ErrorCondition
Siri Rqs::ErrorCondition 1
SubscriptionRef[0..1] : SubscriptionCode MoreData : boolean
0..* Error[1] : AbstractError
1 Description[1] : ErrorDescription deliveries
ResponseMessageIdentifier[0..1] : MessageQualifier *
Status[0..1] : boolean
1 StopMonitoringDelivery
ValidUntil[0..1] : dateTime
ShortestPossibleCycle[0..1] : positiveDuration 1 version[1] : versionString
1
Note[0..1] : populatedString
Extensions[0..1]
visits 1
Siri Rqs::AbstractItem
RecordedAtTime[1] : dateTime
Siri Rqs::AbstractReferencedItem
line notices cancellations
Siri Rqs::AbstractIdentifiedItem IdentifiedItemRef[0..1] : IdentifiedItemCode
IdentifiedItemCode[0..1] : IdentifiedItemCode
0..*
MonitoringRef[1] : MonitoringCode
0..* VisitNumber[1] : VisitNumber
MonitoredStopVisit
LineRef[1] : LineCode
MonitoringRef[1] : MonitoringCode DirectionRef[1] : DirectionCode
CleardownRef[0..1] : CleardownCode VehicleJourneyRef[0..1]
MonitoredVehicleJourney[1] : MonitoredVehicleJourney cancels ClearDownRef[0..1] : CleardownCode
StopVisitNote[0..1] : populatedString JourneyPatternInfo[0..1] : JourneyPatternInfo
Extensions[0..1] : any 0..1 Reason[0..1] : populatedString
1
Extensions[0..1] : any
montor 0..*
1 0..*
0..1 SX-Mdl::AbstractSituationElement
0..1 situation
monitor StopLineNotice
Siri Mdl::Monitor 0..1
journey MonitoringRef[1] : MonitoringCode 0..*
See Monitored 0..* DirectionRef[1] : DirectionCode
LineNote[0..1] : populatedString 1 cancels
Vehicle Journey StopLineNoticeCancellation
Diagrams for SituationRef[0..1] : SituationCode
Extensions[0..1] MonitoringRef[1] : MonitoringCode
1 details 0..1 1 LineRef[1] : LineCode
DirectionRef[1] : DirectionCode
1 direction Extensions[0..1]
Siri Mdl::MonitoredVehicleJourney 0..*
MonitoredVehicleJourneyIdentity[1] : MonitoredJourneyIdentity TM-Mdl::DataFrame
0..1 frame
JourneyPatternInfo[1] : JourneyPatternInfo 0..*
VehicleJourneyInfo[1] : VehicleJourneyInfo
DisruptionInfo[0..1] : DisruptionInfo TM-Mdl::Direction0..1
«group»Siri Mdl::FramedVehicleJourneyRef
JourneyProgress[0..1] : ProgressInfo
line
TrainBlockPart[0..1] : TrainBlockPart 0..* DataFrameRef[1] : DataFrameCode
OperationalInfo[0..1] : OperationalInfo directions DatedVehicleJourneyRef[1] : DatedVehicleJourneyCode
PreviousCalls[0..*] : PreviousCall
MonitoredCall[0..1] : MonitoredCall 1 journey
1 1 0..*
OnwardCalls[0..*] : OnwardCall line 1
IsCompleteCallSequence[0..1] : boolean 1
TM-Mdl::Line journey
Extensions[0..1] : any TM-Mdl::DatedVehicleJourney
0..1
previous onward 0..* 1
1 1 1
current identity
0..* 0..*
«group»Siri Mdl::MonitoredJourneyIdentity
0..1 LineRef[0..1] : LineCode
Siri Mdl::PreviousCall Siri Mdl::OnwardCall
DirectionRef[0..1] : DirectionCode
FramedVehicleJourneyRef[1..1] : FramedVehicleJourneyRef
Siri Mdl::MonitoredCall 1..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 Definition. Purpose

Level
minimum Return only minimum data: a single MonitoredCall with Used for exchanging just real-time
a stop ids and passing time data between systems that are not
concerned with other details.
basic Return useful basic minimum data. A single Used to drive simple displays with
MonitoredCall for each MonitoredVehicleJourney limited space that show just lines and
visiting the Stop, with passing times, and line id. passing times and line numbers.
normal Return a single MonitoredCall at the stop for each Use for normal departure boards that
MonitoredVehicleJourney, populated with with times, show arrival/departure times for each
stop id, Stop name, DestinationDisplay values (i.e. vehicle along with names (but not a
headings), status etc. calling pattern).
calls Return additional information including Onwards and Use for departure boards that need to
Previous elements with the previous and onward calling show the full calling pattern or the
pattern, modulated by the NumberOfCalls on the onward calling pattern.
request.
full Return all information including full calling pattern, Used for data exchange between
operational data (BlockRef, VehicleRef, etc), progress operational services, or for advanced
data, journey pattern references etc 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.
0..* block 0..1

TM-Mdl::JourneyPattern pattern 1 TM-Mdl::Block
0..1 TM-Mdl::DatedVehicleJourney 0..1
0..1 journey TM-Mdl::DataFrame
0..*
0..1 TM-Mdl::Vehicle
«group» 1
pattern
JourneyPatternInfo «group» 0..1
0..* JourneyPatternRef[0..1] TM-Mdl::Line FramedVehicleJourneyRef
journey0..*
VehicleMode[0..1] DataFrameRef[1] TM-Mdl::CourseOfJourney
RouteRef[0..1] 0..1 0..1 1 DatedVehicleJourneyRef[1] 0..*
line 0..*
PublishedLineName[0..1] 1
0..1
DirectionName[0..1] «group»
ExternalLineRef[0..1] MonitoredJourneyIdentity «group»OperationalInfo
0..1 route
LineRef[0..1] BlockRef[0..1]
TM-Mdl::Route 0..*TM-Mdl::TrainPart
0..* pattern info 0..* DirectionRef[0..1] CourseOfJourneyRef[0..1]
FramedVehicleJourneyRef[1..1] VehicleRef[0..1] train
identity operational 0..* 0..1
«group»VehicleJourneyInfo 1 1
ServiceInfo[0..1] 1..1 0..1
TM-Mdl::TrainBlockPart
OriginRef[0..1] MonitoredVehicleJourney
DestinationName[0..1] train block NumberOfBlockParts[0..1]
1 MonitoredVehicleJourneyIdentity[1] TrainPartRef[0..1]
OriginShortName[0..1]
0..1 JourneyPatternInfo[1] PositionOfTrainBlockPart[0..1]
Via[0..*]
DestinationRef[0..1] VehicleJourneyInfo[1] 0..1
DisruptionInfo[0..1] 1
DestinationName[0..1] 1
DestinationShortName[0..1] JourneyProgress[0..1]
VehicleJourneyNote[0..1] TrainBlockPart[0..1]
JourneyNote[0..1] OperationalInfo[0..1] 1 «group»ProgressInfo
HeadwayService[0..1] PreviousCalls[0..*] progress
0..*
destination MonitoredCall[0..1] Monitored[0..1]
OriginAimedDepartureTime[0..1] MonitoringError[0..1]
DestinationAimedDepartureTime[0..1] OnwardCalls[0..*] 0..1
1 locationInCongestion[0..1]
IsCompleteCallSequence[0..1]
Extensions[0..1] Loc Mdl::Location 0..1 InPanic[0..1]
1 info 0..* 1 PredictionInaccurate[0..1] disruption
0..1 DataSource[0..1]
origin 1 stop
0..1 «enumeration» ConfidenceLevel[0..1]
0..1 AbstractMonitoredCall OccupancyEnum
TM-Mdl::StopPoint 0..* VehicleLocation[0..1]
StopPointRef[0..1] full Bearing[0..1]
0..1
«group»ServiceInfo VisitNumber[0..1] seatsAvailable ProgressRate[0..1]
OperatorRef[0..1] Order[0..1] standingAvailable Occupancy[0..1]
ProductCategoryRef[0..1] VehicleFeature StopPointName[0..1] Delay[0..1]
ServiceFeatureRef[0..*] ProgressStatus[0..1]
0..1
0..*
VehicleFeatureRef[0..*] OnwardCall
0..*
0..* ServiceFeature VehicleAtStop[0..1]
operator 0..1
0..* 1 TimingPoint[0..1]
0..1 arrival «enumeration»
AimedArrivalTimes[0..1]
PreviousCall ProgressRateEnum
ArrivalInfo[0..1]
TM-Mdl::Operator VehicleAtStop[0..1] 1 AimedDepartureTimes[0..1] noProgress
1 headway slowProgress
ArrivalTimes[0..1] DepartureInfo[0..1]
DepartureTimes[0..1] HeadwayInfo[0..1] arrival normalProgress
Extensions[0..1] Extensions[0..1] 1 fastProgress
0..1 *
unknown
times 1 «group»HeadwayInfo 1 1 «group»

0..1 0..1 AimedArrivalTimes
«group»ArrivalInfo AimedHeadWayInterval[0..1]
departure AimedArrivalTime[0..1]
ExpectedHeadwayInterval[0..1]
ArrivalStatus[0..1] 0..1 ExpectedArrivalTime[0..1]
ArrivalPlatformName[0..1] departure
times ArrivalBoardingActivity[0..1] arrival «group»
MonitoredCall headway
«enumeration» AimedDepartureTimes
VehicleAtStop[0..1]
1
ArrivalActivityEnum 0..1 AimedDepartureTime[0..1]
VehicleLocationAtStop[0..1] 0..1
alighting ExpectedDepartureTime[0..1]
ReversesAtStop[0..1]
0..1 noAlighting PlatformTraversal[0..1] 1
passThru «group»DepartureInfo
SignalStatus[0..1] departure
1 CallNote[0..1] DepartureStatus[0..1] 0..1
«group»DepartureTimes 0..1departure times Disruption[0..1] DeparturePlatformName[0..1]
AimedDepartureTime[0..1] ArrivalTimes[0..1] 10..1 DepartureBoardingActivity[0..1]
ActualDepartureTimes[0..1] ArrivalInfo[0..1] disruption
ExpectedDepartureTime[0..1] DepartureTimes[0..1] «group»DisruptionInfo
DepartureInfo[0..1] 1 0..1 SituationRef[0..1]
HeadwayInfo[0..1] «enumeration» FacilityChange[0..1]
«group»ArrivalTimes Extensions[0..1] TimeStatusEnum
«enumeration»
AimedArrivalTime[0..1] 0..1 arrival times DepartureActivityEnum early reference
1
0..1
ActualArrivalTimes[0..1] 1 onTime
1 boarding
ExpectedArrivalTime[0..1] call delayed 0..1
noBoarding
«group»CallInfo arrived
0..1 passThru
SIRI Summary TimingPoint[0..1] cancelled «group»
BoardingStretch[0..1] noReport SituationReference
MonitoredVehicleJourney
© 2006 SIRI RequestStop[0..1]
DestinationDisplay[0..1]
0..*
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

6. SIRI VEHICLE M ONITORING (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 Used to drive simple movement
vehicle journey e.g. Line id - and supply simple displays displays with limited space
ProgressInfo such as a current location, that show just lines and passing
times and line numbers.
normal Return a single MonitoredCall at the current or next Use for on and off board next stop
stop for each MonitoredVehicleJourney, populated displays and visualisations.
with times, stop id, Stop name, DestinationDisplay
values (i.e. headings), status etc.
calls Return additional information including current Use for exchanging data for roaming,
MonitoredCall, Onwards, and Previous elements or for replicating current vehicle
with the previous and onward calling pattern, prediction data to distribution
modulated by the NumberOfCalls on the request. 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, Used for sending data to consumer
operational data (BlockRef, VehicleRef, etc), systems that do not have all the
progress data, journey pattern references etc 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
0..1 producer Siri Rqs::AbstractProducerResponse

SIRI-SM
Siri Mdl::Participant ResponseTimeStamp : dateTime
StopMonitoringDelivery 1 0..* ProducerRef : ParticipantCode
© 2006 SIRI
Address : EndPointAddress
ResponseMessageIdentifier : MessageQualifier
subscriber RequestMessageRef : MessageQualifier
0..1 1 Siri Rqs::ServiceDelivery
RequestMessageRef[0..1] : MessageQualifier errors
SubscriberRef[0..1] : ParticipantCode Status : boolean
errors
SubscriptionFilterRef[0..1] : SubscriptionFilterCode ErrorCondition : ErrorCondition
Siri Rqs::ErrorCondition 1
SubscriptionRef[0..1] : SubscriptionCode MoreData : boolean
0..* Error[1] : AbstractError
1 Description[1] : ErrorDescription deliveries
ResponseMessageIdentifier[0..1] : MessageQualifier *
1 StopMonitoringDelivery
ShortestPossibleCycle[0..1] : positiveDuration 1 version[1] : versionString
1
Note[0..1] : populatedString
Extensions[0..1]
visits 1
line notices cancellations
Siri Rqs::AbstractIdentifiedItem IdentifiedItemRef[0..1] : IdentifiedItemCode
0..*
MonitoringRef[1] : MonitoringCode
0..* VisitNumber[1] : VisitNumber
MonitoredStopVisit
MonitoringRef[1] : MonitoringCode DirectionRef[1] : DirectionCode
CleardownRef[0..1] : CleardownCode VehicleJourneyRef[0..1]
MonitoredVehicleJourney[1] : MonitoredVehicleJourney cancels ClearDownRef[0..1] : CleardownCode
StopVisitNote[0..1] : populatedString JourneyPatternInfo[0..1] : JourneyPatternInfo
Extensions[0..1] : any 0..1 Reason[0..1] : populatedString
1
montor 0..*
1 0..*
0..1 SX-Mdl::AbstractSituationElement
0..1 situation
monitor StopLineNotice
Siri Mdl::Monitor 0..1
journey MonitoringRef[1] : MonitoringCode 0..*
See Monitored 0..* DirectionRef[1] : DirectionCode
LineNote[0..1] : populatedString 1 cancels
Vehicle Journey StopLineNoticeCancellation
Diagrams for SituationRef[0..1] : SituationCode
Extensions[0..1] MonitoringRef[1] : MonitoringCode
1 details 0..1 1 LineRef[1] : LineCode
DirectionRef[1] : DirectionCode
1 direction Extensions[0..1]
Siri Mdl::MonitoredVehicleJourney 0..*
MonitoredVehicleJourneyIdentity[1] : MonitoredJourneyIdentity TM-Mdl::DataFrame
0..1 frame
JourneyPatternInfo[1] : JourneyPatternInfo 0..*
VehicleJourneyInfo[1] : VehicleJourneyInfo
DisruptionInfo[0..1] : DisruptionInfo TM-Mdl::Direction0..1
«group»Siri Mdl::FramedVehicleJourneyRef
JourneyProgress[0..1] : ProgressInfo
line
TrainBlockPart[0..1] : TrainBlockPart 0..* DataFrameRef[1] : DataFrameCode
OperationalInfo[0..1] : OperationalInfo directions DatedVehicleJourneyRef[1] : DatedVehicleJourneyCode
PreviousCalls[0..*] : PreviousCall
MonitoredCall[0..1] : MonitoredCall 1 journey
1 1 0..*
OnwardCalls[0..*] : OnwardCall line 1
IsCompleteCallSequence[0..1] : boolean 1
TM-Mdl::Line journey
Extensions[0..1] : any TM-Mdl::DatedVehicleJourney
0..1
previous onward 0..* 1
1 1 1
current identity
0..* 0..*
«group»Siri Mdl::MonitoredJourneyIdentity
0..1 LineRef[0..1] : LineCode
Siri Mdl::PreviousCall Siri Mdl::OnwardCall
FramedVehicleJourneyRef[1..1] : FramedVehicleJourneyRef
Siri Mdl::MonitoredCall 1..1
Figure 6-4 VehicleMonitoringDelivery - Detail

7. SIRI PRODUCTIONTIM ETABLE (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
requestor
Participant SubscriptionRequest SIRI-PT Summary
requests
requestor
1 0..* ProductionTimetableSubscription
1 1 & ProductionTimetableRequest
0..* © 2007 SIRI
0..*
policies
ServiceRequest ProductionTimetableSubscriptionRequest
1 0..1
1 1
request
requests ProductionTimetableSubscriptionPolicies
0..* 1
policies
ProductionTimetableRequest
1 0..1
1 topics
TimetableVersion
0..1 ProductionTimetablePolicies
0..1
Language[0..1]
version ProductionTimetableTopics IncrementalUpdates[0..1]
operator ValidityPeriod[0..1]
Operator 0..* TimetableVersionRef[0..1]
line OperatorRef[0..1] period
0..1 0..* LineRef[0..1]
DirectionRef[0..1] 0..1
0..* 1
0..1
direction 0..* ValidityPeriod
Line Direction StartTime[1]
0..1 EndTime[1]
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.
context
Siri Rqs::SubscriptionRequest Siri Rqs::SubscriptionContext
0..1
requestor Address[0..1] : EndPointAddress
Siri Mdl::Participant 1
RequestorRef[1] : Participant SIRI-PT
1 MessageIdentifer[0..1] : MessageQualifier
1 1
0..* ConsumerAddress[0..1] : EndPointAddress ProductionTimetableSubscription
SubscriptionFilterIdentifier[0..1] : nmtoken & ProductionTimetableRequest
© 2007 SIRI
requestor requests
subscriber
Siri Rqs::AbstractFunctionalSubscriptionRequest
0..* 0..*
InitialTerminationTime[1] : dateTime
0..*
Siri Rqs::ServiceRequest
RequestContext[1] : RequestContext
RequestTimestamp[1] : dateTime ProductionTimetableSubscriptionRequest
Address[1] : EndPointAddress ProductionTimetableRequest[1] : ProductionTimetableRequest
RequestorRef[1] : ParticipantCode 1
ProductionTimetableSubscriptionPolicies[0..1] : ProductionTimetableSubscriptionPolicies
MessageIdentifer[1] : string Extensions[0..1] : any 1
context policies
1
1
request Siri Rqs::AbstractFunctionalServiceRequest
requests
0..1
MessageIdentifier[0..1] : MessageQualifier 0..1
Siri Rqs::RequestContext
0..* 1
ProductionTimetableSubscriptionPolicies
ProductionTimetableRequest
policies
ProductionTimetableTopics[0..1] : ProductionTimetableTopics
ProductionTimetablePolicies[0..1] : ProductionTimetablePolicies
Extensions[0..1] : any 1
topics
1 0..1
TM-Mdl::TimetableVersion
0..1
ProductionTimetablePolicies
0..1
version Language[0..1] : lang
ProductionTimetableTopics
TM-Mdl::Operator IncrementalUpdates[0..1] : boolean
ValidityPeriod[0..1]
0..1 0..* TimetableVersionRef[0..1] : TimetableVersionCode
operator OperatorRef[0..1] : OperatorCode
LineRef[0..1] : LineCode
0..* DirectionRef[0..1] : DirectionCode
period
line 0..* 1
0..*
TM-Mdl::Line
0..1
directions 0..1
1
Siri Mdl::ValidityPeriod
0..*
StartTime[1] : dateTime
direction
EndTime[1] : dateTime
TM-Mdl::Direction
0..1
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.
subscriber0..1 producer Siri Rqs::AbstractProducerResponse

0..* Siri Mdl::Participant
1 0..* ProducerRef[0..1] : ParticipantCode
SIRI-PT
Siri Rqs::AbstractFunctionalServiceDelivery Address[0..1] : EndPointAddress
ProductionTimetableDelivery ResponseMessageIdentifier[0..1] : MessageQualifier
ResponseTimeStamp[1] : dateTime © 2006 SIRI RequestMessageRef[0..1] : MessageQualifier
errors
SubscriberRef[0..1] : ParticipantCode
Siri Rqs::ErrorCondition
SubscriptionFilterRef[0..1] : SubscriptionFilterCode 0..1
errors
Error[1] : AbstractError 1
SubscriptionRef[0..1] : SubscriptionCode 0..1
Description[1] : ErrorDescription Siri Rqs::ServiceDelivery
ResponseMessageIdentifier[0..1] : MessageQualifier deliveries 1 Status[0..1] : boolean
Status[0..1] : boolean ErrorCondition[0..1] : ErrorCondition
ErrorCondition[0..1] : ErrorCondition MoreData[1] : boolean
ValidUntil[0..1] : dateTime 1
0..*
TM-Mdl::JourneyPattern
TM-Mdl::Mode TM-Mdl::Route
ProductionTimetableDelivery 0..1
Siri Rqs::AbstractItem 0..1 route 0..1
version[1] : versionString 1
RecordedAtTime[1] : dateTime pattern
Extensions[0..1] : any 0..* 0..* 0..*
timetables
1
TM-Mdl::TimetableVersion TM-Mdl::Line line «group»Siri Mdl::JourneyPatternInfo
0..* 0..* line
JourneyPatternRef[0..1] : JourneyPatternCode
default
1
1 0..* VehicleMode[0..1] : Mode
0..1 0..* PT-Mdl::DatedTimetableVersionFrame RouteRef[0..1] : RouteCode
VersionRef[0..1] : TimetableVersionCode 0..1 PublishedLineName[0..1] : populatedString
DirectionName[0..1] : populatedString 0..1
1 ExternalLineRef[0..1] : LineCode
DirectionRef[1] : DirectionCode default 0..1
1 JourneyPatternInfo[0..1] : JourneyPatternInfo
ServiceInfo[0..1] : ServiceInfo 1
DatedVehicleJourneyInfo[0..1] : DatedVehicleJourneyInfo «group»Siri Mdl::ServiceInfo
OperatorRef[0..1] : OperatorCode
journeys
ProductCategoryRef[0..1] : ProductCategoryCode 0..1
TM-Mdl::VehicleJourney default ServiceFeatureRef[0..*] : ServiceFeatureCode
VehicleFeatureRef[0..*] : VehicleFeatureCode stops
PT-Mdl::DatedVehicleJourney «group»
PT-Mdl::DatedVehicleJourneyInfo
DatedVehicleJourneyCode[0..1] : DatedVehicleJourneyCode
0..1 DestinationDisplay[0..1] : populatedString
VehicleJourneyRef[0..1] : VehicleJourneyCode journey info LineNote[0..1] : populatedString
ExtraJourney[0..1] : boolean
0..* 1 HeadwayService[0..1] : boolean
0..* Cancellation[0..1] : boolean
block Monitored[0..1] : boolean
JourneyPatternInfo[0..1] : JourneyPatternInfo 0..1
ServiceInfo[0..1] : ServiceInfo
VehicleJourneyNote[0..1] : populatedString 1
0..1 JourneyNote[0..1] : populatedString pattern
BlockRef[0..1] : BlockCode
CourseOfJourneyRef[0..1] : CourseOfJourneyCode
TM-Mdl::Block Calls[0..*] : DatedCall 1 2..*
«group»
Extensions[0..1] : AllowedResourceUsageExceeded TM-Mdl::StopPointInSequence
runs stop point
1 calls 2..* StopPointRef[1] : StopPointCode
0..* 0..* VisitNumber[0..1] : VisitNumber TM-Mdl::StopPoint
0..1 run 1 0..1 Order[0..1] : positiveInteger
*
StopPointName[0..1] : populatedString stop 1
PT-Mdl::DatedCall 0..*
0..1 call 1 1
TM-Mdl::CourseOfJourney StopPointInSequence[1]
CallInfo[0..1] : CallInfo «group»PT-Mdl::AimedArrivalInfo
CallNote[0..1] : populatedString
«group»Siri Mdl::CallInfo AimedArrivalTime[0..1] : dateTime
FacilityChange[0..1] : FacilityChange 0..1
ArrivalPlatformName[0..1] : populatedString
TimingPoint[0..1] : boolean AimedArrivalInfo[0..1] : AimedArrivalInfo 1 ArrivalBoardingActivity[0..1] : ArrivalActivityEnum
BoardingStretch[0..1] : boolean AimedDepartureInfo[0..1] : AimedDepartureInfo
RequestStop[0..1] : boolean AimedHeadwayInterval[0..1] : positiveDuration
DestinationDisplay[0..1] : populatedString Extensions[0..1] : any 1 to stop
«group»PT-Mdl::AimedDepartureInfo
AimedDepartureTime[0..1] : dateTime
1 0..1
PT-Mdl::TargetedInterchange DeparturePlatformName[0..1] : populatedString
0..* connection DepartureBoardingActivity[0..1] : DepartureActivityEnum
InterchangeCode[0..1] : InterchangeCode
DistributorVehicleJourneyRef[1] : DatedVehicleJourneyCode
DistributorConnectionLinkRef[0..1] : ConnectionLinkCode TM-Mdl::ConnectionLink
DistributorConnectionLink[0..1] : ConnectionLink ConnectionLinkCode[0..1] : ConnectionLinkCode
DistributorVisitNumber[0..1] : VisitNumber StopPointRef[0..1] : StopPointCode 0..*
ref
DistributorOrder[0..1] : positiveInteger StopPointName[0..1] : nlString
StaySeated[0..1] : boolean 1
DefaultDuration[0..1] : duration
Guaranteed[0..1] : boolean 0..1 FrequentTravellerDuration[0..1] : duration
Advertised[0..1] : boolean OccasionalTravellerDuration[0..1] : duration
MaximumWaitTime[0..1] : positiveDuration 0..* 0..1 ImpairedAccessDuration[0..1] : duration
Figure 7-4 ProductionTimetableDelivery - Detail

8. SIRI ESTIM ATEDTIM ETABLE (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
requestor subscriptions
1 SubscriptionRequest
0..* 1
Participant
*
requestor policies
1
EstimatedTimetableSubscriptionRequest
1
0..* 0..1
1
request EstimatedTimetableSubscriptionPolicies
ServiceRequest
requests IncrementalUpdates[0..1]
ChangeBeforeUpdate[0..1]
1 0..* *
SIRI-ET Summary policies
EstimatedTimeTableSubscription EstimatedTimetableRequest 0..1

1
& EstimatedTimeTableRequest
© 2006 SIRI 1
EstimatedTimetablePolicies
topics
Language[0..1]
0..*
0..1 0..* line

version EstimatedTimetableTopics
TimetableVersion Line
PreviewInterval[0..1]
0..1
TimetableVersionRef[0..1] 0..*
0..*
OperatorRef[0..1] direction
0..1 operator LineRef[0..1]
Operator DirectionRef[0..1] Direction
0..*
0..1
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.
0..* producer 1
AbstractProducerResponse Participant SIRI-PT - Summary
EstimatedTimeTableDelivery
© 2006 SIRI
errors
1 0..1 Operator feature
deliveries
1
operator ServiceFeature
0..* 0..1
0..* 0..* 0..1
EstimatedTimetableDelivery
TimetableVersion «group»
Association1 ServiceInfo VehicleFeature
1 delivery service
OperatorRef[0..1]
1 0..1 ProductCategoryRef[0..1] feature
0..* 0..1
0..1 ServiceFeatureRef[0..*]
VehicleFeatureRef[0..*]
0..*
EstimatedJourneyVersionFrame journeys category
VersionRef[0..1] 0..* ProductCategory
Extensions[0..1] 10..* 1
line 0..1
direction block
0..* 0..* «group» Block
1 EstimatedVehicleJourney OperationalInfo
0..1 runs
1 LineRef[1] BlockRef[0..1] 0..* run 1
JourneyPattern DirectionRef[1] CourseOfJourneyRef[0..1]
Direction
DatedVehicleJourneyRef[0..1] VehicleRef[0..1]
0..1 0..*
0..1 DatedVehicleJourneyIndirectRef[0..1]
pattern EstimatedVehicleJourneyCode[0..1] 0..1 0..* vehicle 0..1 *
0..* Line ExtraJourney[0..1]
Cancellation[0..1]
CourseOfJourney
JourneyPatternInfo[0..1] 0..1
«group» 0..1pattern info 1 operational info
ServiceInfo[0..1]
JourneyPatternInfo
VehicleJourneyName[0..1]
JourneyPatternRef[0..1] Vehicle
JourneyNote[0..1] 1 «group»
VehicleMode[0..1] HeadwayService[0..1] SituationReference
RouteRef[0..1] DisruptionInfo[0..1]
PublishedLineName[0..1] 1 Monitored[0..1] «group»
mode disruption 0..1
DirectionName[0..1] PredictionInaccurate[0..1] DisruptionInfo
ExternalLineRef[0..1] 0..* between Occupancy[0..1] reference
1 SituationRef[0..1]
0..1 OperationalInfo[0..1] 0..1 FacilityChange[0..1]
0..* route EstimatedCalls[2..*] 1
Mode IsCompleteStopSequence[0..1]
Extensions[0..1] call info «group»
0..1 0..1
Route CallInfo
1 calls TimingPoint[0..1]
from 0..* 0..1
«group» BoardingStretch[0..1]
stops DatedVehicleJourneyIndirectRef 1
0..* RequestStop[0..1]
OriginRef[1] DestinationDisplay[0..1]
AimedDepartureTime[1] EstimatedCall
DestinationRef[1]
AimedArrivalTime[1] 0..* StopPointInSequence[0..1] «enumeration»
1
ExtraCall[0..1] DepartureActivityEnum
Cancellation[0..1] boarding
1 stop
StopPoint «group» CallInfo[0..1] noBoarding
0..* StopPointInSequence DestinationDisplay[0..1] passThru
at
StopPointRef[1] CallNote[0..1] departure info
1 FacilityChange[0..1]
VisitNumber[0..1]
AimedArrivalTimes[0..1] 1
Order[0..1] 1
StopPointName[0..1] ArrivalInfo[0..1] «group»
2..* DepartureInfo
AimedDepartureTimes[0..1]
DepartureInfo[0..1] 0..1 DepartureStatus[0..1]
«enumeration» 0..1 arrival HeadwayInterval[0..1] DeparturePlatformName[0..1]
«group»
ArrivalActivityEnum Extensions[0..1] DepartureBoardingActivity[0..1]
ArrivalInfo
alighting
ArrivalStatus[0..1]
noAlighting 1 1headway
1
ArrivalPlatformName[0..1]
passThru departure times
ArrivalBoardingActivity[0..1] «enumeration»
0..1 arrival times 0..1 TimeStatusEnum
0..1 early
«group» onTime
«group» delayed
«group»HeadwayInfo AimedDepartureTimes
AimedArrivalTimes arrived
AimedArrivalTime[0..1] AimedHeadWayInterval[0..1] AimedDepartureTime[0..1]
cancelled
ExpectedArrivalTime[0..1] ExpectedHeadwayInterval[0..1] ExpectedDepartureTime[0..1]
noReport
Figure 8-3 EstimatedTimetableDelivery - Summary

ESTIMATEDTIMETABLEDELIVERY DETAIL
Figure 7-4 shows the detailed attributes of an EstimatedTimetableDelivery.
Siri Rqs::AbstractProducerResponse
SIRI-PT Siri Mdl::Participant ResponseTimeStamp[1] : dateTime
EstimatedTimeTableDelivery 1
ProducerRef[0..1] : ParticipantCode
© 2006 SIRI producer Address[0..1] : EndPointAddress
0..1
ResponseMessageIdentifier[0..1] : MessageQualifier
Siri Rqs::AbstractFunctionalServiceDelivery 0..* RequestMessageRef[0..1] : MessageQualifier
ResponseTimeStamp[1] : dateTime 0..* subscriber
RequestMessageRef[0..1] : MessageQualifier 1
SubscriberRef[0..1] : ParticipantCode Siri Rqs::ServiceDelivery
SubscriptionFilterRef[0..1] : SubscriptionFilterCode errors -Status : boolean TM-Mdl::Mode
errors Siri Rqs::ErrorCondition 0..1
SubscriptionRef[0..1] : SubscriptionCode -ErrorCondition : ErrorCondition
Address[0..1] : EndPointAddress -Error : AbstractError -MoreData : boolean
1 0..1
ResponseMessageIdentifier[0..1] : MessageQualifier 0..1 -Description : ErrorDescription
ErrorCondition[0..1] : ErrorCondition deliveries 1 0..* TM-Mdl::Route
0..* 0..*
ValidUntil[0..1] : dateTime 0..1
«group»Siri Mdl::JourneyPatternInfo
EstimatedTimetableDelivery
JourneyPatternRef[0..1] : JourneyPatternCode pattern
TM-Mdl::TimetableVersion Siri Rqs::AbstractItem version[1] : versionString VehicleMode[0..1] : Mode
Extensions[0..1] : any 0..*
-RecordedAtTime : dateTime RouteRef[0..1] : RouteCode
0..1 PublishedLineName[0..1] : populatedString
1 1 DirectionName[0..1] : populatedString
0..* delivery 0..1 ExternalLineRef[0..1] : LineCode 0..1
ET-Mdl::EstimatedJourneyVersionFrame
1
VersionRef[0..1] : TimetableVersionCode TM-Mdl::JourneyPattern
Extensions[0..1] : any pattern info «group»Siri Mdl::ServiceInfo
1 0..* OperatorRef[0..1] : OperatorCode operator
0..* 1 ProductCategoryRef[0..1] : ProductCategoryCode 1
0..1
TM-Mdl::Line TM-Mdl::Direction 1 ServiceFeatureRef[0..*] : ServiceFeatureCode 0..*
0..* 0..* VehicleFeatureRef[0..*] : VehicleFeatureCode
0..1 0..1 TM-Mdl::Operator
1 service
ET-Mdl::EstimatedVehicleJourney
LineRef[1] : LineCode 0..*
0..1 «group»Siri Mdl::OperationalInfo
block
DirectionRef[1] : DirectionCode BlockRef[0..1] : BlockCode
DatedVehicleJourneyRef[0..1] : DatedVehicleJourneyCode TM-Mdl::Block CourseOfJourneyRef[0..1] : CourseOfJourneyCode
DatedVehicleJourneyIndirectRef[0..1] : DatedVehicleJourneyIndirectRef VehicleRef[0..1] : VehicleCode
EstimatedVehicleJourneyCode[0..1] : EstimatedVehicleJourney operational info stops
0..* ExtraJourney[0..1] : boolean 1
0..1 0..* 0..*
Cancellation[0..1] : boolean run
0..1 vehicle
JourneyPatternInfo[0..1] : JourneyPatternInfo TM-Mdl::CourseOfJourney
ServiceInfo[0..1] : ServiceInfo
VehicleJourneyName[0..1] : populatedString «group»
JourneyNote[0..1] : populatedString 1 Siri Mdl::DatedVehicleJourneyIndirectRef 0..1
HeadwayService[0..1] : boolean OriginRef[1] : StopPointCode
DisruptionInfo[0..1] : DisruptionInfo 0..*
AimedDepartureTime[1] : dateTime TM-Mdl::Vehicle
Monitored[0..1] : boolean from
0..1 DestinationRef[1] : StopPointCode
PredictionInaccurate[0..1] : boolean AimedArrivalTime[1] : dateTime
Occupancy[0..1] : OccupancyEnum 1
OperationalInfo[0..1] : OperationalInfo 1 1 0..*
«group»
EstimatedCalls[2..*] : EstimatedCall TM-Mdl::StopPointInSequence 2..*
IsCompleteStopSequence[0..1] : boolean TM-Mdl::StopPoint
StopPointRef[1] : StopPointCode
Extensions[0..1] : any stop VisitNumber[0..1] : VisitNumber
0..1 0..* Order[0..1] : positiveInteger
1 1 StopPointName[0..1] : populatedString
1
«group»Siri Mdl::DisruptionInfo calls ET-Mdl::EstimatedCall
«group»Siri Mdl::CallInfo
SituationRef[0..1] : SituationReference StopPointInSequence[0..1] : StopPointInSequence
FacilityChange[0..1] : FacilityChange ExtraCall[0..1] : boolean TimingPoint[0..1] : boolean
reference Cancellation[0..1] : boolean BoardingStretch[0..1] : boolean
0..* CallInfo[0..1] : CallInfo 1 0..1 RequestStop[0..1] : boolean
1 0..1 1 DestinationDisplay[0..1] : populatedString DestinationDisplay[0..1] : populatedString
«group»
SX-Mdl::SituationReference CallNote[0..1] : populatedString
FacilityChange[0..1] : FacilityChange «group»Siri Mdl::HeadwayInfo
arrival times 1
0..1 AimedArrivalTimes[0..1] : ArrivalTimes AimedHeadWayInterval[0..1] : positiveDuration
1
«group» ArrivalInfo[0..1] : ArrivalInfo ExpectedHeadwayInterval[0..1] : positiveDuration
0..1
Siri Mdl::AimedArrivalTimes AimedDepartureTimes[0..1] : DatedVehicleJourneyIndirectRef
-AimedArrivalTime : dateTime DepartureInfo[0..1] : DepartureInfo «group»
1
-ExpectedArrivalTime : dateTime HeadwayInterval[0..1] : HeadwayInfo Siri Mdl::AimedDepartureTimes
Extensions[0..1] : any AimedDepartureTime[0..1] : dateTime
«enumeration» 0..1 0..1 ExpectedDepartureTime[0..1] : dateTime
Siri Enm::TimeStatusEnum 1
early «group»Siri Mdl::ArrivalInfo departure info
onTime «group»Siri Mdl::DepartureInfo
ArrivalStatus[0..1] : TimeStatusEnum
delayed ArrivalPlatformName[0..1] : populatedString DepartureStatus[0..1] : TimeStatusEnum
0..1
arrived ArrivalBoardingActivity[0..1] : ArrivalActivityEnum DeparturePlatformName[0..1] : populatedString
cancelled DepartureBoardingActivity[0..1] : DepartureActivityEnum
noReport
Figure 8-4 EstimatedTimetableDelivery - Detail

9. SIRI STOP TIM ETABLE (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.
Destination.
requestor Siri Rqs::SubscriptionRequest context

Siri Rqs::SubscriptionContext
0..* 1 0..1
1 MessageIdentifer[0..1] : MessageQualifier
ConsumerAddress[0..1] : EndPointAddress
SubscriptionFilterIdentifier[0..1] : nmtoken
Siri Mdl::Participant SubscriptionContext[0..1] : SubscriptionContext 1
subscriber
0..*
1 1
requests
Siri Rqs::AbstractFunctionalSubscriptionRequest
requestor
InitialTerminationTime[1] : dateTime
0..*
0..*
StopTimetableSubscriptionRequest
Siri Rqs::ServiceRequest
StopTimetableRequest[1] : StopTimetableRequest
RequestContext[1] : RequestContext StopTimetableSubscriptionPolicies[0..1] : StopTimetableSubscriptionPolicies
RequestTimestamp[1] : dateTime Extensions[0..1] : any 1 policies
Address[1] : EndPointAddress
RequestorRef[1] : ParticipantCode requests
MessageIdentifer[1] : string request1
1 Siri Rqs::AbstractFunctionalServiceRequest
context
1 MessageIdentifier[0..1] : MessageQualifier
1..1 0..1
0..* 1
Siri Rqs::RequestContext
StopTimetableSubscriptionPolicies
StopTimetableRequest
StopTimetableTopics[0..1] : StopTimetableTopics policies
StopTimetablePolicies[0..1] : StopTimetablePolicies
topics 1
0..1 0..1
1
StopTimetableTopics StopTimetablePolicies
MonitoringWindow[0..1] : HalfOpenTimestampRange Language[0..1] : lang
0..* MonitoringRef[0..1] : MonitoringCode
monitor direction
LineRef[0..1] : LineCode
0..*
SIRI-ST
0..*
StopTimetableSubscription
0..1 0..1
line & StopTimetableRequest
directions © 2007 SIRI
Siri Mdl::Monitor TM-Mdl::Line TM-Mdl::Direction
0..1 1 0..*
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
ProducerResponse SIRI-ST Summary

StopTimetableDelivery
© 2006 SIRI
errors
ServiceDelivery
ErrorCondition
1 0..1
1
deliveries
cancellations TimetabledStopVisitCancellation
StopTimetableDelivery MonitoringRef[1]
0..* 1 0..* VisitNumber[0..1]
cancels VehicleJourneyIdentity[1]
1 1
JourneyPatternInfo[0..1]
visits
1 Extensions[0..1]
0..1 frame
TimetabledStopVisit
DataFrame 0..* for
MonitoringRef[1] 1 0..*
TargetedVehicleJourney[1]
* «group»
Extensions[1] journey
journey FramedVehicleJourneyRef
DataFrameRef[1] 1 1 monitoring point
«enumeration» 1 DatedVehicleJourneyRef[1] 0..1
VehicleModesEnum
identity «group»
air 1
bus VehicleJourneyIdentity
Route line 1 LineRef[1]
coach
ferry DirectionRef[1]
0..1 1 1 FramedVehicleJourneyRef[0..1]
metro 0..1
rail
tram 0..1
TargetedVehicleJourney Monitor
underground
route VehicleJourneyIdentity[1]
1 Line 0..1
JourneyPatternInfo[0..*]
JourneyPattern VehicleJourneyInfo[0..1] monitor
MonitoringRef[0..1] «group»
pattern0..1 Extensions[0..1] 0..* VehicleJourneyInfo
destination0..* ServiceInfo[0..1]
0..*
1 OriginRef[0..1]
0..1 DestinationName[0..1]
calls
«group» OriginShortName[0..1]
JourneyPatternInfo StopPoint Via[0..*]
JourneyPatternRef[0..1] DestinationRef[0..1]
VehicleMode[0..1] 0..* 1
DestinationName[0..1]
stops 0..* 0..1 0..1
RouteRef[0..1] 0..* DestinationShortName[0..1]
at origin
PublishedLineName[0..1] stop VehicleJourneyNote[0..1]
DirectionName[0..1] TargetedCall JourneyNote[0..1]
ExternalLineRef[0..1] HeadwayService[0..1]
StopPointRef[0..1]
OriginAimedDepartureTime[0..1]
VisitNumber[1]
0..* mode Order[0..1] 0..*
DestinationAimedDepartureTime[0..1]
Mode
TimingPoint[0..1]
0..1 ServiceInfo[0..1] info
1
AimedArrivalInfo[0..1] service info
AimedDepartureInfo[0..1] operator
«group» AimedHeadwayInterval[0..1] 0..1 0..*
1 0..1
StopPointInSequence Extensions[0..1] Operator
2..* StopPointRef[1] 0..1
«group» feature
VisitNumber[0..1] arrival1 info
1 ServiceInfo
Order[0..1] 0..1
StopPointName[0..1] OperatorRef[0..1] 0..*
0..* ProductCategoryRef[0..1]
0..1 departure info ServiceFeatureRef[0..*] ServiceFeature
VehicleFeatureRef[0..*]
«group»
AimedArrivalInfo 0..* 0..* feature
AimedArrivalTime[0..1] VehicleFeature
ArrivalPlatformName[0..1] 0..1
ArrivalBoardingActivity[0..1] category
0..1 ProductCategory
«enumeration» 0..1
ArrivalActivityEnum «group» «enumeration»
alighting AimedDepartureInfo DepartureActivityEnum
noAlighting AimedDepartureTime[0..1] boarding
passThru DeparturePlatformName[0..1] noBoarding
DepartureBoardingActivity[0..1] passThru
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 CONNECTIONTIM ETABLE (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.
Destination.
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.
0..* producer 1
ProducerResponse Participant SIRI-CT Summary
ConnectionTimetableDelivery
errors © 2006 SIRI
deliveries
1 0..1
1 0..*
arrivals 1 cancellations
ConnectionTimetableDelivery
1 0..*
stops «group»
StopPointInSequence TimetabledFeederArrivalCancellation
0..1 visit 1
0..*
StopPointRef[1] InterchangeRef[0..1]
2..*
visit VisitNumber[0..1] ConnectionLinkRef[1]
TimetabledFeederArrival Order[0..1] StopPointInSequence[0..1]
StopPointName[0..1] LineRef[1]
InterchangeRef[0..1] 0..1
interchange DirectionRef[1]
ConnectionLinkRef[1] 1 at
Interchange VehicleJourneyRef[1]
StopPointInSequence[0..1] 0..*
feeder JourneyPatternInfo[0..1]
FeederJourney[1] 0..* 0..1 Reason[0..1]
AimedArrivalTime[1]
Extensions[0..1]
Extensions[0..1] 1
link
0..1
0..* 0..1 frame 0..*
to stop 1 0..1
DataFrame 0..*
ConnectionLink 0..1 origin
«group» StopPoint
journey
FramedVehicleJourneyRef
journey
DataFrameRef[1] 0..1
destination 0..* 0..*
10..* DatedVehicleJourneyRef[1]
1
1 1 «group»
DatedVehicleJourney
0..* VehicleJourneyInfo
ServiceInfo[0..1]
0..* directions
0..1
JourneyPattern 1 direction InterchangeJourney OriginRef[0..1]
pattern Direction 0..*
1 DestinationName[0..1]
LineRef[1]
OriginShortName[0..1]
0..1 DirectionRef[1]
0..* Via[0..*]
directions 0..* FramedVehicleJourneyRef[0..1]
DestinationRef[0..1]
1 JourneyPatternInfo[0..1]
pattern 0..1 line DestinationName[0..1]
VehicleJourneyInfo[0..1]
DestinationShortName[0..1]
Line 1 DisruptionInfo[0..1] journey info VehicleJourneyNote[0..1]
0..* 0..1 Monitored[0..1]
JourneyNote[0..1]
AimedDepartureTime[0..1]
0..1 HeadwayService[0..1]
OperationalInfo[0..1] 1
«group» 0..1 pattern OriginAimedDepartureTime[0..1]
Extensions[0..1]
JourneyPatternInfo DestinationAimedDepartureTime[0..1]
JourneyPatternRef[0..1] info
0..1
VehicleMode[0..1] 1 1 1
Operator
RouteRef[0..1] operational info operator
PublishedLineName[0..1] 0..1
DirectionName[0..1] «group» 0..1 disruption
ExternalLineRef[0..1] DisruptionInfo 0..*
«group»
SituationRef[0..1]
0..1 ServiceInfo
FacilityChange[0..1]
0..*
mode 0..* route OperatorRef[0..1]
0..*
«group» ProductCategoryRef[0..1]
0..*situation
OperationalInfo feature ServiceFeatureRef[0..*]
BlockRef[0..1] VehicleFeatureRef[0..*]
0..1 feature
0..1 0..1 CourseOfJourneyRef[0..1]
VehicleRef[0..1] 0..* 0..*
Situation block 0..1
Mode Route category
0..* 0..* 0..* 0..1
run ServiceFeature
0..1 vehicle
VehicleFeature
Block
0..1 0..1
Vehicle
CourseOfJourney 0..1 ProductCategory
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 CONNECTIONM ONITORING (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.
Destination.
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::ProducerResponse
0..1
SIRI-CM producer -ResponseTimeStamp : dateTime
Siri Mdl::Participant -ProducerRef : ParticipantCode
ConnectionMonitoringDelivery -Address : EndPointAddress
© 2007 SIRI 1 0..* -ResponseMessageIdentifier : MessageQualifier
subscriber -RequestMessageRef : MessageQualifier
Siri Rqs::ServiceDelivery
1 Status[0..1] : boolean
SubscriberRef[0..1] : ParticipantCode 0..1
errors ErrorCondition[0..1] : ErrorCondition
SubscriptionFilterRef[0..1] : SubscriptionFilterCode Siri Rqs::ErrorCondition MoreData[1] : boolean
SubscriptionRef[0..1] : SubscriptionCode deliveries
Error[1] : AbstractError
Description[1] : ErrorDescription 1 1
0..* deliveries
0..*
ConnectionMonitoringFeederDelivery ConnectionMonitoringDistributorDelivery
ShortestPossibleCycle[0..1] : positiveDuration 1
version[1] : versionString version[1] : versionString
Extensions[1] : BaseSituation 1
Extensions[1] : any 1
1
1
Siri Rqs::AbstractIdentifiedItem Siri Rqs::AbstractReferencedItem

arrvals
IdentifiedItemCode[0..1] : IdentifiedItemCode IdentifiedItemRef[0..1] : IdentifiedItemCode
cancellations
0..*
0..*
MonitoredFeederArrivalCancellation
CM-Mdl::MonitoredFeederArrival
InterchangeRef[0..1] : InterchangeCode
InterchangeRef[0..1] : InterchangeCode ConnectionLinkRef[1] : ConnectionLinkCode
0..1
ConnectionLinkRef[1] : ConnectionLinkCode 0..1 StopPointInSequence[0..1] : StopPointInSequence 1
StopPointInSequence[0..1] : StopPointInSequence 11 TM-Mdl::Interchange LineRef[1] : LineCode
ClearDownRef[0..1] : CleardownCode DirectionRef[1] : DirectionCode
FeederJourney[1] : InterchangeJourney VehicleJourneyRef[1] : VehicleJourneyCode
1 link 0..1
VehicleAtStop[1] : boolean JourneyPatternInfo[0..1] : JourneyPatternInfo
NumberOfTransferPassengers[0..1] : integer Reason[0..1] : populatedString
ExpectedArrivalTime[1] : dateTime Extensions[0..1] : any 0..1
0..*TM-Mdl::ConnectionLink
1
1 at to stop «group»Siri Mdl::JourneyPatternInfo
0..10..* TM-Mdl::Route
1
TM-Mdl::StopPoint JourneyPatternRef[0..1] : JourneyPatternCode
«group» route 0..* VehicleMode[0..1] : Mode
0..1
TM-Mdl::StopPointInSequence 0..1 0..* RouteRef[0..1] : RouteCode
StopPointRef[1] : StopPointCode PublishedLineName[0..1] : populatedString
VisitNumber[0..1] : VisitNumber DirectionName[0..1] : populatedString
Order[0..1] : positiveInteger 0..* CM-Mdl::AbstractDistributorItem ExternalLineRef[0..1] : LineCode
feeder StopPointName[0..1] : populatedString InterchangeRef[0..1] : InterchangeCode
distributor 1 ConnectionLinkRef[1] : ConnectionLinkCode 0..*mode 0..*
StopPointRef[0..1] : StopPointCode 0..1
0..1 pattern
0..1 0..1 feeder DistributorVisitNumber[0..1] : VisitNumber TM-Mdl::Mode
0..* DistributorOrder[0..1] : positiveInteger
DistributorJourney[1] : InterchangeJourney 0..1
«group» FeederVehicleJourneyRef[0..1] : FramedVehicleJourneyRef
Siri Mdl::FramedVehicleJourneyRef Extensions[0..1] : any TM-Mdl::JourneyPattern
journey distributor
0..* 1 pattern
1 1
Siri Mdl::InterchangeJourney 0..*

CM-Mdl::WaitProlongedDeparture
LineRef[1] : NetworkCode
DirectionRef[1] : DirectionCode ExpectedDepartureTime[0..1] : dateTime
FramedVehicleJourneyRef[0..1] : FramedVehicleJourneyRef Extensions[0..1] : any
1 1
JourneyPatternInfo[0..1] : JourneyPatternInfo
VehicleJourneyInfo[0..1] : VehicleJourneyInfo CM-Mdl::StoppingPositionChangedDeparture 0..*
DisruptionInfo[0..1] : DisruptionInfo
ChangeNote[0..1] : populatedString
Monitored[0..1] : boolean
NewLocation[0..1] : Location
AimedDepartureTime[0..1] : dateTime
OperationalInfo[0..1] : OperationalInfo
Extensions[0..1] : any 0..*
DistributorDepartureCancellation
direction
0..* 0..* Reason[0..1] : populatedString
See ConnectionTimetable
0..1 line Extensions[0..1] : any
Service for details
TM-Mdl::Line TM-Mdl::Direction
0..1
Figure 11-4 ConnectionMonitoringDelivery - Detail

12. SIRI GENERALM ESSAGE (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.
Siri Rqs::AbstractProducerResponse
SIRI-GM ResponseTimeStamp[1] : dateTime
GeneralMessageDelivery ProducerRef[0..1] : ParticipantCode
© 2007 SIRI Address[0..1] : EndPointAddress
1 producer
0..*
Siri Mdl::Participant Siri Rqs::ServiceDelivery

subscriber
0..1 ErrorCondition[0..1] : ErrorCondition
0..* MoreData[1] : boolean
0..1
Siri Rqs::AbstractFunctionalServiceDelivery 1
1
ResponseTimeStamp[1] : dateTime SIRI Requests::ErrorCondition
RequestMessageRef[0..1] : MessageQualifier -Error[1] : AbstractError
SubscriberRef[0..1] : ParticipantCode -Description[1] : ErrorDescription
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
SubscriptionRef[0..1] : SubscriptionCode
0..1
ResponseMessageIdentifier[0..1] : MessageQualifier 1
0..* deliveries
GeneralMessageDelivery
1
version[1] : versionString
Siri Rqs::AbstractItem Extensions[0..1]
-RecordedAtTime[1] : dateTime 1
Siri Rqs::AbstractIdentifiedItem
IdentifiedItemRef[0..1] : IdentifiedItemCode 0..1
0..1
«group»
SX-Mdl::SituationReference
GeneralMessage GeneralMessageCancellation
0..1 InfoMessageIdentifier[1] : InfoMessageIdentifier
situation InfoMessageIdentifier[1] : InfoMessageIdentifier
InfoMessageVersion[0..1] : InfoMessageVersion InfoMessageVersion[0..1] : InfoMessageVersion
InfoChannelRef[0..1] : InfoChannelCode InfoChannelRef[0..1] : InfoChannelCode
1 ValidUntilTime[0..1] : dateTime cancels
ValidUntilTime[0..1] : dateTime
SituationRef[0..1] : SituationCode SituationRef[0..1] : SituationCode
0..* Content[1] : Content 1 Extensions[0..1]
0..1
info channel
1
1 «datatype» «datatype»
GM-Mdl::InfoMessageIdentifier GM-Mdl::InfoChannelCode
Content
GM-Mdl::InfoChannel
format[0..1] : nmtoken
0..1 «datatype»
value[0..1] : string
GM-Mdl::InfoMessageVersion
Figure 12-4 GeneralMessageDelivery - Detail

13. SIRI FACILITYM ONITORING (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 Summary
participant
Participant subscriptions SituationExchangeSubscription
SubscriptionRequest
participant 1 0..*
& SituationExchangeRequest
1 1 © 2007 SIRI
0..*
0..*
policies
SituationExchangeSubscriptionRequest *
ServiceRequest requests request
1
1 SituationExchangeSubscriptionPolicies
1
IncrementalUpdates[0..1]
1
* policies
SituationExchangePolicies
SituationExchangeRequest
topics 0..1 Language[0..1]
1 MaximumNumberOfSituations[0..1]
0..1
1 «enumeration»
VehicleModesEnum
«enumeration»
PredictabilityEnum SituationExchangeTopics air
PreviewInterval[1] bus
planned
StartTime[0..1] «enumeration» coach
unplanned
VehicleMode[0..1] AccessModesEnum ferry
«enumeration» both
AffectedSubMode[0..1] metro
TpegSeverityEnum foot
AccessMode[1] rail
unknown bicycle
Severity[0..1] tram
verySlight car
Predictability[0..1] underground
slight taxi
filter 1 Keywords[0..*] shuttle filter
normal
SituationNetworkFilter[0..1]
severe
SituationStopPlaceFilter[0..1]
verySevere 1
SituationJourneyFilter[0..1]
noImpact
AccessibilityNeedFilter[0..1]
undefined places filter 0..*
1 1
0..1 0..1
0..1 AccessibilityNeedsFilter
Network
UserNeed[0..1]
SituationStopPlaceFilter
SituationJourneyFilter
0..1 0..*
network SituationNetworkFilter StopPlaceRef[0..1]
VehicleJourneyRef[0..1] vehicle 0..1
FacilityRef[0..1] user need
OperatorRef[0..1] InterchangeRef[0..1]
OperationalUnitRef[0..1] VehicleRef[0..1] 0..*
NetworkRef[0..1] 0..*
stop place journey
connection
unit 1 LineRef[0..1] 0..* 0..* interchange 0..1 0..*
operator StopPointRef[0..1] 1
0..* ConnectionLinkRef[0..1] 0..*
UserNeed
StopPlace0..1 0..1 Vehicle
0..1 0..*0..* stop point 0..1
line Interchange
Operator ConnectionLink VehicleJourney
0..1 0..1
1
OperationalUnit Line StopPoint
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.
context
Siri Mdl::Participant requestor Siri Rqs::SubscriptionRequest Siri Rqs::SubscriptionContext
requestor RequestTimestamp[1] : dateTime 0..1
1
1
0..*
1
SIRI-SX
0..1 MessageIdentifer[0..1] : MessageQualifier
SituationExchangeSubscription
ConsumerAddress[0..1] : EndPointAddress & SituationExchangeRequest
Siri Rqs::ServiceRequest SubscriptionFilterIdentifier[0..1] : nmtoken © 2007 SIRI
RequestContext[1] : RequestContext subscriptions
context 0..*
Address[1] : EndPointAddress
RequestorRef[1] : ParticipantCode 1
MessageIdentifer[1] : string SituationExchangeSubscriptionRequest policies
0..1 SituationExchangeRequest[1] : SituationExchangeRequest
requests
1 1
SituationExchangeSubscriptionPolicies[0..1] : SituationExchangeSubscriptionPolicies
Extensions[0..1] : any *
* Siri Rqs::RequestContext
1 request 1 SituationExchangeSubscriptionPolicies
SituationExchangeRequest
IncrementalUpdates[0..1] : boolean
SituationExchangeTopics[0..1] : SituationExchangeTopics
SituationExchangePolicies[0..1] : SituationExchangePolicies policies
SituationExchangePolicies
* Language[0..1] : lang
1 MaximumNumberOfSituations[0..1] : integer
«enumeration» topic unit
TM-Mdl::OperationalUnit
SX-Enm::PredictabilityEnum
0..* 1
planned 1
TM-Mdl::Operator TM-Mdl::Network
unplanned
both operator SituationNetworkFilter 0..* network
0..1
1 OperatorRef[0..1] : OperatorCode 0..* 1
0..* OperationalUnitRef[0..1] : OperationalUnitCode
SituationExchangeTopics NetworkRef[0..1] : NetworkCode 0..* stop TM-Mdl::Line
PreviewInterval[1] : duration LineRef[0..1] : LineCode
StartTime[0..1] : dateTime StopPointRef[0..1] : StopPointCode
VehicleMode[0..1] : VehicleModesEnum 0..1 ConnectionLinkRef[0..1] : ConnectionLinkCode 1
AffectedSubMode[0..1] : AccessModesEnum 1
filter 0..1 TM-Mdl::StopPoint
AccessMode[1] : AccessModesEnum
Severity[0..1] : TpegSeverityEnum to stop
0..*
connection 1
Predictability[0..1] : boolean 1
Keywords[0..*] : string SituationStopPlaceFilter
0..*
SituationNetworkFilter[0..1] : SituationNetworkFilter StopPlaceRef[0..1] : StopPlaceCode 1
SituationStopPlaceFilter[0..1] : SituationStopPlaceFilter FacilityRef[0..1] : FacilityCode
SituationJourneyFilter[0..1] : SituationJourneyFilter 1 TM-Mdl::ConnectionLink
AccessibilityNeedFilter[0..1] : AccessibilityNeedsFilter stop place 1
0..*
filter iFOPT-Mdl::StopPlace
«enumeration» 1
TpegSeverityEnum SituationJourneyFilter 0..* journey
unknown VehicleJourneyRef[0..1] : VehicleJourneyCode
verySlight filter 0..1
InterchangeRef[0..1] : InterchangeCode
slight VehicleRef[0..1] : VehicleCode 1
normal 0..*
severe
0..* 0..* TM-Mdl::VehicleJourney
verySevere AccessibilityNeedsFilter
noImpact interchange
undefined «enumeration» needs 1 vehicle 1
Siri Enm::VehicleModesEnum1
air TM-Mdl::Interchange TM-Mdl::Vehicle
«enumeration» bus
Siri Enm::AccessModesEnum coach *
foot ferry
bicycle metro
car rail ACSB-Mdl::UserNeed
taxi tram
shuttle underground
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 SIRI-SX Summary PT

errors SituationExchangeDelivery
© 2006 SIRI
1 0..1 «enumeration»
deliveries RelatedEnum
1
RelatedSituation cause
context SituationContext
0..* effect
CreationTime[1]
«group» corrects
0..1 related to SituationRef[1] identifier
SituationReference supercedes
SituationExchangeDelivery RelatedAs[1]
CountryRef[0..1] supercededBy
Extensions[0..1]
1 0..* 1 1 ParticipantRef[0..1] association
1
1
1 reference to 0..*
situations AbstractSituationElement «group»
ExternalReference
CreationTime[1] SituationElementReference
CountryRef[0..1] SituationNumber[1] Reference[1]
ParticipantRef[1] UpdateCountryRef[0..1]
SituationNumber[1] body UpdateParticipantRef[0..1]
*
RelatedTo[0..*] SituationVersion[0..1]
SituationBody SituationSource
VersionedAtTime[0..1]
SituationBody[1] 1
made by 1 Country[0..1]
1
SourceType[1]
SourceMethod[0..1]
0..* Email[0..1]
Participant 0..1
Phone[0..1]
UpdateSituationElement updated
*0..* by Fax[0..1]
BaseSituationElement updates Web[0..1]
SituationVersion[0..1]
Other[0..1]
UpdateParticipantCountry[0..1] «group»
1 0..* AgentReference[0..1]
when UpdateParticipantRef[0..1] 1 PtSituationBody
sourceTimeOfObservation[1]
SituationSource[1] TimeOfCommunication[1]
SituationStatus[1] ExternalCode[0..1]
classifiers 1
Reason TemporalGroup[1] Extensions[0..1]
ClassifierGroup[1]
reason 1 0..* 1 DescriptionGroup[0..1] 1
* 1 description
1 Affects[0..1]
Consequences[0..*] Consequence
«group» PublishingActions[0..1] 1
«group» consequence Period[0..1]
«group» ClassifierGroup Extensions[0..1]
DescriptionGroup Condition[0..1]
TemporalGroup Reason[1] Severiity[1]
ReasonName[0..1] Summary[0..1] 0..*
ValidityPeriod[1]
Description[0..1]
1 11status Affects[0..1]
Repetitions[0..*] PublicEvent[0..1] «group» Suitabilities[0..*]
PublicationWindow[1] Severity[1] Detail[0..1] SituationStatus Advice[1]
actions
Priority[0..1] Advice[0..1] Verification[1] Blocking[0..1]
Sensitivity[0..1] Internal[0..1] 1
1 Progress[1] Boarding[0..1]
Audience[0..1] Images[0..*] affects Quality[0..1] Delays[0..1]
applies InfoLink[0..*] 0..1
ReportType[0..1] Reality[0..1] Casualties[0..1]
ScopeType[0..*] Likelihood[0..1] Easements[0..*]
Planned[0..1] PublishingActions Extensions[0..1]
0..1 Keywords[0..*] affects
0..* 1 0..*
ValidityPeriod network journeys journey
StartTime[1] Network AffectedNetwork 0..1
0..1 AffectedVehicleJourney
EndTime[1] 1 0..* networks 1 1
1 0..*
operators 1 roads
0..* AffectsScope
DatedVehicleJourney
0..* 1
operator 1 locations
AffectedOperator 1 0..1
1 1 AffectedRoads
0..1 0..* 0..* lines places 0..1 1 GroupOfLocations
line AffectedLine
Operator routes place
stops places
AffectedPlace
1 0..* 0..1
0..1 0..* 0..* 0..* 0..*
Line 0..* stop
AffectedScheduledStop 0..* Place
AffectedStopPlace
routes AffectedRoute
0..1
0..* 0..1 stop place 0..* stop place
Route StopPoint StopPlace StopPlaceComponent
1 0..1
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.
SIRI PT Situation Body SituationSource

© 2006 SIRI AbstractSituationElement
«enumeration» Country[0..1] : CountryEnum
«enumeration» SituationProgressEnum SourceType[1] : SourceEnum
«enumeration»
VerificationEnum 1 SourceMethod[0..1] : SourceMethodEnum
draft ProbabilityOfOccurenceEnum
unknown Email[0..1] : email
draftPendingApproval certain body Phone[0..1] : phoneNumber
unverified approvedDraft probable
verified Fax[0..1] : phoneNumber
open riskOf Web[0..1] : anyURI
verifiedAsDuplicate closing improbable 0..1
source Other[0..1] : string
closed 0..* AgentReference[0..1] : string
TimeOfObservation[1] : dateTime
TimeOfCommunication[1] : dateTime
«group»PtSituationBody
11
status ExternalCode[0..1] : string
«group»SituationStatus SituationSource[1] : SituationSource Extensions[0..1] : any
Verification[1] : VerificationEnum SituationStatus[1] : SituationStatus
Progress[1] : SituationProgressEnum TemporalGroup[1] : TemporalGroup 1
Quality[0..1] : QualityIndexEnum ClassifierGroup[1] : ClassifierGroup actions «enumeration»
Reality[0..1] : InformationStatusEnum DescriptionGroup[0..1] : DescriptionGroup SourceEnum
1 1 PublishingActions
Likelihood[0..1] : ProbabilityOfOccurenceEnum Affects[0..1] : AffectsScope email
0..1
Consequences[0..*] : Consequence consequence phone
PublishingActions[0..1] : PublishingActions 1 fax
Consequence
Extensions[0..1] : any post
«enumeration» «enumeration» 0..*
1 feed
InformationStatusEnum QualityIndexEnum 0..1 0..1 affects radio
1 1 1
affects
real certain classifiers AffectsScope tv
securityExercise veryReliable when web
technicalExercise reliable pager
test unreliable text
unconfirmed description «group»DescriptionGroup other
1
Summary[0..1] : DefaultedText
* 0..1
Description[0..1] : DefaultedText
«group»TemporalGroup «group»ClassifierGroup 1
Detail[0..1] : DefaultedText
ValidityPeriod[1] : ValidityPeriod Reason[1] : Reason Advice[0..1] : DefaultedText
Repetitions[0..*] : DayType ReasonName[0..1] : nlString image
Internal[0..1] : DefaultedText
PublicationWindow[1] : ValidityPeriod PublicEvent[0..1] : PublicEventTypeEnum Images[0..*] : Image
0..* Severity[1] : TpegSeverityEnum InfoLink[0..*] : InfoLink
days
1 1 Priority[0..1] : integer
applies Sensitivity[0..1] : SensitivityEnum image
1 1
Audience[0..1] : AudienceEnum
DayType 0..1
ReportType[0..1] : TpegReportEnum 0..1
0..* reason image 1
0..1 ScopeType[0..*] : ScopeTypeEnum InfoLink
Planned[0..1] : boolean Image
Keywords[0..*] : string
ValidityPeriod
«enumeration»
StartTime[1] : dateTime Tpeg-Mdl::TpegSeverityEnum
EndTime[1] : dateTime «enumeration» unknown
«enumeration»
1 SensitivityEnum ScopeTypeEnum verySlight
Reason slight
veryHigh general
ReasonCode[1] : ReasonEnum high operator «enumeration» normal
SubReasonCode[0..1] : SubReasonEnum medium network AudienceEnum severe
low route public verySevere
«enumeration» veryLow line staff noImpact
TpegReportEnum place emergencyServices undefined
unknown stopPlace management
network stopPlaceComponent stationStaff
route stopPoint infoServices
point vehicleJourney authorities
individualService datedVehicleJourney transportOperators
undefined connectionLink
interchange
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.
operator
Operator
0..*
0..1 operator DatedVehicleJourney
AffectedOperator
1 consequence journey
1
0..* «group»PtSituationBody Consequence
0..*
0..*
1 0..*
affects 0..*
1 1 0..*
operators affects 0..1 0..1 journeys
1 AffectedVehicleJourney
operators
1 AffectsScope roads 1
0..* 1
1 0..1 1 1 1
1
0..* networks 1 disruptions
1 stops 1 AffectedRoads
AffectedNetwork 1 place
places Place
0..* destinations
0..* 0..* 0..* 0..*
0..1 0..*
1
network mode 0..* accessibility calls
1 AffectedStopPlace AffectedPlace AccessibilityDisruption
stop place
10..*
Network 0..1 components 0..*
placesdisruptions
1 0..* journey
lines 1 TopographicPlace
StopPlace 1
AffectedStopPlaceComponent 0..* 1*
0..*
component
0..*
0..1component AffectedScheduledStop
Mode 0..* at
StopPlaceComponent 0..*
lines 0..* 1 0..1 0..*
mode 0..* 0..1
connections
0..*
AffectedCall
0..*
SIRI-SX Summary stop interchanges
1
Direction
Situation Affects AffectedConnectionLink
0..1 0..* 0..*

0..*direction
Scope 0..*
0..* link
0..1
© 2007 0..*
affected stops link
AffectedInterchange
AffectedLine
1 0..1
0..* 0..*
links 0..* 0..*
interchange
0..* 1 routes section LineSection ConnectionLink
0..* 1 0..*
directions line 0..1 to stop0..* 1
links 1
stop routes
RouteLink 0..1
0..* 0..1 Interchange
0..* StopPoint
0..*
AffectedRoute
1
routes 1
0..1 1 0..* lines
Route
Line
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
«enumeration»
DX2-DTs::AreaOfInterestEnum SIRI-SX
continentWide Situation Affects
national
neighbouringCountries Scope - Stop Place
AffectsScope notSpecified © 2007
locations
regional
AreaOfInterest[0..1] : AreaOfInterestEnum DX2-Mdl::GroupOfLocations
Operators[0..*] : AffectedNetwork 0..1 0..1
Networks[0..*] : AffectedOperator AffectedRoads
Lines[0..*] : AffectedLine
1 AffectedPlace TM-Mdl::Place
StopPlaces[0..*] : AffectedStopPlace 0..1
StopPoints[0..*] : AffectedScheduledStop 1 PlaceRef[1] : PlaceId
Places[0..*] : AffectedPlace PlaceName[0..1] : nlString 0..*
VehicleJourneys[0..*] : AffectedVehicleJourney PlaceType[0..1]
places accessibility
Roads[0..1] : AffectedRoads 1 Location[0..1] : Location
Extensions[0..1] : any AccessibilityDisruption[0..1] : AccessibilityDisruption
0..* Extensions[0..1] : any 1
1 stops
iFOPT-Mdl::StopPlace accessibility
AffectedStopPlaceElement 0..1 0..*
0..1 AccessibilityDisruption[0..1] : AccessibilityDisruption 1

stop place 0..* ACSB-Mdl::AccessibilityDisruption
MobilityImpairedAccess[1] : boolean
0..* Liimitations[0..1] : Limitation
AffectedStopPlace
Suitabilities[0..*] : Suitability
StopPlaceRef[1] : StopPlaceCode
PlaceName[0..1] : nlString 1
StopPlaceType[1] : StopPlaceTypeEnum 1
ACSB-Mdl::Suitability
Components[0..*] : AffectedStopPlaceComponent 0..* suitabilities
NavigationPaths[0..*] : ComponentId UserNeed[1] : nmtoken
Extensions[0..1] : any Suitable[1] : SuitableEnum
limitation
«enumeration»
1
components ACSB-Mdl::SuitableEnum «enumeration»
suitable ACSB-Mdl::AccessibilityEnum
«enumeration» notSuitable true
iFOPT-Mdl::StopPlaceTypeEnum 0..* unknown false
airport unknown
railStation 0..*
AffectedStopPlaceComponent
metroStation
coachStation ComponentRef[1] : ComponentId
ComponentName[0..1] : nlString ACSB-Mdl::Limitation
busStation
shipPort ComponentType[1] : ComponentTypeEnum WheelchairAccess[0..1] : AccessibilityEnum
ferryPort AccessFeatureType[0..1] StepFreeAccess[0..1] : AccessibilityEnum
ferryStop Extensions[0..1] EscalatorFreeAccess[0..1] : AccessibilityEnum
level
onStreetBus LiftFreeAccess[0..1] : AccessibilityEnum
0..* 1 AudibleSignsAvailable[0..1] : AccessibilityEnum
onStreetTram 0..*
skiLift VisualSignsAvailable[0..1] : AccessibilityEnum
other component iFOPT-Mdl::Level
«enumeration»
«enumeration» iFOPT-Mdl::ComponentTypeEnum
iFOPT-Mdl::AccessFacilityEnum quay
0..1 accessSpace
unknown
lift boardingPosition
escalator iFOPT-Mdl::StopPlaceComponent stoppingPlace
travelator stoppingPosition
ramp entrance
stairs stopPathLink
shuttle AbstractPathLink AbstractStopPlaceSpace accessPathLink
narrowEntrance other
barrier
lowFloorAccess
iFOPT-Mdl::AccessPathLink iFOPT-Mdl::AccessSpace iFOPT-Mdl::Quay iFOPT-Mdl::BoardingPosition

iFOPT-Mdl::StopPathLink
Figure 14-9 Affects Scope - Stop Place

15. SIRI COM M ON 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).
Siri Rqs::ErrorCondition Errors::AbstractError

-Error[1] : AbstractError -ErrorText[1] : string
-Description[1] : ErrorDescription 1
1 SIRI
Simple ErrorTypes
© 2006 SIRI
Errors::CapabilityNotSupportedError Errors::OtherError
CapabilityCode[1]
Errors::AccessNotAllowedError Errors::NoInfoForTopicError Errors::AllowedResourceUsageExceeded
image
SX-Mdl::DefaultedText InfoLink Image
nlString[1] : nlString Uri[1] : anyURI ImageRef[0..1]
0..1
overridden[0..1] Label[1] : nlString 1 ImageBinary[0..1]
Image[1] : Image ImageContent[0..1] : ImageContentEnum
LinkContent[1] : LinkContentEnum
«enumeration»
SIRI Siri Enm::LinkContentEnum
details
Complex Data Types «enumeration»
advice
© 2006 SIRI Siri Enm::ImageContentEnum
timetable
map
relatedSite
graphic
other
logo
Loc Mdl::Location
id[0..1] : nmtoken EquipmentAvailability
srsName[0..1] : string
EquipmentRef[0..1] : EquipmentCode
Longitude[0..1] : Longtitude
0..1 Description[0..1] : populatedString
Latitude[0..1] : Latitude
EquipmentStatus[1] : EquipmentStatus
Coordinates[0..1] : Coordinates
FacilityChange ValidityPeriod[0..1] : HalfOpenTimestampRange
Precision[0..1] : distance
EquipmentTypeRef[0..1] : EquipmentTypeCode
EquipmentAvailability[0..1]
1 EquipmentFeatures[0..*] : EquipmentFeatureCode
SituationRef[0..1] : SituationCode
HalfOpenTimestampRange MobilityDisruption[0..1]
1
StartTime[1] : dateTime
EndTime[0..1] : dateTime MobilityDisruption
0..1 MobilityImpairedAccess[0..1]
MobilityFacility[0..1] : MobilityFacility
«group»FramedVehicleJourneyRef TM-Mdl::Mode
TpegSubMode
-DataFrameRef : DataFrameCode -Mode[1]
-DatedVehicleJourneyRef : DatedVehicleJourneyCode -SubMode[0..1] : TpegSubMode
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» «datatype» SIRI

DataFrameCode TimetableVersionCode
Identifier Simple DataTypes
For Transmodel entities
«datatype» © 2006 SIRI
«datatype» «datatype»
OperationalUnitCode StopPointCode
OperatorCode
«datatype» «datatype» «datatype»

NetworkCode ConnectionLinkCode PlaceId
«datatype»
IFOPT-DTs::StopPlaceId
«datatype» «datatype» «datatype» «datatype»
LineCode RouteCode DirectionCode ZoneCode
«datatype»
«datatype»
IFOPT-DTs::ComponentId
JourneyPatternCode «datatype» «datatype» «datatype»
DatedVehicleJourneyCode VehicleJourneyCode InterchangeCode
«datatype» «datatype» «datatype» «datatype» «datatype» «datatype»

BlockCode CourseOfJourneyCode VehicleCode TrainPartCode TrainPartCode IFOPT-DTs::StopPlaceCode
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.
«enumeration»
«enumeration» «enumeration» «enumeration»
SIRI-SX SituationProgressEnum
PredictabilityEnum SensitivityEnum SourceEnum «enumeration»
draft ScopeTypeEnum
Enumerations draftPendingApproval
planned veryHigh email
© 2006 SIRI unplanned high phone general
approvedDraft operator
both medium fax
open network
low post
«enumeration» closing route
veryLow feed
QualityIndexEnum closed «enumeration» line
«enumeration» radio
certain AudienceEnum tv place
RelatedEnum
veryReliable «enumeration» public web stopPlace
reliable staff cause pager stopPlaceComponent
ElementStatusEnum
unreliable emergencyServices effect text stopPoint
editable corrects
unconfirmed management other vehicleJourney
versioned supercedes
stationStaff datedVehicleJourney
released supercededBy
infoServices connectionLink
«enumeration» authorities association interchange
ConnectionDirectionEnum «enumeration» transportOperators
both VerificationEnum
«enumeration» «enumeration»
from unknown SX-Enm-DTX::SourceMethodEnum DX2-DTs::PublicEventTypeEnum
to unverified
verified athleticsMeeting
verifiedAsDuplicate ballGame
baseballGame
basketballGame
«enumeration» «enumeration» bycycleRace
SIRI-SX / Datex2 DX2-DTs::ProbabilityOfOccurenceEnum DX2-DTs::RoadSourceMethodEnum boatRace
Enumerations certain automobileClubPatrol boxingTournament
© 2008 SIRI probable cameraObservation bullFight
riskOf freightVehicleOperator ceremonialEvent
improbable inductionLoopMonitoringStation concert
microwavedMonitoringStation cricketMatch
mobileTelephoneCaller exhibition
«enumeration» «enumeration» nonPoliceEmergencyServicesPatrol fair
DX2-DTs::DelayBandEnum DX2-DTs::AreaOfInterestEnum otherInformation festival
delayLongerThanSixHours continentWide otherOfficialVehicle filmTVMaking
delayBetweenThreeHoursAndSixHours national policePatrol footballMatch
delayBetweenOneHourAndThreeHours neighbouringCountries privateBreakdownService funfair
delayBetweenThirtyMinutesAndOneHours notSpecified publicAndPrivateUtilities golfTournament
delayLessThanThirtyMinutes regional registeredMobileObserver hockeyGame
negligble roadAuthorities horseRaceMeeting
roadOperatorPatrol internationalSportsMeeting
«enumeration» «enumeration» roadsideTelephoneCaller majorEvent
DX2-DTs::DelayTypeEnum DX2-DTs::InformationStatusEnum spotterAircraft marathon
delays real trafficMonitoringStation market
delaysOfLongDuration securityExercise transitOperator match
longDelays technicalExercise vehicleProbeMeasurement motorSportRaceMeeting
veryLongDelays test videoProcessingMonitoringStation parade
raceMeeting
rugbyMatch
severalMajorEvents
show
showJumping
sportsMeeting
stateOccassion
tennisTournament
tournament
tradeFair
waterSportsMeeting
winterSportsMeeting
other
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.
«enumeration»
«enumeration» «enumeration» «enumeration» «enumeration»
TpegServiceConditionEnum
TpegDayTypeEnum TpegSeverityEnum TpegReportEnum TpegTicketRestrictionEnum
unknown
unknown unknown unknown unknown
altered
monday verySlight network allTicketClassesValid
cancelled
tuesday slight route fullFareOnly
delayed
wednesday normal point certainTicketsOnly
diverted
thursday severe individualService ticketWithReservation
noService
friday verySevere undefined specialFare
disrupted
saturday noImpact onlyTicketsOfSpecifiedOperator
additionalService
sunday undefined noRestrictions
specialService
mondayToFriday onTime noOffPeakTickets
mondayToSaturday normalService noWeekendReturnTickets
weekends intermittentService noReducedFareTickets
publicHoliday shortFormedService unknwonTicketRestriction
holiday fullLengthService
regionalHoliday extendedService tpeg pti_27
Tpeg pti-26
nationalHoliday splitingTrain
sundaysAndPublicHolidays replacementTransport
schooldays arrivesEarly
everyday shuttleService tpeg pti_25
undefinedDayType replacementService
undefinedServiceInformation
TPEG «enumeration»
TpegRoutePointEnum
Miscellaneous
unknown
Enumerations startPoint
TPEG pti_34 © 2007 SIRI destination
tpeg pti_13 stop
via
notStopping
temporaryStop
tpeg pti_5
«enumeration» temporarilyNotStopping
TpegInterchangeStatusEnum exceptionalStop
tpeg pti 31 additionalStop
unknown
requestStop
connection
frontTrainDestination
replacement
rearTrainDestination
alternative
throughServiceDestination
connectionNotHeld
notVia
connectionHeld
alteredStartPoint
statusOfConnectionUndecided
alteredDestination
undefined
undefinedRoutePoint
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

Handbookv 15

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Handbookv 15

Uploaded by

Copyright:

Available Formats

.

2008/ 01/10 Njsk Kizoom

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 © Copyright 2007, 2008 Kizoom Limited:

Telephone: 207 749 2670

Company Registration Number : 3745127

© Copyright Kizoom 2006-2007 Page 2

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

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

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

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

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

© Copyright Kizoom 2006-2007 Page 3

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

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

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

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

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

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

© Copyright Kizoom 2006-2007 Page 4

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

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

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

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