SIRI-SM - Easily

.
Kizoom Limited, 109-123 Clifton Street, London EC2A 4LD. Tel: +44 207 749 2670
SIRI Handbook
& Functional Service Diagrams
Version 0.8
2007/10/12 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
Document automation & Copyright notice
Kizoom Ltd
107-109 Clifton Street,
London EC2A 4LD
©2007 Kizoom Limited:
All rights Reserved.
Telephone: 207 749 2670
Company Registration Number : 3745127
Author:
Nicholas Knowles
© Copyright Kizoom 2006-2007
Page 2
SIRI Functional Services - UML Diagrams
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 ............................................................................................... 16
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
SIRI Functional Services - UML Diagrams
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 ................................................................ 35
Examples of Live services that USe SIRI-SM ..................................................................................... 39
Map based web departure boards................................................................................................ 39
WAP mobile departure boards ..................................................................................................... 39
SMS departure boards .................................................................................................................. 39
6.
SIRI Vehicle Monitoring (VM) ........................................................................................................ 40
SIRI-VM: Subscription & Request ..................................................................................................... 40
VehicleMonitoringRequest Summary ........................................................................................... 40
VehicleMonitoringRequest Detail ................................................................................................. 41
SIRI-VM: Delivery ............................................................................................................................. 42
VehicleMonitoringDelivery Summary ........................................................................................... 42
Use of MonitoredVehicleJourney Element for SIRI-VM ................................................................ 43
VehicleMonitoringDelivery Detail ................................................................................................. 44
7.
SIRI ProductionTimetable (PT)....................................................................................................... 45
SIRI-PT: Subscription & Request ....................................................................................................... 45
ProductionTimetableRequest Summary ........................................................................................ 45
ProductionTimetableRequest Detail ............................................................................................. 46
SIRI-PT: Delivery .............................................................................................................................. 47
ProductionTimetableDelivery Summary........................................................................................ 47
ProductionTimetableDelivery Detail ............................................................................................. 48
© Copyright Kizoom 2006-2007
Page 4
SIRI Functional Services - UML Diagrams
8.
SIRI EstimatedTimetable (ET) ........................................................................................................ 49
SIRI-ET: Subscription & Request ....................................................................................................... 49
EstimatedTimetableRequest Summary ......................................................................................... 49
EstimatedTimetableRequest Detail ............................................................................................... 50
SIRI-ET: Delivery ............................................................................................................................... 50
EstimatedTimetableDelivery Summary ......................................................................................... 51
EstimatedTimetableDelivery Detail ............................................................................................... 52
9.
SIRI Stop Timetable (ST) ................................................................................................................ 53
SIRI-ST: Subscription & Request ....................................................................................................... 53
StopTimetableRequest Summary .................................................................................................. 53
StopTimetableRequest Detail ........................................................................................................ 54
SIRI-ST: Delivery ............................................................................................................................... 55
StopTimetableDelivery Summary .................................................................................................. 55
StopTimetableDelivery Detail ........................................................................................................ 56
10.
SIRI ConnectionTimetable (CT) ...................................................................................................... 57
SIRI-CT: Subscription & Request ....................................................................................................... 57
ConnectionTimetableRequest Summary ....................................................................................... 57
ConnectionTimetableRequest Detail ............................................................................................. 58
SIRI-CT: Delivery .............................................................................................................................. 59
ConnectionTimetableDelivery Summary ....................................................................................... 59
ConnectionTimetableDelivery Detail ............................................................................................. 60
11.
SIRI ConnectionMonitoring (CM) .................................................................................................. 61
SIRI-CM: Subscription & Request ..................................................................................................... 61
ConnectionMonitoringRequest Summary ..................................................................................... 61
ConnectionMonitoringRequest Detail ........................................................................................... 62
SIRI-CM: Delivery ............................................................................................................................. 62
ConnectionMonitoringDelivery Summary ..................................................................................... 63
ConnectionMonitoringDelivery Detail ........................................................................................... 64
12.
SIRI GeneralMessage (GM) ........................................................................................................... 65
© Copyright Kizoom 2006-2007
Page 5
SIRI Functional Services - UML Diagrams
SIRI-GM: Subscription & Request ..................................................................................................... 65
GeneralMessageRequest Summary .............................................................................................. 65
GeneralMessageRequest Detail .................................................................................................... 66
SIRI-GM: Delivery ............................................................................................................................. 67
GeneralMessageDelivery Summary .............................................................................................. 67
GeneralMessageDelivery Detail .................................................................................................... 68
13.
SIRI FacilityMonitoring (FM) DRAFT .............................................................................................. 69
SIRI-FM: Subscription & Request ..................................................................................................... 69
FacilityMonitoringRequest Summary ............................................................................................ 69
FacilityMonitoringRequest Detail.................................................................................................. 69
SIRI-FM: Delivery ............................................................................................................................. 69
FacilityMonitoringDelviery Summary ............................................................................................ 69
FacilityMonitoringDelviery Detail.................................................................................................. 69
14.
SIRI SituationExchange (SX) DRAFT ............................................................................................... 70
SIRI-SX: Subscription & Request ....................................................................................................... 70
SituationExchangeRequest Summary ........................................................................................... 70
SituationExchangeRequest Detail ................................................................................................. 71
SIRI-SX: Delivery .............................................................................................................................. 71
SituationExchangeDelivery Summary ........................................................................................... 72
SituationExchangeDelivery Detail ................................................................................................. 73
Situation Model ............................................................................................................................ 73
15.
SIRI Common Data Types .............................................................................................................. 79
Common SIRI Data Types – XML Simple Types ................................................................................. 79
Common SIRI Data Types ................................................................................................................. 79
Common SIRI SImPLE Data Types – Codes & Identifiers ................................................................... 80
Common General SIRI Enumerations ............................................................................................... 81
SIRI-SX Enumerations....................................................................................................................... 81
IFOPT Enumerations for SIRI-SX ....................................................................................................... 82
TPEG Miscellaneous Enumerations for SIRI-SX ................................................................................. 83
© Copyright Kizoom 2006-2007
Page 6
SIRI Functional Services - UML Diagrams
TPEG Mode Enumerations ............................................................................................................... 84
16.
Annex A Notation .......................................................................................................................... 85
Entities............................................................................................................................................. 85
Enumerations .................................................................................................................................. 85
Groups ............................................................................................................................................. 85
Notes ............................................................................................................................................... 85
Relationships ................................................................................................................................... 85
Use of Colour ................................................................................................................................... 86
Serialisation: Containment & Reference .......................................................................................... 86
Alternative Representations of XML Strcutures in UML ............................................................... 87
XML Fragment for Example ........................................................................................................... 89
Order of Attributes .......................................................................................................................... 90
Direction of Reading ........................................................................................................................ 90
Simple Data Types ........................................................................................................................... 90
Reusable Complex Data Types ......................................................................................................... 90
© Copyright Kizoom 2006-2007
Page 7
SIRI Functional Services - UML Diagrams
1. INTRODUCTION
This SIR Handbook provides a short overview of the CEN SIRI (Service Interface for Real Time
Information) technical specification and 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. However commonly required
basic real-time services, such as stop departures or timetable exchange can be understood and
implemented simply in SIRI.
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/
© Copyright Kizoom 2006-2007
Page 8
SIRI Functional Services - UML Diagrams

Transmodel
o

IFOPT
o

CEN TC 278 ENV 12896 Reference Data Model for Public Transport
CEN/TS 00278207 – Identification of Fixed Objects in Public Transport
TPEG
© Copyright Kizoom 2006-2007
Page 9
SIRI Functional Services - UML Diagrams
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
© Copyright Kizoom 2006-2007
Page 10
SIRI Functional Services - UML Diagrams
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.
© Copyright Kizoom 2006-2007
Page 11
SIRI Functional Services - UML Diagrams
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
© Copyright Kizoom 2006-2007
Page 12
SIRI Functional Services - UML Diagrams
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 multiple SIRI services, 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.

Each functional service has unique endpoints, the addresses at which the service can be
found.

Each Participant, whether consumer or producer, has a unique identifier.

Payload content is separated from message management content.

Content may be obtained either by an immediate direct request /response interaction, or by
a publish / subscribe interaction. In both cases the same set of request parameters are
supported; for a subscription the request is wrapped in an additional subscription element.

Data exchange by SIRI services may either be used as input to other computations, or be
rendered into end user information in any one of a number of media: e.g. web, WAP, SMS,
or Voice.
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
VM
SM
JP
ET
SM
ET
VM
SM&
Web
Mobile
GMS
AVMSST
SM
GMS
GMS
GMS
GMS
ICS
ICS
Alerts
5
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.
© Copyright Kizoom 2006-2007
Page 13
SIRI Functional Services - UML Diagrams
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
Content
defined
XML Schema
For payload
Exchange
Behaviour
well-defined interactions
with XML schema
Representations
parameterising behaviour
Transport
Protocol
Independent e.g.
HTTP POST,
SOAP.
4
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.
© Copyright Kizoom 2006-2007
Page 14
SIRI Functional Services - UML Diagrams

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.
Requestor
Responder
Request
Response
Request / Response
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.
Subscriber
NotificationProducer
NotificationConsumer
SubscriptionRequest (ServiceType, Subscription)
SubscriptionResponse
Subscription Manager
register
Notify / Deliver 1
TerminationRequest
Notify / Deliver 2
TerminationResponse
Notify / Deliver etc
terminate
Publish / Subscribe
Figure 3-4 Sequence Diagram of Publish Subscribe Interaction
© Copyright Kizoom 2006-2007
Page 15
SIRI Functional Services - UML Diagrams
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
TerminationResponse
Publish / Subscribe
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”>

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

© Copyright Kizoom 2006-2007
Page 16
SIRI Functional Services - UML Diagrams
<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">
<ResponseTimestamp>2004-12-17T09:30:47-05:00</ResponseTimestamp>
<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>
© Copyright Kizoom 2006-2007
Page 17
SIRI Functional Services - UML Diagrams
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>
<RequestTimestamp>2004-12-17T09:30:47-05:00</RequestTimestamp>

<StopMonitoringSubscriptionRequest>
<SubscriptionIdentifier>000235</SubscriptionIdentifier>
<InitialTerminationTime>2004-12-17T15:30:47-05:01</InitialTerminationTime>
<StopMonitoringRequest version=“1.0”>

<RequestTimestamp>2004-12-17T09:30:47-05:06</RequestTimestamp>
<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 StopMonitoringSubscriptionRequest. It is almost identical to the earlier response to a StopMonitoringRequest, but
also includes subscription identifier data.
<ServiceDelivery>

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

<StopMonitoringDelivery version="0.1d">
<ResponseTimestamp>2004-12-17T09:30:47-05:00</ResponseTimestamp>
<SubscriberRef>NADER</SubscriberRef>
<SubscriptionRef>2004-12-17T09:30:47-05:00</SubscriptionRef>
<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>
© Copyright Kizoom 2006-2007
Page 18
SIRI Functional Services - UML Diagrams
</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>
© Copyright Kizoom 2006-2007
Page 19
SIRI Functional Services - UML Diagrams
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 or data elements wherever they exist, and assumes the same
cardinalities as Transmodel for any associations between elements.

In a 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
It should be noted though, that there is some subtlety involved in expression the mapping of SIRI
content onto Transmodel. Most SIRI services are only concerned with exchanging small parts of the
information models described by Transmodel - and need to perform this exchange efficiently in realtime. The serialisation of the abstract Transmodel content model into concrete SIRI messages is
therefore selective: only those elements that are needed for each particular functional service are
included; often these will be just the changes to a previously established 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 with which it is concerned. Nor can all the associations of
Transmodel be discerned.

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 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, and
© Copyright Kizoom 2006-2007
Page 20
SIRI Functional Services - UML Diagrams
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.
1
SIRI - Summary of relevant
Transmodel entities
route
TM-Mdl::Route
1
route
service pattern
1
0..*
1
© 2007 SIRI
TM-Mdl::Line
0..1
TM-Mdl::Block
line
pattern
1
0..1
TM-Mdl::JourneyPattern
runs
0..*
*
1
0..* 0..*
TM-Mdl::ServicePattern
info
1
TM-Mdl::VehicleJourney
block
1
stops
stops
2..*
0..*
origin
*
1
0..1
TM-Mdl::CourseOfJourney
«group»
Siri Mdl::VehicleJourneyInfo
0..1
«group»
TM-Mdl::StopPointInSequence
0..*
0..*
passing times
0..*
0..1
0..*
at
destination
0..1
TM-Mdl::DatedVehicleJourney
0..1
TM-Mdl::StopPoint
1
run
0..*
1
0..*
*
calls
time
TM-Mdl::PassingTime
stop point
0..*
Siri Mdl::MonitoredVehicleJourney
2..* 1
Siri Mdl::DatedCall
Figure 3-6 Transmodel entities relevant for SIRI
© Copyright Kizoom 2006-2007
Page 21
SIRI Functional Services - UML Diagrams
See the Transmodel specification for full definitions. The following notes outline the relevance of 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 an 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.

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 in the LINE may follow
different journey patterns that follow different branches or 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 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 TargetedVehicleJourney, EstimatedVehicleJourney, and InterchangeJourney.
© Copyright Kizoom 2006-2007
Page 22
SIRI Functional Services - UML Diagrams
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 point in a journey pattern of a vehicle journey), 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.
{ Assignment is to at least one out
of STOP PLACE, QUAY and
BOARDING POSITION.
If a STOP POINT is
associated with QUAY, implies
association wth parent.}
StopPlace
StopPlaceId[1] : StopPlaceId
PublicCode[1] : StopPlaceCode
StopPlaceName[0..1] : nlString
StopPlaceShortName[0..1] : nlString
StopPlaceType[1] : StopPlaceTypeEnum
Quays[0..*] : Quay
AccessSpaces[0..*] : AccessSpace
Entrances[0..*] : Easement
TM-Mdl::ValidityCondition
applies when
0..*
FromDateTime
ToDateTime
DayType
HolidayType
1
1
1
is to
available
AbstracStopAssignment
1
quays
0..*
Timeband
AssignmentId
StopPlaceRef
BandType
StartTime
EndTime
0..*
0..*
Quay
PublicCode[0..1]
QuayName[0..1] : nlString
Label[0..1] : nlString
DestinationDisplay[0..1] : nlString
QuayType[0..1] : Reason
Bearing[0..1] : Bearing
0..*
0..1of
any
1positions
ScheduledStopPointRef
QuayRef
BoardingPositionRef
1
1
*
StopPointCode
StopPointName : nlString
ShortName : nlString
PassengerStopPointAssignment
0..*
change to
0..1
0..*
BoardingPosition
TM-Mdl::StopPoint
for
is to
PublicCode[1]
IFOPT / TS278 SG6
Stop Place
Basic Assignment Model
0..*
DynamicStopPointAssignment
BaseAssignmentRef
© Crown Copyright 2007
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.
© Copyright Kizoom 2006-2007
Page 23
SIRI Functional Services - UML Diagrams
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 AbstractFunctionalServiceDelivery. (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).
© Copyright Kizoom 2006-2007
Page 24
SIRI Functional Services - UML Diagrams
1
requestor
Siri Mdl::Participant
producer
ParticipantCode[1]
0..*
0..*
1
1
0..1
ConsumerService
producer
ProducerService
ConsumerRef[1] : ParticipantCode
requestor
ConsumerEndPoint[1] : EndPointAddress
LastUsedMessageIdentifier[1] : MessageQualifier
ProducerRef[1] : ParticipantCode
EndPoint[1] : EndPointAddress
LastUsedIdentifier[0..1] : MessageQualifier
subscriber
1
0..*
ProducerResponse
1
ResponseTimeStamp[1] : dateTime
ProducerRef[0..1] : ParticipantCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
RequestMessageRef[0..1] : MessageQualifier
ServiceRequest
RequestContext[1] : RequestContext
RequestTimestamp[1] : dateTime
Address[1] : EndPointAddress
RequestorRef[1] : ParticipantCode
MessageIdentifer[1] : string
requests
RequestTimestamp[1] : dateTime
MessageIdentifier[0..1] : MessageQualifier
1
fulfils
Topics, Policies
0..*
0..*
AbstractFunctionalServiceDelivery
AbstractFunctionalServiceRequest
payload
responses
0..*
0..*
1
1
0..*
1
SiriXxxFsRequest
ServiceDelivery
ResponseTimeStamp[1] : dateTime
RequestMessageRef[0..1] : MessageQualifier
SubscriberRef[0..1] : ParticipantCode
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
SubscriptionRef[0..1] : SubscriptionCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
ValidUntil[0..1] : dateTime
ShortestPossibleCycle[0..1] : positiveDuration
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
MoreData[1] : boolean
errors 1
1
errors
1
0..1
0..1
ErrorCondition
Error[1] : AbstractError
Description[1] : ErrorDescription
SIRI Request/Response Entities
& Generic messages
payload
0..*
SiriXxxFsDelivery
© 2007 SIRI
AbstractItem
RecordedAtTime[1] : dateTime
payload
1
*
contents
SiriXxxItem
Figure 3-8 SIRI Request/Response entities
© Copyright Kizoom 2006-2007
Page 25
payload
SIRI Functional Services - UML Diagrams
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 (SiriXxxFsSubscriptionRequest) 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.
© Copyright Kizoom 2006-2007
Page 26
SIRI Functional Services - UML Diagrams
subscriber, consumer and producer services
each keep their own subscription
store of active subscriptions.
subscriber
1
Siri Mdl::Participant
*
SubscribingService
1
producer
ParticipantCode[1]
*
1
manager for
0..*
1
1
SubscriberRef[1] : ParticipantCode
Endpoint[1] : EndPointAddress
LastUsedSubscription[1] : SubscriptionCode
1
serves
1
SubscriptionManager
0..1
consumer for
0..*
1
1
ProducerService
filters
1
subscriber
subscriber
ConsumerService
ProducerRef[1] : ParticipantCode
EndPoint[1] : EndPointAddress
LastUsedIdentifier[0..1] : MessageQualifier
*
ConsumerRef[1] : ParticipantCode
ConsumerEndPoint[1] : EndPointAddress
LastUsedMessageIdentifier[1] : MessageQualifier
subscriptions
SubscriptionFilter
FilterCode[1] : SubscriptionFilterCode
SubscriberRef[1] : ParticipantCode
1
subscriber
0..1
creates
subscriptions
creates
0..1
0..*
filter 0..1
matches
filtered by
0..*
AbstractFunctionalSubscriptionRequest
0..*
SubscriberRef[1] : ParticipantCode
SubscriptionIdentifier[1] : SubscriptionCode
InitialTerminationTime[1] : dateTime
requests
0..*
0..*
subscription
request 1
0..*
0..*
0..*
Subscription
AbstractFunctionalServiceDelivery
SubscriberRef[1] : ParticipantCode
SubscriptionIdentifier[1] : SubscriptionCode
SubscriberEndPoint[1] : EndPointAddress
ConsumerEndPoint[1] : EndPointAddress
ValidUntil[1] : dateTime
ResponseTimeStamp[1] : dateTime
RequestMessageRef[0..1] : MessageQualifier
SubscriberRef[0..1] : ParticipantCode
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
SubscriptionRef[0..1] : SubscriptionCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
Status[0..1]
returns : boolean
ErrorCondition[0..1] : ErrorCondition
ValidUntil[0..1] : dateTime
ShortestPossibleCycle[0..1] : positiveDuration
fulfils
0..1
1
1
1
0..*
SiriXxxFsRequest, SubscriptionPolicy
SiriXxxFsSubscriptionRequest
request
1
AbstractFunctionalServiceRequest
payload
SiriXxxFsDelivery
granted for
RequestTimestamp[1] : dateTime
MessageIdentifier[0..1] : MessageQualifier
0..*
SubscriptionRequest
AbstractItem
RequestTimestamp[1] : dateTime
Address[0..1] : EndPointAddress
RequestorRef[1] : Participant
MessageIdentifer[0..1] : MessageQualifier
ConsumerAddress[0..1] : EndPointAddress
SubscriptionFilterIdentifier[0..1] : nmtoken
SubscriptionContext[0..1] : SubscriptionContext
RecordedAtTime[1] : dateTime
1
contents
*
payload
SiriXxxItem
Topics, Policies
1
SiriXxxFsRequest
requests
1
status for
1
*
SubscriptionResponse
1
ResponseTimeStamp[1] : dateTime
Address[0..1] : EndPointAddress
ResponderRef[0..1] : ParticipantCode
RequestMessageRef[0..1] : MessageQualifier
ResponseStatus[0..1] : ResponseStatus
SubscriptionManagerAddress[0..1] : EndPointAddress
ServiceStartedTime[0..1] : dateTime
Extensions[0..1] : any
statuses
1
1
SIRI Publish Subscribe Entities
& Generic messages
© 2007 SIRI
ResponseStatus
*
ResponseTimeStamp[1] : dateTime
RequestMessageRef[0..1] : MessageQualifier
SubscriberRef[0..1] : ParticipantCode
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
SubscriptionRef[0..1] : SubscriptionCode
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
ValidUntil[0..1] : dateTime
ShortestPossibleCycle[0..1] : positiveDuration
Figure 3-9 SIRI Publish/Subscribe entities
© Copyright Kizoom 2006-2007
Page 27
SIRI Functional Services - UML Diagrams
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.
© Copyright Kizoom 2006-2007
Page 28
SIRI Functional Services - UML Diagrams
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.
© Copyright Kizoom 2006-2007
Page 29
SIRI Functional Services - UML Diagrams
Siri Rqs::SubscriptionRequest
1
1
1111
0..*
subscription requests
PT-Rqs::ProductionTimetableSubscriptionRequest0..*
1
request
ET-Rqs::EstimatedTimetableSubscriptionRequest
0..*
1
request ST-Rqs::StopTimetableSubscriptionRequest0..*
1
PT-Rqs::ProductionTimetableRequest
1
request
SM-Rqs::StopMonitoringSubscriptionRequest
0..*
*
ET-Rqs::EstimatedTimetableRequest
0..*
1
request
VM-Rqs::VehicleMonitoringSubscriptionRequest 0..*
1
1
request
ST-Rqs::StopTimetableRequest
0..*
0..*
0..*
CT-Rqs::ConnectionTimetableSubscriptionRequest
1
0..*
1
request CM-Rqs::ConnectionMonitoringSubscriptionRequest
SM-Rqs::StopMonitoringRequest
1
1
0..*
VM-Rqs::VehicleMonitoringRequest
0..*
GM-Rqs::GeneralMessageSubscriptionRequest
0..*
1
request
CT-Rqs::ConnectionTimetableRequest
0..*
request
1
1
SX-Rqs::SituationExchangeSubscriptionRequest
CM-Rqs::ConnectionMonitoringRequest
0..*
requests
1
1
GM-Rqs::GeneralMessageRequest
SX-Rqs::SituationExchangeRequest
0..*
1111
1
1
1
0..*
Siri Rqs::ServiceRequest
SIRI Service
Requests
© 2007 SIRI
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.
Siri Rqs::ServiceDelivery
0..*
0..*
1
1
1
*
PT-Dlv::ProductionTimetableDelivery
0..*
0..*
FM-Dlv::FacilitiesMonitoringDelivery
SX-Dlv::SituationExchangeDelivery
ET-Dlv::EstimatedTimetableDelivery
0..*
0..*
ST-Dlv::StopTimetableDelivery
*
SIRI Service Deliveries
0..*
SM-Dlv::StopMonitoringDelivery
GM-Dlv::GeneralMessageDelivery
CM-Dlv::ConnectionMonitoringFeederDelivery
CM-Dlv::ConnectionMonitoringDistributorDelivery
0..*
© 2007 SIRI
VM-Dlv::VehicleMonitoringDelivery
CT-Dlv::ConnectionTimetableDelivery
0..*
Figure 4-2 Summary of SIRI Functional Service Deliveries
© Copyright Kizoom 2006-2007
Page 30
SIRI Functional Services - UML Diagrams
5. SIRI STOP MONITORING (SM)
The SIRI Stop Monitoring Service provides a stop-centric view of vehicle arrivals and departures at a
designated stop. It can be used by displays and other delivery services to provide departure board and
other presentations of timetabled and real-time journey information both at stops and remotely. The
choice of data elements to display and the presentation format is up to the client system. The service
can be used in conjunction with the SIRI Stop Timetable service, which provides scheduled data.

The Topics allow a Consumer system to specify that only stop departures and arrivals for a
specific Monitoring point, Operator, Line, or Direction are to be returned.

The Request Policies allow a Consumer system to control the amount of data returned, both
in terms of the number of elements and level of detail.

The Subscription Policies allow a Consumer system to control the change threshold for
returning an update, so that for example an update is only sent if prediction has changed by
more than a given amount.

The Delivery message can include not only service arrival and departure times, but also text
notices and the identifiers of Situation elements associated with the stop and/or line.
SIRI-SM: SUBSCRIPTION & REQUEST
STOPMONITORINGREQUEST SUMMARY
SIRI-SM Summary
StopMonitoringSubscription
& StopMonitoringRequest
requestor
SubscriptionRequest
Participant
0..*
0..*
1
1
requests
0..*
1
© 2007 SIRI
policies
ServiceRequest
StopMonitoringSubscriptionRequest
request
requests
1
1
1
0..1
StopMonitoringSubscriptionPolicies
1
0..*
IncrementalUpdates[1]
ChanegBeforeUpdate[1]
StopMonitoringRequest
1
topics
1
0..1
StopMonitoringPolicies
policies
Monitor
StopMonitoringTopics
monitor
0..1
0..*
operator
0..1
0..*
PreviewInterval[0..1]
StartTime[0..1]
MonitoringRef[0..1]
OperatorRef[0..1]
LineRef[0..1]
DirectionRef[0..1]
DestinationRef[0..1]
StopVisitTypes[1]
0..*
0..1
line
0..1
Line
0..*
direction
0..1
Direction
Operator
«enumeration»
StopVisitTypesEnum
all
arrivals
departures
Language[0..1]
MaximumStopVisits[0..1]
MinimumStopVisitsPerLine[0..1]
MaximumTextLength[0..1]
StopMonitoringDetailLevel[0..1]
MaximumNumberOfPreviousCalls[0..1]
MaximumNumberOfOnwardCalls[0..1]
«enumeration»
SmDetailLevelEnum
minimum
basic
normal
calls
full
Figure 5-1 StopMonitoringRequest - Summary
© Copyright Kizoom 2006-2007
Page 31
SIRI Functional Services - UML Diagrams
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.
context
Siri Rqs::SubscriptionRequest
requestor
Siri Mdl::Participant
1
1
0..*
1
RequestTimestamp[1] : dateTime
Address[0..1] : EndPointAddress
RequestorRef[1] : Participant
MessageIdentifer[0..1] : MessageQualifier
ConsumerAddress[0..1] : EndPointAddress
SubscriptionFilterIdentifier[0..1] : nmtoken
SubscriptionContext[0..1] : SubscriptionContext
subscriber
requestor
1
SIRI-SM StopMonitoringSubscription
& StopMonitoringRequest
© 2007 SIRI
1
requests
Siri Rqs::AbstractFunctionalSubscriptionRequest
SubscriberRef : ParticipantCode
SubscriptionIdentifier : SubscriptionCode
InitialTerminationTime : dateTime
0..*
Siri Rqs::ServiceRequest
RequestContext[1] : RequestContext
RequestTimestamp[1] : dateTime
Address[1] : EndPointAddress
RequestorRef[1] : ParticipantCode
MessageIdentifer[1] : string
0..*
Siri Rqs::SubscriptionContext
0..1
0..*
StopMonitoringSubscriptionRequest
StopMonitoringRequest[1] : StopMonitoringRequest
StopMonitoringSubscriptionPolicies[0..1] : StopMonitoringSubscriptionPolicies
Extensions[0..1] : any
1
1 context
requests
1
request
0..1
Siri Rqs::AbstractFunctionalServiceRequest
1
policies
RequestTimestamp : dateTime
MessageIdentifier : MessageQualifier
Siri Rqs::RequestContext
0..1
0..*
1
StopMonitoringSubscriptionPolicies
IncrementalUpdates[1] : boolean
ChanegBeforeUpdate[1] : duration
StopMonitoringRequest
StopMonitoringTopics[0..1] : StopMonitoringTopics
StopMonitoringPolicies[0..1] : StopMonitoringPolicies
Extensions[0..1] : any
policies
1topics
Siri Mdl::Monitor
0..1
1
0..1
0..1
StopMonitoringPolicies
monitor
StopMonitoringTopics
0..*
TM-Mdl::Operator
operator
0..1
0..*
PreviewInterval[0..1] : duration
StartTime[0..1] : dateTime
MonitoringRef[0..1] : MonitoringCode
OperatorRef[0..1] : OperatorCode
LineRef[0..1] : LineCode
DirectionRef[0..1] : DirectionCode
DestinationRef[0..1] : DestinationCode
StopVisitTypes[1] : StopVisitTypesEnum
line
0..*
0..*
TM-Mdl::Line
0..1
direction
1
directions
Language[0..1] : lang
MaximumStopVisits[0..1] : positiveInteger
MinimumStopVisitsPerLine[0..1] : positiveInteger
MaximumTextLength[0..1] : positiveInteger
StopMonitoringDetailLevel[0..1] : SmDetailLevelEnum
MaximumNumberOfPreviousCalls[0..1] : positiveInteger
MaximumNumberOfOnwardCalls[0..1] : positiveInteger
«enumeration»
SM-Mdl::StopVisitTypesEnum
all
arrivals
departures
«enumeration»
SM-Mdl::SmDetailLevelEnum
minimum
basic
normal
calls
full
TM-Mdl::Direction
0..*
0..1
Figure 5-2 StopMonitoringRequest - Detail
© Copyright Kizoom 2006-2007
Page 32
SIRI Functional Services - UML Diagrams
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 MonitoredVehicleJourney 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..*
1
producer
Siri Rqs::ProducerResponse
SIRI-SM Summary
StopMonitoringDelivery
Siri Mdl::Participant
errors
© 2006 SIRI
Siri Rqs::ServiceDelivery
Siri Rqs::ErrorCondition
1
0..1
1
notice cancellations
StopMonitoringDelivery
deliveries
*
version[1]
Note[0..1]
Extensions[0..1]
1
cancellations
visits
1
1
1
cancels
1
0..1
MonitoredStopVisitCancellation
TM-Mdl::Direction
0..1
0..*
MonitoringRef[1]
VisitNumber[1]
LineRef[1]
DirectionRef[1]
VehicleJourneyRef[0..1]
ClearDownRef[0..1]
JourneyPatternInfo[0..1]
Reason[0..1]
Extensions[0..1]
1
line notices
StopLineNotice
MonitoringRef[1]
LineRef[1]
0..*
DirectionRef[1]
LineNote[0..1]
SituationRef[0..1]
Extensions[0..1] 0..* 0..1
MonitoredStopVisit
MonitoringRef[1]
CleardownRef[0..1]
MonitoredVehicleJourney[1]
StopVisitNote[0..1]
Extensions[0..1]
montor
0..*
0..1
TM-Mdl::Route
0..*
cancels
1
line
1
line
1
pattern
1
0..1
pattern info
1
1
1
0..1
journey info
Siri Mdl::AbstractMonitoredCall
previous
MonitoredVehicleJourneyIdentity[1]
JourneyPatternInfo[1]
VehicleJourneyInfo[1]
DisruptionInfo[0..1]
JourneyProgress[0..1]
TrainBlockPart[0..1]
OperationalInfo[0..1]
PreviousCalls[0..*]
MonitoredCall[0..1]
OnwardCalls[0..*]
IsCompleteCallSequence[0..1]
Extensions[0..1]
current
1
1
1
0..*
1
disruption
onward
0..1
Siri Mdl::OnwardCall
0..*
Siri Mdl::PreviousCall
0..1
VehicleAtStop[0..1]
ArrivalTimes[0..1]
DepartureTimes[0..1]
Extensions[0..1]
TM-Mdl::StopPoint
Siri Mdl::MonitoredCall
VehicleAtStop[0..1]
VehicleLocationAtStop[0..1]
ReversesAtStop[0..1]
PlatformTraversal[0..1]
SignalStatus[0..1]
CallNote[0..1]
Disruption[0..1]
ArrivalTimes[0..1]
ArrivalInfo[0..1]
DepartureTimes[0..1]
DepartureInfo[0..1]
HeadwayInfo[0..1]
Extensions[0..1]
See Monitored
Vehicle Journey
Diagrams for
details
1
0..1
stop
1..1
identity
0..*
0..*
1
journey
1
«group»
Siri Mdl::FramedVehicleJourneyRef
DataFrameRef[1]
DatedVehicleJourneyRef[1]
Siri Mdl::MonitoredVehicleJourney
«group»
Siri Mdl::ServiceInfo
StopPointRef[0..1]
VisitNumber[0..1]
Order[0..1]
StopPointName[0..1]
0..*
«group»
Siri Mdl::MonitoredJourneyIdentity
LineRef[0..1]
DirectionRef[0..1]
FramedVehicleJourneyRef[1..1]
journey
TM-Mdl::DatedVehicleJourney
0..1
0..*
«group»
Siri Mdl::VehicleJourneyInfo
StopLineNoticeCancellation
MonitoringRef[1]
LineRef[1]
DirectionRef[1]
Extensions[0..1]
TM-Mdl::Line
«group»
Siri Mdl::JourneyPatternInfo
info
0..1
0..*
0..1
route
0..1
pattern
0..*
0..1montor
Siri Mdl::Monitor
0..1
TM-Mdl::JourneyPattern
0..*
VehicleAtStop[0..1]
TimingPoint[0..1]
AimedArrivalTimes[0..1]
ArrivalInfo[0..1]
AimedDepartureTimes[0..1]
DepartureInfo[0..1]
HeadwayInfo[0..1]
Extensions[0..1]
«group»
Siri Mdl::DisruptionInfo
SituationRef[0..1]
FacilityChange[0..1]
0..*
0..1
situation
0..1
disruption
SX-Mdl::AbstractSituation
1
Figure 5-3 StopMonitoringDelivery - Summary
© Copyright Kizoom 2006-2007
Page 33
SIRI Functional Services - UML Diagrams
STOPMONITORINGDELIVERY DETAIL
Figure 5-4 shows detailed attributes of a Stop Monitoring delivery – further details of the
MonitoredVehicleJourney are described in further diagrams below.
SIRI-SM
StopMonitoringDelivery
Siri Rqs::ProducerResponse
ResponseTimeStamp : dateTime
ProducerRef : ParticipantCode
Address : EndPointAddress
ResponseMessageIdentifier : MessageQualifier
RequestMessageRef : MessageQualifier
producer
0..1
Siri Mdl::Participant
© 2006 SIRI
0..*
1
subscriber
Siri Rqs::ServiceDelivery
1
errors
Siri Rqs::AbstractFunctionalServiceDelivery
ResponseTimeStamp[1] : dateTime
RequestMesageRef[0..1] : MessageQualifier
SubscriberRef[0..1] : ParticipantCode
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
SubscriptionRef[0..1] : SubscriptionCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
ValidUntil[0..1] : dateTime
ShortestPossibleCycle[0..1] : positiveDuration
Status : boolean
ErrorCondition : ErrorCondition
MoreData : boolean
0..*
0..1
1
errors
Siri Rqs::ErrorCondition
deliveries
Error[1] : AbstractError
Description[1] : ErrorDescription
0..*
1
*
StopMonitoringDelivery
1
1
version[1] : versionString
Note[0..1] : populatedString
Extensions[0..1]
1
visits
Siri Rqs::AbstractItem
1
RecordedAtTime[1] : dateTime
Siri Rqs::AbstractReferencedItem
line notices
IdentifiedItemRef[0..1] : IdentifiedItemCode
Siri Rqs::AbstractIdentifiedItem
cancellations
IdentifiedItemCode[0..1] : IdentifiedItemCode
notice cancellations
MonitoredStopVisitCancellation
0..*
MonitoredStopVisit
MonitoringRef[1] : MonitoringCode
CleardownRef[0..1] : CleardownCode
MonitoredVehicleJourney[1] : MonitoredVehicleJourney
StopVisitNote[0..1] : populatedString
Extensions[0..1] : any
0..*
1
cancels
0..1
0..*
0..1
Siri Mdl::Monitor
0..*
See Monitored
Vehicle Journey
Diagrams for
details
1
StopLineNotice
0..1
Siri Mdl::PreviousCall
0..1
1
0..*
line
0..1
1
1
StopLineNoticeCancellation
MonitoringRef[1] : MonitoringCode
LineRef[1] : LineCode
DirectionRef[1] : DirectionCode
Extensions[0..1]
1
TM-Mdl::DataFrame
frame
0..*
«group»Siri Mdl::FramedVehicleJourneyRef
DataFrameRef[1] : DataFrameCode
DatedVehicleJourneyRef[1] : DatedVehicleJourneyCode
0..*
directions
1
journey
0..*
1
1
line
TM-Mdl::Line
journey
TM-Mdl::DatedVehicleJourney
0..1
0..*
1
identity
«group»Siri Mdl::MonitoredJourneyIdentity
LineRef[0..1] : LineCode
DirectionRef[0..1] : DirectionCode
FramedVehicleJourneyRef[1..1] : FramedVehicleJourneyRef
Siri Mdl::OnwardCall
Siri Mdl::MonitoredCall
cancels
1
TM-Mdl::Direction0..1
onward
0..*
0..*
direction
1
0..*
Siri Mdl::MonitoredVehicleJourney
1
current
0..1
MonitoringRef[1] : MonitoringCode
LineRef[1] : LineCode
DirectionRef[1] : DirectionCode
LineNote[0..1] : populatedString
SituationRef[0..1] : SituationCode
Extensions[0..1]
MonitoredVehicleJourneyIdentity[1] : MonitoredJourneyIdentity
JourneyPatternInfo[1] : JourneyPatternInfo
VehicleJourneyInfo[1] : VehicleJourneyInfo
DisruptionInfo[0..1] : DisruptionInfo
JourneyProgress[0..1] : ProgressInfo
TrainBlockPart[0..1] : TrainBlockPart
OperationalInfo[0..1] : OperationalInfo
PreviousCalls[0..*] : PreviousCall
MonitoredCall[0..1] : MonitoredCall
OnwardCalls[0..*] : OnwardCall
IsCompleteCallSequence[0..1] : boolean
Extensions[0..1] : any
previous
1
SX-Mdl::AbstractSituation
situation
0..1
monitor
journey
1
montor
0..*
MonitoringRef[1] : MonitoringCode
VisitNumber[1] : VisitNumber
LineRef[1] : LineCode
DirectionRef[1] : DirectionCode
VehicleJourneyRef[0..1]
ClearDownRef[0..1] : CleardownCode
JourneyPatternInfo[0..1] : JourneyPatternInfo
Reason[0..1] : populatedString
Extensions[0..1] : any
1..1
Figure 5-4 StopMonitoringDelivery – Detail
© Copyright Kizoom 2006-2007
Page 34
SIRI Functional Services - UML Diagrams
USE OF MONITOREDVEHICLEJOURNEY ELEMENT FOR SIRI-SM
LEVELS OF DETAIL
The MonitoredVehicleJourney element represents an individual vehicle journey that is being
monitored: it can be populated with different amounts of data for different applications. For example,
for the Stop Monitoring service, it might contain just information about the time of the vehicle at the
monitored stop (if say the requested DetailLevel=normal), or it might also included predicted times at
all the subsequent stops along the route (if say DetailLevel=calls).
Detail
Level
Definition.
Purpose
minimum
Return only minimum data: a single MonitoredCall with
a stop ids and passing time
Used for exchanging just real-time
data between systems that are not
concerned with other details.
basic
Return useful basic minimum data. A single
MonitoredCall for each MonitoredVehicleJourney
visiting the Stop, with passing times, and line id.
Used to drive simple displays with
limited space that show just lines and
passing times and line numbers.
normal
Return a single MonitoredCall at the stop for each
MonitoredVehicleJourney, populated with with times,
stop id, Stop name, DestinationDisplay values (i.e.
headings), status etc.
Use for normal departure boards that
show arrival/departure times for each
vehicle along with names (but not a
calling pattern).
calls
Return additional information including Onwards and
Previous elements with the previous and onward calling
pattern, modulated by the NumberOfCalls on the
request.
Use for departure boards that need to
show the full calling pattern or the
onward calling pattern.
full
Return all information including full calling pattern,
operational data (BlockRef, VehicleRef, etc), progress
data, journey pattern references etc
Used for data exchange between
operational services, or for advanced
display services.
Table 5-1 StopMonitoringRequest Detail Levels
For train services, where there may be different carriages going to different places representing
different vehicle journeys, train block parts can be used to identify which section of the train is
involved. There will be separate deliveries for each vehicle journey.
PASSING TIMES
The times that are included on each call may include an arrival or departure time or both (depending
whether it is the start, end or middle of a route), and planned (Aimed), predicted (Expected) or
observed (Actual) - (depending whether it has reached the stop yet. Times are always absolute (i.e. in
UTC): it is up to the delivery system to render these – often they will be shown on signs as relative e.g.
“in two minutes”. Some systems only return average or pedicted 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
© Copyright Kizoom 2006-2007
Page 35
SIRI Functional Services - UML Diagrams
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.
© Copyright Kizoom 2006-2007
Page 36
SIRI Functional Services - UML Diagrams
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..*
TM-Mdl::JourneyPattern
pattern
TM-Mdl::Block
TM-Mdl::DatedVehicleJourney
0..1
0..1
block
1
0..1
journey
TM-Mdl::DataFrame
0..*
0..1
TM-Mdl::Vehicle
«group»
1
JourneyPatternInfo
«group»
0..1
TM-Mdl::Line
FramedVehicleJourneyRef
0..*
JourneyPatternRef[0..1]
journey0..*
VehicleMode[0..1]
DataFrameRef[1]
TM-Mdl::CourseOfJourney
1
RouteRef[0..1]
0..1
DatedVehicleJourneyRef[1]
0..*
0..1
0..*
line
PublishedLineName[0..1]
1
0..1
DirectionName[0..1]
«group»
«group»OperationalInfo
ExternalLineRef[0..1]
MonitoredJourneyIdentity
0..1 route
BlockRef[0..1]
LineRef[0..1]
0..*TM-Mdl::TrainPart
TM-Mdl::Route
CourseOfJourneyRef[0..1]
DirectionRef[0..1]
0..*
pattern info 0..*
VehicleRef[0..1]
FramedVehicleJourneyRef[1..1]
train
0..* 0..1
identity
operational
1
«group»VehicleJourneyInfo
1
1..1
0..1
ServiceInfo[0..1]
TM-Mdl::TrainBlockPart
OriginRef[0..1]
MonitoredVehicleJourney
NumberOfBlockParts[0..1]
DestinationName[0..1]
train block
1
MonitoredVehicleJourneyIdentity[1]
TrainPartRef[0..1]
OriginShortName[0..1]
JourneyPatternInfo[1]
PositionOfTrainBlockPart[0..1]
0..1
Via[0..*]
VehicleJourneyInfo[1]
0..1
DestinationRef[0..1]
1
DisruptionInfo[0..1]
1
DestinationName[0..1]
JourneyProgress[0..1]
DestinationShortName[0..1]
TrainBlockPart[0..1]
VehicleJourneyNote[0..1]
OperationalInfo[0..1]
1
«group»ProgressInfo
JourneyNote[0..1]
PreviousCalls[0..*]
progress
HeadwayService[0..1]
Monitored[0..1]
0..*
destination
MonitoredCall[0..1]
OriginAimedDepartureTime[0..1]
MonitoringError[0..1]
OnwardCalls[0..*]
0..1
DestinationAimedDepartureTime[0..1]
locationInCongestion[0..1]
1
IsCompleteCallSequence[0..1]
Loc Mdl::Location
InPanic[0..1]
0..1
Extensions[0..1]
1
1 info 0..*
PredictionInaccurate[0..1] disruption
0..1
DataSource[0..1]
origin
«enumeration»
1 stop
0..1
ConfidenceLevel[0..1]
0..1
AbstractMonitoredCall
OccupancyEnum
VehicleLocation[0..1]
0..*
TM-Mdl::StopPoint
StopPointRef[0..1]
Bearing[0..1]
full
0..1
«group»ServiceInfo
VisitNumber[0..1]
ProgressRate[0..1]
seatsAvailable
Order[0..1]
Occupancy[0..1]
standingAvailable
OperatorRef[0..1]
StopPointName[0..1]
Delay[0..1]
VehicleFeature
ProductCategoryRef[0..1]
ProgressStatus[0..1]
ServiceFeatureRef[0..*]
0..1
0..*
OnwardCall
VehicleFeatureRef[0..*]
0..*
0..* ServiceFeature
VehicleAtStop[0..1]
operator
0..1
TimingPoint[0..1]
0..*
1
«enumeration»
arrival
0..1
AimedArrivalTimes[0..1]
ProgressRateEnum
PreviousCall
ArrivalInfo[0..1]
1
noProgress
VehicleAtStop[0..1]
AimedDepartureTimes[0..1]
TM-Mdl::Operator
headway
1
slowProgress
ArrivalTimes[0..1]
DepartureInfo[0..1]
normalProgress
arrival
DepartureTimes[0..1]
HeadwayInfo[0..1]
1
fastProgress
Extensions[0..1]
Extensions[0..1]
0..1
*
unknown
0..1
pattern
times
1
times
«group»HeadwayInfo
0..1
«group»ArrivalInfo
ArrivalStatus[0..1]
ArrivalPlatformName[0..1]
ArrivalBoardingActivity[0..1]
«enumeration»
ArrivalActivityEnum
alighting
noAlighting
passThru
0..1
1
AimedHeadWayInterval[0..1]
ExpectedHeadwayInterval[0..1]
1
0..1
departure
«group»
AimedArrivalTimes
AimedArrivalTime[0..1]
ExpectedArrivalTime[0..1]
departure
arrival
MonitoredCall
VehicleAtStop[0..1]
VehicleLocationAtStop[0..1]
ReversesAtStop[0..1]
0..1
PlatformTraversal[0..1]
SignalStatus[0..1]
1
CallNote[0..1]
«group»DepartureTimes
0..1departure times
Disruption[0..1]
ArrivalTimes[0..1]
AimedDepartureTime[0..1]
ArrivalInfo[0..1]
ActualDepartureTimes[0..1]
DepartureTimes[0..1]
ExpectedDepartureTime[0..1]
DepartureInfo[0..1]
HeadwayInfo[0..1]
«group»ArrivalTimes
Extensions[0..1]
0..1 arrival times
AimedArrivalTime[0..1]
0..1
ActualArrivalTimes[0..1]
1
1
call
ExpectedArrivalTime[0..1]
«group»CallInfo
0..1
SIRI Summary
TimingPoint[0..1]
BoardingStretch[0..1]
MonitoredVehicleJourney
RequestStop[0..1]
© 2006 SIRI
DestinationDisplay[0..1]
headway
1
0..1
0..1
«group»
AimedDepartureTimes
AimedDepartureTime[0..1]
ExpectedDepartureTime[0..1]
1
departure
«group»DepartureInfo
10..1
DepartureStatus[0..1]
DeparturePlatformName[0..1]
DepartureBoardingActivity[0..1]
disruption
0..1
«group»DisruptionInfo
1
«enumeration»
DepartureActivityEnum
boarding
noBoarding
passThru
0..1
«enumeration»
TimeStatusEnum
early
onTime
delayed
arrived
cancelled
noReport
SituationRef[0..1]
FacilityChange[0..1]
0..*
situation
0..1
SX-Mdl::AbstractSituation
0..*
Figure 5-5 Monitored VehicleJourney - Summary
© Copyright Kizoom 2006-2007
Page 37
SIRI Functional Services - UML Diagrams
MONITOREDVEHICLEJOURNEY DETAIL
Figure 5-6 shows the detailed data attributes for a MonitoredVehicleJourney.
journey
«group»MonitoredJourneyIdentity
«group»FramedVehicleJourneyRef
LineRef[0..1] : LineCode
DirectionRef[0..1] : DirectionCode
FramedVehicleJourneyRef[1..1] : FramedVehicleJourneyRef
1
1 TM-Mdl::DatedVehicleJourney
«group»ProgressInfo
0..1
journey
DataFrameRef[1] : DataFrameCode
DatedVehicleJourneyRef[1] : DatedVehicleJourneyCode
0..*
1
TM-Mdl::TrainBlockPart
0..*
TM-Mdl::JourneyPattern
NumberOfBlockParts[0..1] : positiveInteger
Monitored[0..1] : boolean
1..1
TrainPartRef[0..1] : TrainPartCode
MonitoringError[0..1] : string
PositionOfTrainBlockPart[0..1] : populatedString
InCongestion[0..1] : boolean
0..1
TM-Mdl::Route
TM-Mdl::Line
0..1
0..1
0..*
0..*
InPanic[0..1] : boolean
0..1
0..1
PredictionInaccurate[0..1] : boolean
0..*
DataSource[0..1] : string
«group»JourneyPatternInfo
TM-Mdl::TrainPart
TM-Mdl::Block
0..*
identityConfidenceLevel[0..1] : boolean
JourneyPatternRef[0..1] : JourneyPatternCode
train block
VehicleLocation[0..1] : Location
VehicleMode[0..1] : Mode
Bearing[0..1] : Bearing
«group»OperationalInfo
RouteRef[0..1] : RouteCode
0..1
ProgressRate[0..1] : ProgressRateEnum
BlockRef[0..1] : BlockCode
PublishedLineName[0..1] : populatedString
Occupancy[0..1] : OccupancyEnum
CourseOfJourneyRef[0..1] : CourseOfJourneyCode
DirectionName[0..1] : populatedString
Delay[0..1] : duration
VehicleRef[0..1] : VehicleCode
ExternalLineRef[0..1] : LineCode
ProgressStatus[0..1] : populatedString
vehicle
pattern info
1
1
0..*
0..1 0..*
«group»VehicleJourneyInfo
0..1
1
run
ServiceInfo[0..1] : ServiceInfo
0..1
OriginRef[0..1] : JourneyPlaceCode
MonitoredVehicleJourney
DestinationName[0..1] : populatedString
TM-Mdl::Vehicle
1
MonitoredVehicleJourneyIdentity[1] : MonitoredJourneyIdentity
OriginShortName[0..1] : populatedString
JourneyPatternInfo[1] : JourneyPatternInfo
Via[0..*] : populatedString
0..1
VehicleJourneyInfo[1] : VehicleJourneyInfo
DestinationRef[0..1] : DestinationCode
1
DisruptionInfo[0..1] : DisruptionInfo
DestinationName[0..1] : populatedString
1
JourneyProgress[0..1] : ProgressInfo
TM-Mdl::CourseOfJourney
DestinationShortName[0..1] : populatedString
0..1
TrainBlockPart[0..1] : TrainBlockPart
VehicleJourneyNote[0..1] : populatedString
OperationalInfo[0..1] : OperationalInfo
JourneyNote[0..1] : populatedString
1
PreviousCalls[0..*] : PreviousCall
HeadwayService[0..1] : boolean
MonitoredCall[0..1] : MonitoredCall
OriginAimedDepartureTime[0..1] : dateTime
OnwardCalls[0..*] : OnwardCall
DestinationAimedDepartureTime[0..1] : dateTime
1
onward
destination
IsCompleteCallSequence[0..1] : boolean
origin
Extensions[0..1] : any
0..11
0..*
0..*
0..1
SX-Mdl::AbstractSituation
10..1
0..1
1
«group»
0..*
0..1
AbstractMonitoredCall
ServiceInfo
TM-Mdl::StopPoint
StopPointRef[0..1] : StopPointCode
«group»DisruptionInfo
0..*
0..*
VisitNumber[0..1] : VisitNumber
SituationRef[0..1] : SituationCode
0..1
Order[0..1] : positiveInteger
0..1
FacilityChange[0..1] : FacilityChange
StopPointName[0..1] : populatedString
0..*
0..*
0..1
TM-Mdl::Operator
1
PreviousCall
MonitoredCall
OnwardCall
VehicleAtStop[0..1] : boolean
ArrivalTimes[0..1] : ArrivalTimes
DepartureTimes[0..1] : DepartureTimes
Extensions[0..1] : any
VehicleAtStop[0..1] : boolean
VehicleLocationAtStop[0..1] : Location
ReversesAtStop[0..1] : boolean
PlatformTraversal[0..1] : boolean
1
1
SignalStatus[0..1] : string
0..1 CallNote[0..1] : populatedString
Disruption[0..1] : DisruptionInfo
1
ArrivalTimes[0..1] : ArrivalTimes
1
ArrivalInfo[0..1] : ArrivalInfo
DepartureTimes[0..1] : DepartureTimes
DepartureInfo[0..1] : DepartureInfo
1
HeadwayInfo[0..1] : HeadwayInfo
Extensions[0..1] : any
headway
VehicleAtStop[0..1] : boolean
TimingPoint[0..1] : boolean
AimedArrivalTimes[0..1] : AimedArrivalTimes
ArrivalInfo[0..1] : ArrivalInfo
AimedDepartureTimes[0..1] : AimedDepartureTimes
DepartureInfo[0..1] : DepartureInfo
HeadwayInfo[0..1] : HeadwayInfo
Extensions[0..1] : any
1
departure
departure
1
1
1
«group»CallInfo
TimingPoint[0..1] : boolean
BoardingStretch[0..1] : boolean
RequestStop[0..1] : boolean
DestinationDisplay[0..1] : populatedString
arrival
0..1
«group»ArrivalInfo
ArrivalStatus[0..1] : TimeStatusEnum
ArrivalPlatformName[0..1] : populatedString
ArrivalBoardingActivity[0..1] : ArrivalActivityEnum
0..1
«group»ArrivalTimes
0..1
0..1
disruption
1
AimedArrivalTime[0..1] : dateTime
ActualArrivalTimes[0..1] : dateTime
ExpectedArrivalTime[0..1] : dateTime
10..1
arrival times
0..1
1
0..1
1
«group»DepartureInfo
departure
DepartureStatus[0..1] : TimeStatusEnum
DeparturePlatformName[0..1] : populatedString
DepartureBoardingActivity[0..1] : DepartureActivityEnum
0..1
«group»DepartureTimes
«group»HeadwayInfo
0..1
AimedHeadWayInterval[0..1] : positiveDuration
ExpectedHeadwayInterval[0..1] : positiveDuration
times
0..1
AimedDepartureTime[0..1] : dateTime
ActualDepartureTimes[0..1] : dateTime
ExpectedDepartureTime[0..1] : dateTime
0..1
SIRI
MonitoredVehicleJourney
© 2006 SIRI
0..1
«group»AimedDepartureTimes
«group»AimedArrivalTimes
AimedArrivalTime[0..1] : dateTime
ExpectedArrivalTime[0..1] : dateTime
AimedDepartureTime[0..1] : dateTime
*
: dateTime
ExpectedDepartureTime[0..1]
arrival
Figure 5-6 Monitored vehicle Journey detail
© Copyright Kizoom 2006-2007
Page 38
SIRI Functional Services - UML Diagrams
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
© Copyright Kizoom 2006-2007
Page 39
SIRI Functional Services - UML Diagrams
6. SIRI VEHICLE MONITORING (VM)
The SIRI Vehicle Monitoring Service reports the position and other real-time properties of a vehicle or
group of vehicles making monitored journeys in real-time. It can be used for example to monitor the
progress of vehicles; to provide information for systems which present visualisations of the
movement of vehicles, for instance on maps, lists or line diagrams; and to exchange information
about roaming vehicles between control centres. A particular use is to log data.
SIRI-VM: SUBSCRIPTION & REQUEST
VEHICLEMONITORINGREQUEST SUMMARY
The VehicleMonitoringRequest (Figure 6-1) is used to request real-time data for a vehicle or vehicles.
The vehicles can be identified by an arbitrary prearranged grouping, a VehicleMonitoringRef –or
other criteria such a Line (e.g. ‘N45’), Direction, or individual VehicleRef.

The Topics allow a Consumer system to specify that only vehicle movements for a specific
Vehicle Monitoring group, Line, or Line Direction or Vehicle are to be returned.

The Request Policies allow a Consumer system to control the amount of data returned.

The Subscription Policies allow a Consumer system to control the change threshold for
update.
subscription requests
requestor
SIRI-VM – Summary
VehicleMonitoringSubscription
& VehicleMonitoringRequest
SubscriptionRequest
1
1
0..*
requestor
Participant
1
© 2007 SIRI
0..*
0..*
1
policies
VehicleMonitoringSubscriptionRequest
request
ServiceRequest
0..1
1
VehicleMonitoringSubscriptionPolicies
1
IncrementalUpdates[0..1]
ChanegBeforeUpdate[0..1]
1
requests
policies
VehicleMonitoringRequest
0..*
1
topics1
0..1
line
VehicleMonitor
0..1
0..*
Line
0..1
0..1
monitor
vehicle
VehicleMonitoringTopics
0..*
0..*
VehicleMonitoringRef[0..1]
VehicleRef[0..1]
LineRef[0..1]
DirectionRef[0..1]
0..1
0..*
direction
Vehicle
Direction
0..1
VehicleMonitoringPolicies
Language[0..1]
MaximumVehicles[0..1]
VehicleMonitoringDetailLevel[0..1]
«enumeration»
VmDetailLevelEnum
minimum
basic
normal
calls
Figure 6-1 VehicleMonitoringRequest - Summary
© Copyright Kizoom 2006-2007
Page 40
SIRI Functional Services - UML Diagrams
VEHICLEMONITORINGREQUEST DETAIL
Figure 6-2 shows detailed attributes for a VehicleMonitoring request.
context
1
Siri Rqs::SubscriptionRequest
requestor
Siri Mdl::Participant
0..*
1
1
Siri Rqs::SubscriptionContext
0..1
requestor
RequestTimestamp[1] : dateTime
Address[0..1] : EndPointAddress
RequestorRef[1] : Participant
MessageIdentifer[0..1] : MessageQualifier
ConsumerAddress[0..1] : EndPointAddress
SubscriptionFilterIdentifier[0..1] : nmtoken
SubscriptionContext[0..1] : SubscriptionContext
0..*
SubscriberRef : ParticipantCode
SubscriptionIdentifier : SubscriptionCode
InitialTerminationTime : dateTime
subscription requests
Siri Rqs::ServiceRequest
context
1
© 2007 SIRI
Siri Rqs::AbstractFunctionalSubscriptionRequest
1
RequestContext[1] : RequestContext
RequestTimestamp[1] : dateTime
Address[1] : EndPointAddress
RequestorRef[1] : ParticipantCode
MessageIdentifer[1] : string
SIRI-VM
VehicleMonitoringSubscription
& VehicleMonitoringRequest
0..*
VehicleMonitoringSubscriptionRequest
1
requests
VehicleMonitoringRequest[1] : VehicleMonitoringRequest
VehicleMonitoringSubscriptionPolicies[0..1] : VehicleMonitoringSubscriptionPolicies
Extensions[0..1] : any
1
policies
1
request
0..1
Siri Rqs::AbstractFunctionalServiceRequest
RequestTimestamp : dateTime
MessageIdentifier : MessageQualifier
Siri Rqs::RequestContext
0..*
0..1
1
VehicleMonitoringSubscriptionPolicies
0..1
IncrementalUpdates[0..1]
ChanegBeforeUpdate[0..1] : duration
policies
VehicleMonitoringRequest
1
VM-Mdl::VehicleMonitor
VehicleMonitoringTopics[0..1] : VehicleMonitoringTopics
topics VehicleMonitoringPolicies[0..1] : StopMonitoringPolicies
Extensions[0..1] : any
monitor
1
0..1
TM-Mdl::Vehicle
0..1
VehicleMonitoringTopics
0..1
vehicle 0..*
VehicleMonitoringRef[0..1] : MonitoringCode
VehicleRef[0..1] : VehicleCode
LineRef[0..1] : LineCode
DirectionRef[0..1] : DirectionCode
0..*line
VehicleMonitoringPolicies
Language[0..1] : lang
MaximumVehicles[0..1] : positiveInteger
VehicleMonitoringDetailLevel[0..1] : VmDetailLevelEnum
direction
0..*
0..*
0..1
0..1
TM-Mdl::Line
directions
TM-Mdl::Direction
1
0..*
«enumeration»
VM-Mdl::VmDetailLevelEnum
minimum
basic
normal
calls
Figure 6-2 VehicleMonitoringRequest - Detail
© Copyright Kizoom 2006-2007
Page 41
SIRI Functional Services - UML Diagrams
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.
0..*
producer
1
ProducerResponse
SIRI-VM Summary
VehicleMonitoringDelivery
Participant
© 2006 SIRI
errors
ServiceDelivery
See Monitored
Vehicle Journey
Diagrams for
details
ErrorCondition
deliveries
1
0..1
0..*
1
1
activity
cancellation
VehicleMonitoringDelivery
0..*
0..*
1
VehicleActivity
1
progress
0..1
ProgressBetweenStops
VehicleActivityCancellation
cancels
ValidUntilTime[1]
VehicleMonitoringRef[1]
1
ProgressBetweenStops[0..1]
MonitoredVehicleJourney[1]
monitor
VehicleActivityNote[0..*]
Extensions[0..1]
0..*
journey
0..1
1
0..1
0..1
VehicleMonitor
1
LinkDistance[0..1] : decimal
Percentage[0..1] : decimal
monitor
1
0..1
JourneyPattern
0..*
pattern
«group»
0..1
JourneyPatternInfo
1
operational
1
disruption
Block
0..1
block
0..* 0..1
«group»
Siri Mdl::OperationalInfo
0..1
MonitoredVehicleJourneyIdentity[1]
JourneyPatternInfo[1]
VehicleJourneyInfo[1]
DisruptionInfo[0..1]
JourneyProgress[0..1]
TrainBlockPart[0..1]
OperationalInfo[0..1]
PreviousCalls[0..*]
MonitoredCall[0..1]
OnwardCalls[0..*]
IsCompleteCallSequence[0..1]
Extensions[0..1]
0..*
«group»
0..1
situation DisruptionInfo
1
1..1
progress
«enumeration»
OccupancyEnum
full
seatsAvailable
standingAvailable
1
«group»
ProgressInfo
Monitored[0..1]
MonitoringError[0..1]
InCongestion[0..1]
InPanic[0..1]
PredictionInaccurate[0..1]
DataSource[0..1]
ConfidenceLevel[0..1]
VehicleLocation[0..1]
Bearing[0..1]
ProgressRate[0..1]
Occupancy[0..1]
Delay[0..1]
ProgressStatus[0..1]
0..1
0..*
MonitoredCall
journey1
«group»
MonitoredJourneyIdentity
LineRef[0..1]
DirectionRef[0..1]
FramedVehicleJourneyRef[1..1]
1
journey info
departure
«enumeration»
ProgressRateEnum
noProgress
slowProgress
normalProgress
fastProgress
unknown
1location
0..1
onward 0..1
0..*
OnwardCall
0..1
Location
id[0..1]
srsName[0..1]
Longitude[0..1]
Latitude[0..1]
Coordinates[0..1]
Precision[0..1]
0..1
0..*
Line
directions
direction
1
0..1
«group»
VehicleJourneyInfo
ServiceInfo[0..1]
OriginRef[0..1]
DestinationName[0..1]
OriginShortName[0..1]
Via[0..*]
DestinationRef[0..1]
DestinationName[0..1]
DestinationShortName[0..1]
VehicleJourneyNote[0..1]
JourneyNote[0..1]
HeadwayService[0..1]
OriginAimedDepartureTime[0..1]
DestinationAimedDepartureTime[0..1]
1
1
departure
0..1
0..*
0..* line
1
Direction
1
Siri Mdl::PreviousCall
0..1
0..*
0..*
1
0..1
VehicleAtStop[0..1]
VehicleLocationAtStop[0..1]
ReversesAtStop[0..1]
PlatformTraversal[0..1]
SignalStatus[0..1]
CallNote[0..1]
Disruption[0..1]
ArrivalTimes[0..1]
ArrivalInfo[0..1]
DepartureTimes[0..1]
DepartureInfo[0..1]
HeadwayInfo[0..1]
Extensions[0..1]
frame
«group»
FramedVehicleJourneyRef
identity
1 current
1
DataFrame
journey
1
Situation
previous
0..*
DatedVehicleJourney
MonitoredVehicleJourney
pattern info
VehicleMonitoringRef[1]
VehicleJourneyRef[1]
LineRef[1]
DirectionRef[1]
JourneyPatternInfo[0..1]
Reason[0..1]
Extensions[0..1]
«group»
DepartureInfo
DepartureStatus[0..1]
DeparturePlatformName[0..1]
DepartureBoardingActivity[0..1]
info
0..1
«group»
ServiceInfo
OperatorRef[0..1]
ProductCategoryRef[0..1]
ServiceFeatureRef[0..*]
VehicleFeatureRef[0..*]
Operator
0..1
operator
0..*
«enumeration»
TimeStatusEnum
early
onTime
delayed
arrived
cancelled
noReport
Figure 6-3 VehicleMonitoringDelivery - Summary
© Copyright Kizoom 2006-2007
Page 42
SIRI Functional Services - UML Diagrams
USE OF MONITOREDVEHICLEJOURNEY ELEMENT FOR SIRI-VM
See also discussion of Passing times and Stop Identifiers under the SIRI-SM service
LEVELS OF DETAIL
The MonitoredVehicleJourney element represents an individual vehicle journey that is being
monitored: it can be populated with different amounts of data for different applications. For example,
for a simple tracking use Vehicle Monitoring service, it might contain just information about the
location of the vehicle at the monitored stop (if say the requested DetailLevel=normal), or it might
also included predicted times at all the subsequent stops along the route (if say DetailLevel=calls).
DetailLevel
Definition.
Purpose
minimum
Return only minimum data: Location
Used for exchanging just real-time
data between systems that are not
concerned with other details.
basic
Return useful basic minimum data to identify the
vehicle journey – e.g. Line id - and supply simple
ProgressInfo such as a current location,
Used to drive simple movement
displays displays with limited space
that show just lines and passing
times and line numbers.
normal
Return a single MonitoredCall at the current or next
stop for each MonitoredVehicleJourney, populated
with times, stop id, Stop name, DestinationDisplay
values (i.e. headings), status etc.
Use for on and off board next stop
displays and visualisations.
calls
Return additional information including current
MonitoredCall, Onwards, and Previous elements
with the previous and onward calling pattern,
modulated by the NumberOfCalls on the request.
Use for exchanging data for roaming,
or for replicating current vehicle
prediction
data
to
distribution
systems. Also can be used to feed
historical logging services that want
to record all the predictions at a given
moment in time.
full
Return all information including full calling pattern,
operational data (BlockRef, VehicleRef, etc),
progress data, journey pattern references etc
Used for sending data to consumer
systems that do not have all the
reference data already
Table 6-1 VehicleMonitoringRequest Detail Levels
LOCATION
The ProgressInfo group of a MonitoredVehicelJourney can include the vehicle’s current location as a
set of coordinates of a specified data reference system, e.g. WGS84.
The static coordinates of stops are part of the STOP PLACE model and are not normally included in
messages.
© Copyright Kizoom 2006-2007
Page 43
SIRI Functional Services - UML Diagrams
VEHICLEMONITORINGDELIVERY DETAIL
Figure 6-4 shows more detailed attributes of VehicleMonitoringDelivery, many of which are
concerned with supplying references to associated entities. The detailed model of a
MonitoredVehicleJourney is the same as for the StopMonitoring service, but will be populated
differently
SIRI-VM
VehicleMonitoringDelivery
Siri Rqs::ProducerResponse
0..1
producer
Siri Mdl::Participant
© 2006 SIRI
1 0..*
subscriber
Siri Rqs::AbstractFunctionalServiceDelivery
0..*
ResponseTimeStamp[1] : dateTime
RequestMessageRef[0..1] : MessageQualifier
SubscriberRef[0..1] : ParticipantCode
errors
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
SubscriptionRef[0..1] : SubscriptionCode
0..1
errors
Address[0..1] : EndPointAddress
1
ResponseMessageIdentifier[0..1] : MessageQualifier
Siri Rqs::ErrorCondition
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
Error[1] : AbstractError
0..1
ValidUntil[0..1] : dateTime
Description[1] : ErrorDescription
ShortestPossibleCycle[0..1] : positiveDuration
0..*
Siri Rqs::AbstractItem
Siri Rqs::ServiceDelivery
1
Status : boolean
ErrorCondition : ErrorCondition
MoreData : boolean
1
deliveries
VehicleMonitoringDelivery
1
RecordedAtTime[1] : dateTime
ResponseTimeStamp : dateTime
ProducerRef : ParticipantCode
Address : EndPointAddress
ResponseMessageIdentifier : MessageQualifier
RequestMessageRef : MessageQualifier
cancellation
version[1] : versionString
Extensions[1]
1
Siri Rqs::AbstractIdentifiedItem
IdentifiedItemCode[0..1] : IdentifiedItemCode
Siri Rqs::AbstractReferencedItem
activity
IdentifiedItemRef[0..1] : IdentifiedItemCode
0..*
0..*
VehicleActivity
ValidUntilTime[1] : dateTime
VehicleMonitoringRef[1] : MonitoringCode
ProgressBetweenStops[0..1] : ProgressBetweenStops
MonitoredVehicleJourney[1] : MonitoredVehicleJourney
VehicleActivityNote[0..*] : populatedString
Extensions[0..1] : any
0..1
1
VehicleActivityCancellation
0..*
0..1
VehicleMonitoringRef[1] : VehicleMonitor
VehicleJourneyRef[1] : FramedVehicleJourneyRef
LineRef[1] : LineCode
DirectionRef[1] : DirectionCode
JourneyPatternInfo[0..1] : JourneyPatternInfo
Reason[0..1] : populatedString
Extensions[0..1] : any
cancels
journey
1
TM-Mdl::DataFrame
1
0..1
frame
journey
journey
1
TM-Mdl::DatedVehicleJourney
0..1
0..*
LinkDistance[0..1] : decimal
Percentage[0..1] : decimal
location0..1
1
0..1
0..*
VM-Mdl::ProgressBetweenStops
Loc Mdl::Location
0..1
0..*
VM-Mdl::VehicleMonitor
«group»
Siri Mdl::FramedVehicleJourneyRef
1
0..*
journey
1
0..1
MonitoredVehicleJourneyIdentity[1] : MonitoredJourneyIdentity
JourneyPatternInfo[1] : JourneyPatternInfo
VehicleJourneyInfo[1] : VehicleJourneyInfo
DisruptionInfo[0..1] : DisruptionInfo
JourneyProgress[0..1] : ProgressInfo
TrainBlockPart[0..1] : TrainBlockPart
OperationalInfo[0..1] : OperationalInfo
PreviousCalls[0..*] : PreviousCall
MonitoredCall[0..1] : MonitoredCall
OnwardCalls[0..*] : OnwardCall
IsCompleteCallSequence[0..1] : boolean
Extensions[0..1] : any
onward
current
previous
1
1
1
0..*
0..1
Siri Mdl::PreviousCall
Siri Mdl::OnwardCall
0..*
Siri Mdl::MonitoredCall
0..1
info
1
TM-Mdl::Line
0..1
«group»
Siri Mdl::ServiceInfo
0..1
0..1
operator
TM-Mdl::Operator
0..*
0..1
pattern
TM-Mdl::JourneyPattern
0..1
0..*
1
1
1
line
«group»
Siri Mdl::JourneyPatternInfo
operational
0..*
TM-Mdl::Direction
1
0..*
«group»
identity Siri Mdl::MonitoredJourneyIdentity
1..1
journey info
«group»
1
1
1
Siri Mdl::VehicleJourneyInfo
0..1
Siri Mdl::MonitoredVehicleJourney
pattern info
«group»
Siri Mdl::ProgressInfo
progress
0..*
direction
route
0..*
0..1
TM-Mdl::Route
0..1
«group»
Siri Mdl::OperationalInfo
block
0..*
1
disruption
0..1
TM-Mdl::Block
0..1
«group»
Siri Mdl::DisruptionInfo
situation
See Monitored
Vehicle Journey
Diagrams for
details
0..*
0..1
Siri Mdl::Situation
Figure 6-4 VehicleMonitoringDelivery - Detail
© Copyright Kizoom 2006-2007
Page 44
SIRI Functional Services - UML Diagrams
7. SIRI PRODUCTIONTIMETABLE (PT)
The SIRI Production Timetable Service transmits daily timetables that include any planned updates
that are known about at the time of transmission. The service is used typically to communicate
between Scheduling systems and AVMS systems, and also between AVMS systems and intelligent
clients of the AVMS system to distributed the latest timetables. The timetables exchanged should
cover all lines covered by the AVMS system. SIR-PT may be used in conjunction with the SIRI
Estimated Timetable service to provide a base timetable.
The SIRI Production Timetable Service is also used to transmit the planned interchanges between
journeys, including information about the linking of vehicle parts through the interchange, such as
whether passengers are able to remain seated in the vehicle.

The Request Topics allow a Consumer system to specify that only timetables for a specific
timetable version. Operator, line, or direction are to be returned.

The Delivery can include the times at stops, block and journey pattern information, and
information about available connections.
SIRI-PT: SUBSCRIPTION & REQUEST
PRODUCTIONTIMETABLEREQUEST SUMMARY
requestor
Participant
1
SubscriptionRequest
1
requestor
0..*
SIRI-PT Summary
ProductionTimetableSubscription
& ProductionTimetableRequest
requests
1
© 2007 SIRI
0..*
0..*
policies
ProductionTimetableSubscriptionRequest
ServiceRequest
1
0..1
1
request
1
ProductionTimetableSubscriptionPolicies
requests
0..*
1
policies
ProductionTimetableRequest
1
0..1
topics
1
TimetableVersion
version
0..*
line
0..1
Language[0..1]
IncrementalUpdates[0..1]
ProductionTimetableTopics
operator
Operator
ProductionTimetablePolicies
0..1
0..1
0..*
0..*
ValidityPeriod[0..1]
TimetableVersionRef[0..1]
OperatorRef[0..1]
LineRef[0..1]
DirectionRef[0..1]
period
1
0..1
0..1
direction 0..*
Line
Direction
0..1
ValidityPeriod
StartTime[1]
EndTime[1]
Figure 7-1 ProductionTimeTableRequest - Summary
© Copyright Kizoom 2006-2007
Page 45
SIRI Functional Services - UML Diagrams
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::SubscriptionContext
Siri Rqs::SubscriptionRequest
requestor
Siri Mdl::Participant
1
1
RequestTimestamp[1] : dateTime
Address[0..1] : EndPointAddress
RequestorRef[1] : Participant
MessageIdentifer[0..1] : MessageQualifier
ConsumerAddress[0..1] : EndPointAddress
SubscriptionFilterIdentifier[0..1] : nmtoken
SubscriptionContext[0..1] : SubscriptionContext
0..*
1
0..1
1
SIRI-PT
ProductionTimetableSubscription
& ProductionTimetableRequest
1
subscriber
© 2007 SIRI
requests
requestor
Siri Rqs::AbstractFunctionalSubscriptionRequest
SubscriberRef[1] : ParticipantCode
SubscriptionIdentifier[1] : SubscriptionCode
InitialTerminationTime[1] : dateTime
0..*
0..*
0..*
Siri Rqs::ServiceRequest
RequestContext[1] : RequestContext
RequestTimestamp[1] : dateTime
Address[1] : EndPointAddress
RequestorRef[1] : ParticipantCode
MessageIdentifer[1] : string
ProductionTimetableSubscriptionRequest
ProductionTimetableRequest[1] : ProductionTimetableRequest
ProductionTimetableSubscriptionPolicies[0..1] : ProductionTimetableSubscriptionPolicies
Extensions[0..1] : any
1
context
1
1
policies
1
request
requests
0..1
Siri Rqs::AbstractFunctionalServiceRequest
RequestTimestamp[1] : dateTime
MessageIdentifier[0..1] : MessageQualifier
Siri Rqs::RequestContext
0..*
0..1
1
ProductionTimetableSubscriptionPolicies
ProductionTimetableRequest
policies
ProductionTimetableTopics[0..1] : ProductionTimetableTopics
ProductionTimetablePolicies[0..1] : ProductionTimetablePolicies
Extensions[0..1] : any
topics
1
TM-Mdl::TimetableVersion
0..1
0..1
0..1
version
0..1
operator
ProductionTimetablePolicies
0..*
0..*
ValidityPeriod[0..1]
TimetableVersionRef[0..1] : TimetableVersionCode
OperatorRef[0..1] : OperatorCode
LineRef[0..1] : LineCode
DirectionRef[0..1] : DirectionCode
period
line
0..*
TM-Mdl::Line
1
0..*
0..1
0..1
directions
Language[0..1] : lang
IncrementalUpdates[0..1] : boolean
ProductionTimetableTopics
TM-Mdl::Operator
1
1
Siri Mdl::ValidityPeriod
0..*
direction
StartTime[1] : dateTime
EndTime[1] : dateTime
TM-Mdl::Direction
0..1
Figure 7-2 ProductionTimetableRequest - Detail
© Copyright Kizoom 2006-2007
Page 46
SIRI Functional Services - UML Diagrams
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.
0..*
1
producer
ProducerResponse
SIRI - PT Summary
ProductionTimetableDelivery
Participant
© 2006 SIRI
errors
deliveries 1
ErrorCondition
ServiceDelivery
Operator
0..1
operator
0..*
TimetableVersion
VehicleFeature
0..*
Line
0..*
0..1category
version
DatedTimetableVersionFrame
directions
0..1 feature 0..*
0..1
1
line
ProductCategory
VersionRef[0..1]
LineRef[1]
0..*
DirectionRef[1]
JourneyPatternInfo[0..1]
1
ServiceInfo[0..1]
DatedVehicleJourneyInfo[0..1]
Extensions[0..1]
pattern
1
0..*
0..*
Direction
0..*
«group»
JourneyPatternInfo
stops JourneyPatternRef[0..1]
VehicleMode[0..1]
RouteRef[0..1]
PublishedLineName[0..1]
DirectionName[0..1]
ExternalLineRef[0..1]
0..1
0..1 service
1
0..*
TargetedInterchange
DatedCall
stop point
call arrival
CourseOfJourney
1
2..*
mode
0..*
0..1
1
0..1
journey info
calls
0..1
«group»
StopPointInSequence
StopPointRef[1]
VisitNumber[0..1]
Order[0..1]
StopPointName[0..1]
DatedVehicleJourneyCode[0..1]
VehicleJourneyRef[0..1]
ExtraJourney[0..1]
0..*
Cancellation[0..1]
JourneyPatternInfo[0..1]
ServiceInfo[0..1]
VehicleJourneyNote[0..1]
1
JourneyNote[0..1]
BlockRef[0..1]
run
CourseOfJourneyRef[0..1]
0..*
Calls[0..*]
Extensions[0..1]
0..1
0..1
Route
2..*
0..1
block
DatedVehicleJourney
Mode
0..* route
«group»
ServiceInfo
OperatorRef[0..1]
ProductCategoryRef[0..1]
ServiceFeatureRef[0..*]
VehicleFeatureRef[0..*]
Block
0..*
0..1
pattern
0..1
feature
0..*
VehicleJourney
«group»
DatedVehicleJourneyInfo
DestinationDisplay[0..1]
LineNote[0..1]
HeadwayService[0..1]
Monitored[0..1]
pattern
JourneyPattern
0..*
journeys
0..1
1
0..*
timetables
ProductionTimetableDelivery
1
ServiceFeature
0..1
1
StopPointInSequence[1]
CallInfo[0..1]
CallNote[0..1]
FacilityChange[0..1]
AimedArrivalInfo[0..1]
AimedDepartureInfo[0..1]
AimedHeadwayInterval[0..1]
Extensions[0..1]
1
0..1
connection
1
0..*
call departure
1 call 1
0..1
InterchangeCode[0..1]
DistributorVehicleJourneyRef[1]
DistributorConnectionLinkRef[0..1]
DistributorConnectionLink[0..1]
DistributorVisitNumber[0..1]
DistributorOrder[0..1]
StaySeated[0..1]
Guaranteed[0..1]
Advertised[0..1]
MaximumWaitTime[0..1]
Extensions[0..1]
1
0..1
0..*
0..*
at
«group»
CallInfo
TimingPoint[0..1]
BoardingStretch[0..1]
RequestStop[0..1]
DestinationDisplay[0..1]
«group»
AimedArrivalInfo
AimedArrivalTime[0..1]
ArrivalPlatformName[0..1]
ArrivalBoardingActivity[0..1]
«group»
AimedDepartureInfo
AimedDepartureTime[0..1]
DeparturePlatformName[0..1]
DepartureBoardingActivity[0..1]
connection link
0..1
1
StopPoint
«enumeration»
ArrivalActivityEnum
alighting
noAlighting
passThru
0..1
«enumeration»
DepartureActivityEnum
boarding
noBoarding
passThru
ref
0..1
ConnectionLink
to stop
0..*
ConnectionLinkCode[0..1]
StopPointRef[0..1]
StopPointName[0..1]
DefaultDuration[0..1]
FrequentTravellerDuration[0..1]
OccasionalTravellerDuration[0..1]
ImpairedAccessDuration[0..1]
Figure 7-3 ProductionTimetableDelivery - Summary
© Copyright Kizoom 2006-2007
Page 47
SIRI Functional Services - UML Diagrams
PRODUCTIONTIMETABLEDELIVERY DETAIL
Figure 7-4 shows attribute types for a ProductionTimetableDelivery as well.
1
Participant
ProducerResponse
1
AbstractServiceDelivery
1
ResponseTimeStamp[1] : dateTime
RequestMesageRef[0..1] : MessageQualifier
SubscriberRef[0..1] : ParticipantCode
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
SubscriptionRef[0..1] : SubscriptionCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
ValidUntil[0..1] : dateTime
ShortestPossibleCycle[0..1] : positiveDuration
1
ResponseTimeStamp[1] : dateTime
ProducerRef[0..1] : ParticipantCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
RequestMessageRef[0..1] : MessageQualifier
SIRI -PT
ProductionTimetableDelivery
0..1
© 2006 SIRI
ServiceDelivery
1
1
ErrorCondition
Error[1] : AbstractError
Description[1] : ErrorDescription
0..1Status[0..1] : boolean
ErrorCondition[1] : ErrorCondition
MoreData[1] : boolean
1
0..*
JourneyPattern
Mode
1
AbstractItem
TimetableVersion
0..1
1
ProductionTimetableDelivery
0..1
DatedTimetableVersionFrame
default
1
1
0..1
ServiceInfo
OperatorRef[0..1] : OperatorCode
ProductCategoryRef[0..1] : ProductCategoryCode
ServiceFeatureRef[0..*] : ServiceFeatureCode
VehicleFeatureRef[0..*] : VehicleFeatureCode
0..1
VehicleJourney
journeys
1
0..1
DestinationDisplay[0..1] : populatedString
DatedVehicleJourneyCode[0..1] : DatedVehicleJourneyCode
0..1
info LineNote[0..1] : populatedString
journey
VehicleJourneyRef[0..1] : VehicleJourneyCode
HeadwayService[0..1] : boolean
ExtraJourney[0..1] : boolean
1
Monitored[0..1] : boolean
Cancellation[0..1] : boolean
0..1
JourneyPatternInfo[0..1] : JourneyPatternInfo
ServiceInfo[0..1] : ServiceInfo
pattern
1
VehicleJourneyNote[0..1] : populatedString
JourneyNote[0..1] : populatedString
BlockRef[1] : BlockCode
StopPointInSequence
1 stop point
CourseOfJourneyRef[1] : CourseOfJourneyCode
StopPointRef[1] : StopPointCode
Extensions[0..1] : any
VisitNumber[0..1] : VisitNumber
1
Order[0..1] : positiveInteger
0..1
1
1
StopPointName[0..1] : populatedString
calls
run
1
block
0..1
Block
DatedCall
0..1
CourseOfJourney 0..1
call 2..*1
CallInfo
TimingPoint[0..1] : boolean
BoardingStretch[0..1] : boolean
RequestStop[0..1] : boolean
DestinationDisplay[0..1] : populatedString
0..1stops
DatedVehicleJourneyInfo
DatedVehicleJourney
0..*
1
JourneyPatternRef[0..1] : JourneyPatternCode
VehicleMode[0..1] : VehicleModesEnum
RouteRef[0..1] : RouteCode
PublishedLineName[0..1] : populatedString
DirectionName[0..1] : populatedString
ExternalLineRef[0..1] : LineCode
default
1
1
0..1
JourneyPatternInfo
default
0..*
VersionRef[0..1] : TimetableVersionCode
LineRef[1] : LineCode
DirectionRef[1] : DirectionCode
JourneyPatternInfo[0..1] : JourneyPatternInfo
ServiceInfo[0..1] : ServiceInfo
DatedVehicleJourneyInfo[0..1] : DatedVehicleJourneyInfo
Extensions[0..1] : any
1
1
1
0..1
Route
0..1
version[1] : VersionString
Extensions[0..1] : any
timetables
-RecordedAtTime[1] : dateTime
TargetedInterchange
StopPoint
1
1
0..1
0..1
AimedArrivalInfo
StopPointInSequence[1] : StopPointInSequence
CallInfo[0..1] : CallInfo
CallNote[0..1] : populatedString
FacilityChange[0..1] : FacilityChange
AimedArrivalInfo[0..1] : AimedArrivalInfo
AimedDepartureInfo[0..1] : AimedDepartureInfo
AimedHeadwayInterval[0..1] : positiveDuration
Extensions[0..1] : any
InterchangeCode[0..1] : InterchangeCode
DistributorVehicleJourneyRef[1] : DatedVehicleJourneyCode
DistributorConnectionLinkRef[0..1] : ConnectionLinkCode
DistributorConnectionLink[0..1] : ConnectionLink
DistributorVisitNumber[0..1] : VisitNumber
DistributorOrder[0..1] : positiveInteger
StaySeated[0..1] : boolean
Guaranteed[0..1] : boolean
Advertised[0..1] : boolean
MaximumWaitTime[0..1] : positiveDuration
Extensions[0..1] : any
2..*
AimedArrivalTime[0..1] : dateTime
ArrivalPlatformName[0..1] : populatedString
ArrivalBoardingActivity[0..1] : ArrivalActivityEnum
1
to stop
1
0..1
1
AimedDepartureInfo
AimedDepartureTime[0..1] : dateTime
DeparturePlatformName[0..1] : populatedString
DepartureBoardingActivity[0..1] : DepartureActivityEnum
connection
0..*
ConnectionLink
ref
1{OR}
0..1
0..1
ConnectionLinkCode[0..1] : ConnectionLinkCode
StopPointRef[0..1] : StopPointCode
StopPointName[0..1] : populatedString
DefaultDuration[0..1] : positiveDuration
FrequentTravellerDuration[0..1] : positiveDuration
OccasionalTravellerDuration[0..1] : positiveDuration
ImpairedAccessDuration[0..1] : positiveDuration
1
1
Figure 7-4 ProductionTimetableDelivery - Detail
© Copyright Kizoom 2006-2007
Page 48
SIRI Functional Services - UML Diagrams
8. SIRI ESTIMATEDTIMETABLE (ET)
The SIRI Estimated Timetable service is used by an AVMS or real-time hub to inform interested
systems of the current status of all known vehicle journeys. This enables schedule information
systems to provide up-to-the-minute information for short-term journey planning. It can also be used
to support intelligent displays that calculate the deviations from the timetables themselves using a
timetable and a real time difference delay by the SIRI Stop Monitoring Service. A further use is the
historic logging of changes to journey times. It can be used to exchange changes to a timetable
established by the SIRI Production timetable service.

The Request Topics allow a Consumer system to specify that only timetables for a specific
timetable version. Operator, Line, or Direction are to be returned.

The Subscription Policies allow a subscriber to specify the amount of change to allow before
sending an update.

The Delivery returns predicted real-time changes to the timetable.
SIRI-ET: SUBSCRIPTION & REQUEST
ESTIMATEDTIMETABLEREQUEST SUMMARY
requestor
subscriptions
1
SubscriptionRequest
0..*
1
Participant
*
1
policies
requestor
EstimatedTimetableSubscriptionRequest
1
0..*
0..1
1
request
ServiceRequest
EstimatedTimetableSubscriptionPolicies
requests
IncrementalUpdates[0..1]
ChangeBeforeUpdate[0..1]
1
0..*
*
policies
SIRI-ET Summary
EstimatedTimeTableSubscription
& EstimatedTimeTableRequest
EstimatedTimetableRequest
0..1
1
1
© 2006 SIRI
EstimatedTimetablePolicies
topics
Language[0..1]
0..*
0..1
0..*
version
TimetableVersion
0..*
0..1
operator
Operator
line
EstimatedTimetableTopics
PreviewInterval[0..1]
TimetableVersionRef[0..1]
OperatorRef[0..1]
LineRef[0..1]
DirectionRef[0..1]
Line
0..1
0..*
direction
0..*
Direction
0..1
Figure 8-1 EstimatedTimetableRequest - Summary
© Copyright Kizoom 2006-2007
Page 49
SIRI Functional Services - UML Diagrams
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.
Siri Rqs::SubscriptionRequest
requestor
0..*
1
Siri Mdl::Participant
1
1
Siri Rqs::SubscriptionContext
HeartbeatInterval[0..1] : duration
0..1
1
subscriptions
1
Siri Rqs::AbstractFunctionalSubscriptionRequest
subscriber
requestor
context
RequestTimestamp[1] : dateTime
Address[0..1] : EndPointAddress
RequestorRef[1] : Participant
MessageIdentifer[0..1] : MessageQualifier
ConsumerAddress[0..1] : EndPointAddress
SubscriptionFilterIdentifier[0..1] : nmtoken
SubscriptionContext[0..1] : SubscriptionContext
SubscriberRef[1] : ParticipantCode
SubscriptionIdentifier[1] : SubscriptionCode
InitialTerminationTime[1] : dateTime
0..*
*
EstimatedTimetableSubscriptionRequest
0..*
EstimatedTimetableRequest[1] : EstimatedTimetableRequest
EstimatedTimetableSubscriptionPolicies[0..1] : EstimatedTimetableSubscriptionPolicies
Extensions[0..1] : any
Siri Rqs::ServiceRequest
RequestContext[1] : RequestContext
RequestTimestamp[1] : dateTime
Address[1] : EndPointAddress
RequestorRef[1] : ParticipantCode
MessageIdentifer[1] : string
requests
1policies
0..1
EstimatedTimetableSubscriptionPolicies
0..1
request
1
IncrementalUpdates[0..1] : boolean
ChangeBeforeUpdate[0..1] : duration
context
1
Siri Rqs::AbstractFunctionalServiceRequest
RequestTimestamp[1] : dateTime
MessageIdentifier[0..1] : MessageQualifier
0..*
0..1
Siri Rqs::RequestContext
1
policies
EstimatedTimetableRequest
EstimatedTimetableTopics[0..1] : EstimatedTimetableTopics
EstimatedTimetablePolicies[0..1] : ProductionTimetablePolicies
Extensions[0..1] : any
1
version
TM-Mdl::TimetableVersion
1
0..*
0..1
0..1
0..1
operator
EstimatedTimetableTopics
line
PreviewInterval[0..1] : duration
TimetableVersionRef[0..1] : TimetableVersionCode
OperatorRef[0..1] : OperatorCode
LineRef[0..1] : LineCode
DirectionRef[0..1] : DirectionCode
TM-Mdl::Operator
0..*
0..1
TM-Mdl::Line
topics
directions
0..1
0..*
1
0..*
0..*
direction
EstimatedTimetablePolicies
Language[0..1] : lang
SIRI-ET
EstimatedTimeTableSubscription
& EstimatedTimeTableRequest
© 2006 SIRI
TM-Mdl::Direction
0..1
Figure 8-2 EstimatedTimetableRequest - Detail
SIRI-ET: DELIVERY
© Copyright Kizoom 2006-2007
Page 50
SIRI Functional Services - UML Diagrams
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..*
1
producer
ProducerResponse
SIRI-PT - Summary
EstimatedTimeTableDelivery
Participant
© 2006 SIRI
errors
ServiceDelivery
ErrorCondition
1
deliveries
1
0..1
Operator
feature
ServiceFeature
operator
0..*
0..1
0..* 0..1
0..*
EstimatedTimetableDelivery
service
0..1
1
0..*
0..1
journeys
EstimatedJourneyVersionFrame
line
0..*
direction
0..*
1
0..1
0..*
Line
0..1pattern info 1
«group»
JourneyPatternInfo
JourneyPatternRef[0..1]
VehicleMode[0..1]
RouteRef[0..1]
PublishedLineName[0..1]
DirectionName[0..1]
ExternalLineRef[0..1]
1
mode
0..*
between
0..1
route
Mode
0..1
0..1
0..*
1
at
«group»
DatedVehicleJourneyIndirectRef
OriginRef[1]
AimedDepartureTime[1]
DestinationRef[1]
AimedArrivalTime[1]
0..*
1
2..*
«enumeration»
ArrivalActivityEnum
alighting
noAlighting
passThru
«group»
OperationalInfo
BlockRef[0..1]
CourseOfJourneyRef[0..1]
VehicleRef[0..1]
«group»
StopPointInSequence
StopPointRef[1]
VisitNumber[0..1]
Order[0..1]
StopPointName[0..1]
«group»
ArrivalInfo
ArrivalStatus[0..1]
ArrivalPlatformName[0..1]
ArrivalBoardingActivity[0..1]
0..1
«group»
AimedArrivalTimes
AimedArrivalTime[0..1]
ExpectedArrivalTime[0..1]
0..1 0..*
0..*
0..1
*
vehicle
CourseOfJourney
0..1
1
Vehicle
disruption
1
0..1
call info
«group»
DisruptionInfo
SituationRef[0..1]
FacilityChange[0..1]
«group»
CallInfo
TimingPoint[0..1]
BoardingStretch[0..1]
RequestStop[0..1]
DestinationDisplay[0..1]
0..1
1
0..*
0..*
Block
0..1 runs
run
1
operational info
calls
1
StopPoint
0..1
block
LineRef[1]
DirectionRef[1]
DatedVehicleJourneyRef[0..1]
DatedVehicleJourneyIndirectRef[0..1]
EstimatedVehicleJourneyCode[0..1]
ExtraJourney[0..1]
Cancellation[0..1]
JourneyPatternInfo[0..1]
ServiceInfo[0..1]
VehicleJourneyName[0..1]
JourneyNote[0..1]
HeadwayService[0..1]
DisruptionInfo[0..1]
Monitored[0..1]
PredictionInaccurate[0..1]
Occupancy[0..1]
OperationalInfo[0..1]
EstimatedCalls[2..*]
IsCompleteStopSequence[0..1]
Extensions[0..1]
Route
from
0..1
0..*
ProductCategory
1
EstimatedVehicleJourney
Direction
0..1
pattern
stops
feature
category
10..*
JourneyPattern
0..*
VehicleFeature
0..*
VersionRef[0..1]
Extensions[0..1]
1
«group»
ServiceInfo
OperatorRef[0..1]
ProductCategoryRef[0..1]
ServiceFeatureRef[0..*]
VehicleFeatureRef[0..*]
TimetableVersion
Association1
1 delivery
EstimatedCall
StopPointInSequence[0..1]
ExtraCall[0..1]
Cancellation[0..1]
stop
CallInfo[0..1]
DestinationDisplay[0..1]
CallNote[0..1]
FacilityChange[0..1]
AimedArrivalTimes[0..1]
1
ArrivalInfo[0..1]
AimedDepartureTimes[0..1]
DepartureInfo[0..1]
0..1 arrival HeadwayInterval[0..1]
Extensions[0..1]
0..*
1
1
departure info
«enumeration»
DepartureActivityEnum
boarding
noBoarding
passThru
1
0..1
«group»
DepartureInfo
DepartureStatus[0..1]
DeparturePlatformName[0..1]
DepartureBoardingActivity[0..1]
1headway
1
departure times
arrival times
0..1
0..1
«group»HeadwayInfo
AimedHeadWayInterval[0..1]
ExpectedHeadwayInterval[0..1]
«group»
AimedDepartureTimes
AimedDepartureTime[0..1]
ExpectedDepartureTime[0..1]
«enumeration»
TimeStatusEnum
early
onTime
delayed
arrived
cancelled
noReport
Figure 8-3 EstimatedTimetableDelivery - Summary
© Copyright Kizoom 2006-2007
Page 51
SIRI Functional Services - UML Diagrams
ESTIMATEDTIMETABLEDELIVERY DETAIL
Figure 7-4 shows the detailed attributes of an EstimatedTimetableDelivery.
SIRI-PT
EstimatedTimeTableDelivery
Siri Rqs::ProducerResponse
Siri Mdl::Participant
© 2006 SIRI
ResponseTimeStamp[1] : dateTime
ProducerRef[0..1] : ParticipantCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
RequestMessageRef[0..1] : MessageQualifier
1
producer
0..1
Siri Rqs::AbstractFunctionalServiceDelivery
0..*
0..* subscriber
ResponseTimeStamp[1] : dateTime
RequestMessageRef[0..1] : MessageQualifier
SubscriberRef[0..1] : ParticipantCode
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
errors
Siri Rqs::ErrorCondition
SubscriptionRef[0..1] : SubscriptionCode
-Error : AbstractError
Address[0..1] : EndPointAddress
1
-Description : ErrorDescription
ResponseMessageIdentifier[0..1] : MessageQualifier
0..1
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
0..*
ValidUntil[0..1] : dateTime
ShortestPossibleCycle[0..1] : positiveDuration
EstimatedTimetableDelivery
TM-Mdl::TimetableVersion
-RecordedAtTime : dateTime
0..*
Siri Rqs::ServiceDelivery
1
delivery
TM-Mdl::Mode
-Status : boolean
-ErrorCondition : ErrorCondition
-MoreData : boolean
1
deliveries
0..*
0..1
TM-Mdl::Route
0..*
0..1
«group»Siri Mdl::JourneyPatternInfo
JourneyPatternRef[0..1] : JourneyPatternCode
VehicleMode[0..1] : Mode
RouteRef[0..1] : RouteCode
PublishedLineName[0..1] : populatedString
DirectionName[0..1] : populatedString
ExternalLineRef[0..1] : LineCode
version[1] : versionString
Extensions[0..1] : any
Siri Rqs::AbstractItem
0..11
1
errors
0..1
0..1
pattern
0..*
0..1
ET-Mdl::EstimatedJourneyVersionFrame
1
VersionRef[0..1] : TimetableVersionCode
Extensions[0..1] : any
1
1
0..*
TM-Mdl::Line
TM-Mdl::Direction
0..*
0..1
TM-Mdl::JourneyPattern
pattern info
0..*
0..*
1
0..1
service
1
«group»Siri Mdl::ServiceInfo
OperatorRef[0..1] : OperatorCode
ProductCategoryRef[0..1] : ProductCategoryCode
ServiceFeatureRef[0..*] : ServiceFeatureCode
VehicleFeatureRef[0..*] : VehicleFeatureCode
ET-Mdl::EstimatedVehicleJourney
0..*
LineRef[1] : LineCode
DirectionRef[1] : DirectionCode
DatedVehicleJourneyRef[0..1] : DatedVehicleJourneyCode
DatedVehicleJourneyIndirectRef[0..1] : DatedVehicleJourneyIndirectRef
EstimatedVehicleJourneyCode[0..1] : EstimatedVehicleJourney
ExtraJourney[0..1] : boolean
Cancellation[0..1] : boolean
JourneyPatternInfo[0..1] : JourneyPatternInfo
ServiceInfo[0..1] : ServiceInfo
VehicleJourneyName[0..1] : populatedString
JourneyNote[0..1] : populatedString
HeadwayService[0..1] : boolean
DisruptionInfo[0..1] : DisruptionInfo
Monitored[0..1] : boolean
PredictionInaccurate[0..1] : boolean
Occupancy[0..1] : OccupancyEnum
OperationalInfo[0..1] : OperationalInfo
EstimatedCalls[2..*] : EstimatedCall
IsCompleteStopSequence[0..1] : boolean
Extensions[0..1] : any
1
TM-Mdl::Block
operational info
1
0..*
run
0..1
0..1
1
0..*
from
0..1
«group»
Siri Mdl::DatedVehicleJourneyIndirectRef
OriginRef[1] : StopPointCode
AimedDepartureTime[1] : dateTime
DestinationRef[1] : StopPointCode
AimedArrivalTime[1] : dateTime
1
1
1
0..*
TM-Mdl::StopPoint
stop
1
SituationRef[0..1] : SituationCode
FacilityChange[0..1] : FacilityChange
0..*
1
0..1
situation
0..*
0..1
Siri Mdl::Situation
«group»
Siri Mdl::AimedArrivalTimes
-AimedArrivalTime : dateTime
-ExpectedArrivalTime : dateTime
«enumeration»
Siri Enm::TimeStatusEnum
early
onTime
delayed
arrived
cancelled
noReport
1
TM-Mdl::Operator
0..*
stops
vehicle
TM-Mdl::CourseOfJourney
ET-Mdl::EstimatedCall
calls
1
BlockRef[0..1] : BlockCode
CourseOfJourneyRef[0..1] : CourseOfJourneyCode
VehicleRef[0..1] : VehicleCode
1
«group»Siri Mdl::DisruptionInfo
0..1
0..*
«group»Siri Mdl::OperationalInfo
0..*
0..1
block
0..*
0..1
operator
StopPointInSequence[0..1] : StopPointInSequence
ExtraCall[0..1] : boolean
Cancellation[0..1] : boolean
CallInfo[0..1] : CallInfo
DestinationDisplay[0..1] : populatedString
CallNote[0..1] : populatedString
FacilityChange[0..1] : FacilityChange
AimedArrivalTimes[0..1] : ArrivalTimes
ArrivalInfo[0..1] : ArrivalInfo
0..1
AimedDepartureTimes[0..1] : DatedVehicleJourneyIndirectRef
DepartureInfo[0..1] : DepartureInfo
HeadwayInterval[0..1] : HeadwayInfo
Extensions[0..1] : any
«group»Siri Mdl::ArrivalInfo
ArrivalStatus[0..1] : TimeStatusEnum
ArrivalPlatformName[0..1] : populatedString
ArrivalBoardingActivity[0..1] : ArrivalActivityEnum
TM-Mdl::Vehicle
«group»
TM-Mdl::StopPointInSequence
StopPointRef[1] : StopPointCode
VisitNumber[0..1] : VisitNumber
Order[0..1] : positiveInteger
StopPointName[0..1] : populatedString
2..*
«group»Siri Mdl::CallInfo
1 0..1
1
TimingPoint[0..1] : boolean
BoardingStretch[0..1] : boolean
RequestStop[0..1] : boolean
DestinationDisplay[0..1] : populatedString
«group»Siri Mdl::HeadwayInfo
AimedHeadWayInterval[0..1] : positiveDuration
ExpectedHeadwayInterval[0..1] : positiveDuration
1
0..1
0..1
0..1
«group»
Siri Mdl::AimedDepartureTimes
AimedDepartureTime[0..1] : dateTime
ExpectedDepartureTime[0..1] : dateTime
1
departure info
«group»Siri Mdl::DepartureInfo
0..1
DepartureStatus[0..1] : TimeStatusEnum
DeparturePlatformName[0..1] : populatedString
DepartureBoardingActivity[0..1] : DepartureActivityEnum
Figure 8-4 EstimatedTimetableDelivery - Detail
© Copyright Kizoom 2006-2007
Page 52
SIRI Functional Services - UML Diagrams
9. SIRI STOP TIMETABLE (ST)
The SIRI Stop Timetable Service provides a timetabled for vehicle arrivals and departures at a
designated stop. It can be used to reduce the amount of information that needs to be transmitted in
real-time to stops and displays, as reference data for a Stop Monitoring Service; and provides a data
feed of the static timetables.

The Request Topics allow a Consumer system to specify that only stop timetables for a
specific monitoring point, line, or direction are to be returned.

The Delivery returns departures from the stop for a specified window.
SIRI-ST: SUBSCRIPTION & REQUEST
STOPTIMETABLEREQUEST SUMMARY
requestor
Participant
1
requestor
1
0..*
requests
SubscriptionRequest
0..*
0..*
1
request
ServiceRequest
SIRI-ST Summary
StopTimetableSubscription
& StopTimetableRequest
1
© 2007 SIRI
StopTimetableSubscriptionRequest
policies
1
1
1
requests
StopTimetableSubscriptionPolicies
policies
0..1
0..1
StopTimetableRequest
1
0..*
StopTimetablePolicies
1
Language[0..1] : lang
line
topics
0..1
monitor
Monitor
Line
StopTimetableTopics
0..*
0..1
-MonitoringWindow[0..1]
-MonitoringRef[0..1]
-LineRef[0..1]
-DirectionRef[0..1]
0..*
direction
0..1
Direction
0..*
0..1
Figure 9-1 StopTimetableRequest - Summary
© Copyright Kizoom 2006-2007
Page 53
SIRI Functional Services - UML Diagrams
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.
Other criteria that can be used to filter results include Line (e.g. ‘N45’), Direction, Operator and
Destination.
Siri Rqs::SubscriptionRequest
requestor
0..*
1
Siri Mdl::Participant
subscriber
Siri Rqs::SubscriptionContext
1 0..1
1
0..*
1
1
context
RequestTimestamp[1] : dateTime
Address[0..1] : EndPointAddress
RequestorRef[1] : Participant
MessageIdentifer[0..1] : MessageQualifier
ConsumerAddress[0..1] : EndPointAddress
SubscriptionFilterIdentifier[0..1] : nmtoken
SubscriptionContext[0..1] : SubscriptionContext
requests
Siri Rqs::AbstractFunctionalSubscriptionRequest
SubscriberRef[1] : ParticipantCode
SubscriptionIdentifier[1] : SubscriptionCode
InitialTerminationTime[1] : dateTime
requestor
0..*
0..*
StopTimetableSubscriptionRequest
Siri Rqs::ServiceRequest
RequestContext[1] : RequestContext
RequestTimestamp[1] : dateTime
Address[1] : EndPointAddress
RequestorRef[1] : ParticipantCode
MessageIdentifer[1] : string
context
1
1..1
StopTimetableRequest[1] : StopTimetableRequest
StopTimetableSubscriptionPolicies[0..1] : StopTimetableSubscriptionPolicies
Extensions[0..1] : any
requests
1
request1
policies
Siri Rqs::AbstractFunctionalServiceRequest
RequestTimestamp[1] : dateTime
MessageIdentifier[0..1] : MessageQualifier
0..*
1
0..1
1
Siri Rqs::RequestContext
StopTimetableSubscriptionPolicies
StopTimetableRequest
StopTimetableTopics[0..1] : StopTimetableTopics
StopTimetablePolicies[0..1] : StopTimetablePolicies
Extensions[0..1] : any
topics
0..1
1
policies
1
StopTimetableTopics
monitor
0..1
0..*
StopTimetablePolicies
MonitoringWindow[0..1] : HalfOpenTimestampRange
MonitoringRef[0..1] : MonitoringCode
LineRef[0..1] : LineCode
DirectionRef[0..1] : DirectionCode
Language[0..1] : lang
direction
0..*
0..*
0..1
line
directions
Siri Mdl::Monitor
TM-Mdl::Line
0..1
0..1
SIRI-ST
StopTimetableSubscription
& StopTimetableRequest
© 2007 SIRI
TM-Mdl::Direction
1
0..*
Figure 9-2 StopTimetableRequest - Detail
© Copyright Kizoom 2006-2007
Page 54
SIRI Functional Services - UML Diagrams
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 TargetedVehicleJourney with a TargetedCall at the stop with passing times.
STOPTIMETABLEDELIVERY SUMMARY
SIRI-ST Summary
StopTimetableDelivery
ProducerResponse
© 2006 SIRI
errors
ServiceDelivery
ErrorCondition
1
0..1
1
deliveries
cancellations
TimetabledStopVisitCancellation
cancels
MonitoringRef[1]
VisitNumber[0..1]
VehicleJourneyIdentity[1]
JourneyPatternInfo[0..1]
Extensions[0..1]
StopTimetableDelivery
0..*
0..*
1
1
1
visits
MonitoringRef[1]
TargetedVehicleJourney[1]
Extensions[1]
*
«enumeration»
VehicleModesEnum
air
bus
coach
ferry
metro
rail
tram
underground
line
VehicleJourneyIdentity[1]
JourneyPatternInfo[0..*]
VehicleJourneyInfo[0..1]
MonitoringRef[0..1]
Extensions[0..1]
route
0..*
Monitor
monitor
0..*
destination0..*
«group»
StopPointInSequence
StopPointRef[1]
VisitNumber[0..1]
Order[0..1]
StopPointName[0..1]
0..1
0..1
0..*
at
stop
0..1
origin
0..*
TargetedCall
StopPointRef[0..1]
VisitNumber[1]
Order[0..1]
TimingPoint[0..1]
ServiceInfo[0..1]
AimedArrivalInfo[0..1]
AimedDepartureInfo[0..1]
AimedHeadwayInterval[0..1]
Extensions[0..1]
Mode
arrival1 info
0..*
info
1
1
departure info
«group»
AimedArrivalInfo
AimedArrivalTime[0..1]
ArrivalPlatformName[0..1]
ArrivalBoardingActivity[0..1]
«enumeration»
ArrivalActivityEnum
alighting
noAlighting
passThru
«group»
VehicleJourneyInfo
ServiceInfo[0..1]
OriginRef[0..1]
DestinationName[0..1]
OriginShortName[0..1]
Via[0..*]
DestinationRef[0..1]
DestinationName[0..1]
DestinationShortName[0..1]
VehicleJourneyNote[0..1]
JourneyNote[0..1]
HeadwayService[0..1]
OriginAimedDepartureTime[0..1]
DestinationAimedDepartureTime[0..1]
1
service info
0..*
0..1
0..1
0..1
StopPoint
0..1
monitoring point
«group»
VehicleJourneyIdentity
LineRef[1]
DirectionRef[1]
FramedVehicleJourneyRef[0..1]
1
1
0..* mode
1
1
0..1
Line
calls
0..*
0..*
0..1
1
«group»
JourneyPatternInfo
JourneyPatternRef[0..1]
VehicleMode[0..1]
RouteRef[0..1]
PublishedLineName[0..1]
DirectionName[0..1]
ExternalLineRef[0..1]
1
journey
1
TargetedVehicleJourney
pattern0..1
2..*
journey
1
JourneyPattern
stops
«group»
FramedVehicleJourneyRef
DataFrameRef[1]
DatedVehicleJourneyRef[1]
identity
1
Route
0..1
for
0..*
DataFrame
1
1
1
0..1 frame
TimetabledStopVisit
0..1
0..1
operator
0..*
0..*
0..*
Operator
0..1
feature
«group»
ServiceInfo
OperatorRef[0..1]
ProductCategoryRef[0..1]
ServiceFeatureRef[0..*]
VehicleFeatureRef[0..*]
0..1
0..*
ServiceFeature
feature
VehicleFeature
0..1
category
0..1
ProductCategory
0..1
«group»
AimedDepartureInfo
AimedDepartureTime[0..1]
DeparturePlatformName[0..1]
DepartureBoardingActivity[0..1]
«enumeration»
DepartureActivityEnum
boarding
noBoarding
passThru
Figure 9-3 StopTimetableDelivery - Summary
© Copyright Kizoom 2006-2007
Page 55
SIRI Functional Services - UML Diagrams
STOPTIMETABLEDELIVERY DETAIL
Figure 9-4 Figure 7-4 shows attribute types for a StopTimetableDelivery as well.
Siri Rqs::ProducerResponse
SIRI-ST
StopTimetableDelivery
ResponseTimeStamp[1] : dateTime
ProducerRef[0..1] : ParticipantCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
RequestMessageRef[0..1] : MessageQualifier
producer
Siri Mdl::Participant
1
© 2006 SIRI
0..*
0..1
1
errors
Siri Rqs::AbstractFunctionalServiceDelivery
ResponseTimeStamp[1] : dateTime
RequestMessageRef[0..1] : MessageQualifier
SubscriberRef[0..1] : ParticipantCode
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
SubscriptionRef[0..1] : SubscriptionCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
ValidUntil[0..1] : dateTime
ShortestPossibleCycle[0..1] : positiveDuration
Siri Rqs::ServiceDelivery
subscriber
0..*
0..1
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
MoreData[1] : boolean
errors
Siri Rqs::ErrorCondition
1 0..1
Error[1] : AbstractError
Description[1] : ErrorDescription
1
deliveries
0..*
StopTimetableDelivery
-version[1] : versionString
-Extensions[0..1] : any
Siri Rqs::AbstractItem
1
RecordedAtTime[1] : dateTime
«enumeration»
Siri Enm::VehicleModesEnum
air
bus
coach
ferry
metro
rail
cancellations tram
underground
1
Siri Rqs::AbstractIdentifiedItem
Siri Rqs::AbstractReferencedItem
IdentifiedItemCode[0..1] : IdentifiedItemCode
IdentifiedItemRef[0..1] : IdentifiedItemCode
*
visits
cancels
1
TimetabledStopVisitCancellation
0..*
monitoring point
1
0..1
1
TimetabledStopVisit
MonitoringRef[1] : MonitoringCode
TargetedVehicleJourney[1] : TargetedVehicleJourney
Extensions[1] : any
0..*
1
ST-Mdl::Monitor
MonitoringRef[1] : MonitoringCode
VisitNumber[0..1] : VisitNumber
VehicleJourneyIdentity[1] : VehicleJourneyIdentity
JourneyPatternInfo[0..1] : JourneyPatternInfo
Extensions[0..1] : any
1
0..1
monitor 0..1
ST-Mdl::TargetedVehicleJourney
1
1
VehicleJourneyIdentity[1] : VehicleJourneyIdentity
JourneyPatternInfo[0..*] : JourneyPatternInfo
VehicleJourneyInfo[0..1] : VehicleJourneyInfo
MonitoringRef[0..1] : MonitoringCode
Extensions[0..1] : any
1
journey Info
vehicle
0..1
0..*
identity
«group»
Siri Mdl::FramedVehicleJourneyRef
pattern
«group»Siri Mdl::VehicleJourneyIdentity
LineRef[1] : LineCode
DirectionRef[1] : DirectionCode
10..1
line FramedVehicleJourneyRef[0..1] : FramedVehicleJourneyRef0..1
1
TM-Mdl::Line
1
0..1
ServiceInfo[0..1] : ServiceInfo
OriginRef[0..1] : JourneyPlaceCode
DestinationName[0..1] : populatedString
OriginShortName[0..1] : populatedString
1
Via[0..*] : populatedString
info
DestinationRef[0..1] : DestinationCode
DestinationName[0..1] : populatedString
DestinationShortName[0..1] : populatedString
VehicleJourneyNote[0..1] : populatedString
0..1
JourneyNote[0..1] : populatedString
HeadwayService[0..1] : boolean
OriginAimedDepartureTime[0..1] : dateTime
0..1
DestinationAimedDepartureTime[0..1] : dateTime
ST-Mdl::TargetedCall
«group»Siri Mdl::JourneyPatternInfo
journey pattern
TM-Mdl::JourneyPattern
0..1
pattern
0..*
0..1
0..*
route
TM-Mdl::Route
JourneyPatternRef[0..1] : JourneyPatternCode
VehicleMode[0..1] : Mode
RouteRef[0..1] : RouteCode
PublishedLineName[0..1] : populatedString
DirectionName[0..1] : populatedString
ExternalLineRef[0..1] : LineCode
operator
«group»Siri Mdl::ServiceInfo
OperatorRef[0..1] : OperatorCode
ProductCategoryRef[0..1] : ProductCategoryCode
ServiceFeatureRef[0..*] : ServiceFeatureCode
VehicleFeatureRef[0..*] : VehicleFeatureCode
service info
0..*
1
1
«group»Siri Mdl::VehicleJourneyInfo
calls
1
0..* category
TM-Mdl::Operator
feature 0..1
0..*
Siri Mdl::ServiceFeature
0..*
0..1
feature
0..*
Siri Mdl::VehicleFeature
Siri Mdl::ProductCategory
0..1
StopPointRef[0..1] : StopPointCode
«group»Siri Mdl::AimedArrivalInfo
VisitNumber[1] : VisitNumber
AimedArrivalTime[0..1] : dateTime
info
arrival
Order[0..1] : positiveInteger
1
ArrivalPlatformName[0..1] : populatedString
TimingPoint[0..1] : boolean
ArrivalBoardingActivity[0..1] : ArrivalActivityEnum
ServiceInfo[0..1] : ServiceInfo
0..1
1
AimedArrivalInfo[0..1] : AimedArrivalInfo
AimedDepartureInfo[0..1] : AimedDepartureInfodeparture info
«group»Siri Mdl::AimedDepartureInfo
AimedHeadwayInterval[0..1] : positiveDuration
1
AimedDepartureTime[0..1] : dateTime
Extensions[0..1] : any
0..1
: populatedString
DeparturePlatformName[0..1]
0..1 stop
DepartureBoardingActivity[0..1] : DepartureActivityEnum
0..*
TM-Mdl::StopPoint
0..1
«enumeration»
Siri Enm::ArrivalActivityEnum
alighting
noAlighting
passThru
«enumeration»
Siri Enm::DepartureActivityEnum
boarding
noBoarding
passThru
Figure 9-4 StopTimetableDelivery - Detail
© Copyright Kizoom 2006-2007
Page 56
SIRI Functional Services - UML Diagrams
10. SIRI CONNECTIONTIMETABLE (CT)
The SIRI Connection Timetable Service is used for the exchange of schedule data for potential feeder
vehicle journeys to a connection zone. It is normally used in conjunction with the SIRI Connection
Monitoring Service to establish the reference data of planned connections to be monitored by the
real time systems. The service is location-related, i.e. all requests and replies relate to specific
connection links, as identified by connection link identifiers.

The Topics allow a Consumer system to specify that only Connection Timetables for a specific
Connection Link, Line, or Line Direction or Vehicle are to be returned.

The Delivery returns planned connections as InterchangeJourneys
SIRI-CT: SUBSCRIPTION & REQUEST
CONNECTIONTIMETABLEREQUEST SUMMARY
requestor
SIRI-CT - Summary
ConnectionTimetableSubscription
& ConnectionTimetableRequest
© 2006 SIRI
Participant
0..*
1
1
requestor
requests
SubscriptionRequest
0..*
1
policies
0..*
ConnectionTimetableSubscriptionRequest
1
ServiceRequest
request
1
0..1
1
ConnectionTimetableSubscriptionPolicies
1
requests
policies
ConnectionTimetableRequest
0..*
1
1
0..1
ConnectionTimetablePolicies
Language[0..1]
topics
0..1
line
link
0..1
Line
ConnectionTimetableTopics
ConnectionLink
0..*
PreviewInterval[0..1]
ConnectionLinkRef[0..1]
LineRef[0..1]
DirectionRef[0..1]
0..*
0..1
direction
Direction
0..*
0..1
Figure 10-1 ConnectionTimetableRequest - Summary
© Copyright Kizoom 2006-2007
Page 57
SIRI Functional Services - UML Diagrams
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.
Other criteria that can be used to filter results include Line (e.g. ‘N45’), Direction, Operator and
Destination.
context
Siri Rqs::SubscriptionRequest
0..*
RequestTimestamp[1] : dateTime
Address[0..1] : EndPointAddress
RequestorRef[1] : Participant
MessageIdentifer[0..1] : MessageQualifier
ConsumerAddress[0..1] : EndPointAddress
SubscriptionFilterIdentifier[0..1] : nmtoken
SubscriptionContext[0..1] : SubscriptionContext
requestor
subscriber
1
Siri Mdl::Participant
Siri Rqs::SubscriptionContext
SIRI-CT
ConnectionTimetableSubscription
& ConnectionTimetableRequest
0..1
1
© 2006 SIRI
requests
1
Siri Rqs::AbstractFunctionalSubscriptionRequest
SubscriberRef : ParticipantCode
SubscriptionIdentifier : SubscriptionCode
InitialTerminationTime : dateTime
0..*
0..*
1
requestor
1
ConnectionTimetableSubscriptionRequest
0..*
ConnectionTimetableRequest[1] : ConnectionTimetableRequest
ConnectionTimetableSubscriptionPolicies[0..1] : ConnectionTimetableSubscriptionPolicies
Extensions[0..1] : any
Siri Rqs::ServiceRequest
RequestContext[1] : RequestContext
RequestTimestamp[1] : dateTime
Address[1] : EndPointAddress
RequestorRef[1] : ParticipantCode
MessageIdentifer[1] : string
1
1
context
0..*
0..1
Siri Rqs::RequestContext
1
request
requests
1
policies
Siri Rqs::AbstractFunctionalServiceRequest
RequestTimestamp : dateTime
MessageIdentifier : MessageQualifier
0..1
ConnectionTimetableSubscriptionPolicies
1
ConnectionTimetableRequest
ConnectionTimetableTopics[0..1] : ConnectionTimetableTopics
ConnectionTimetablePolicies[0..1] : ConnectionTimetablePolicies
Extensions[0..1] : any
policies
0..1
1
ConnectionTimetablePolicies
1
topics
Language[0..1] : lang
0..1
line
TM-Mdl::Line
ConnectionTimetableTopics
TM-Mdl::ConnectionLink
link
0..1
0..*
-PreviewInterval[0..1] : HalfOpenTimestampRange
-ConnectionLinkRef[0..1] : ConnectionLinkCode
-LineRef[0..1] : LineCode
-DirectionRef[0..1] : DirectionCode
0..1
0..*
1
directions
0..*
0..* direction
TM-Mdl::Direction
0..1
Figure 10-2 ConnectionTimetableRequest - Detail
© Copyright Kizoom 2006-2007
Page 58
SIRI Functional Services - UML Diagrams
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..*
1
producer
ProducerResponse
SIRI-CT – Summary
ConnectionTimetableDelivery
Participant
© 2006 SIRI
errors
ServiceDelivery
1
ErrorCondition
deliveries
0..1
0..*
1
1
arrivals
cancellations
ConnectionTimetableDelivery
0..*
1
stops
«group»
StopPointInSequence
StopPointRef[1]
VisitNumber[0..1]
Order[0..1]
StopPointName[0..1]
0..*
2..*
visit
TimetabledFeederArrival
InterchangeRef[0..1]
ConnectionLinkRef[1]
StopPointInSequence[0..1]
FeederJourney[1]
AimedArrivalTime[1]
Extensions[0..1]
0..*
TimetabledFeederArrivalCancellation
InterchangeRef[0..1]
ConnectionLinkRef[1]
StopPointInSequence[0..1]
LineRef[1]
DirectionRef[1]
VehicleJourneyRef[1]
JourneyPatternInfo[0..1]
Reason[0..1]
Extensions[0..1]
at
Interchange
0..*
feeder
0..1
1
link
0..1
0..1
0..*
0..1
interchange
1
1
0..1 visit
frame
DataFrame
0..*
to stop
0..*
10..*
0..1
origin
StopPoint
«group»
FramedVehicleJourneyRef
DataFrameRef[1]
DatedVehicleJourneyRef[1]
journey
1 0..1
ConnectionLink
journey
0..1
destination
0..*
0..*
1
1
JourneyPattern
0..*
0..1
Direction
0..*
directions
1
pattern
0..*
0..1 line
1
Line
0..* 0..1
«group»
JourneyPatternInfo
JourneyPatternRef[0..1]
VehicleMode[0..1]
RouteRef[0..1]
PublishedLineName[0..1]
DirectionName[0..1]
ExternalLineRef[0..1]
0..*
mode
0..* directions
0..1
direction
0..*
1
1
pattern
0..*
0..1
route
pattern
InterchangeJourney
LineRef[1]
DirectionRef[1]
FramedVehicleJourneyRef[0..1]
JourneyPatternInfo[0..1]
VehicleJourneyInfo[0..1]
DisruptionInfo[0..1]
Monitored[0..1]
AimedDepartureTime[0..1]
OperationalInfo[0..1]
Extensions[0..1]
1
Mode
0..1
Route
journey info
1
«group»
DisruptionInfo
SituationRef[0..1]
FacilityChange[0..1]
0..1
1
Operator
operator
disruption
0..*
0..1
0..1
block
Situation
0..1
0..1
1
operational info
0..*situation
0..1
«group»
VehicleJourneyInfo
ServiceInfo[0..1]
OriginRef[0..1]
DestinationName[0..1]
OriginShortName[0..1]
Via[0..*]
DestinationRef[0..1]
DestinationName[0..1]
DestinationShortName[0..1]
VehicleJourneyNote[0..1]
JourneyNote[0..1]
HeadwayService[0..1]
OriginAimedDepartureTime[0..1]
DestinationAimedDepartureTime[0..1]
info
1
DatedVehicleJourney
«group»
OperationalInfo
BlockRef[0..1]
CourseOfJourneyRef[0..1]
VehicleRef[0..1]
0..*
0..*
0..*
run
0..1
vehicle
0..*
feature
0..1
0..1
«group»
ServiceInfo
OperatorRef[0..1]
ProductCategoryRef[0..1]
ServiceFeatureRef[0..*]
VehicleFeatureRef[0..*]
0..*
feature
0..*
category
0..1
ServiceFeature
VehicleFeature
Block
0..1
0..1
Vehicle
CourseOfJourney 0..1
ProductCategory
Figure 10-3 ConnectionTimetableDelivery - Summary
© Copyright Kizoom 2006-2007
Page 59
SIRI Functional Services - UML Diagrams
CONNECTIONTIMETABLEDELIVERY DETAIL
Figure 10-4 shows attribute types for a ConnectionTimetableDelivery as well.
SIRI-CT
ConnectionTimetableDelivery
producer
0..1
Siri Mdl::Participant
© 2006 SIRI
1
Siri Rqs::AbstractFunctionalServiceDelivery
0..*
0..* subscriber
ResponseTimeStamp[1] : dateTime
RequestMessageRef[0..1] : MessageQualifier
SubscriberRef[0..1] : ParticipantCode
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
SubscriptionRef[0..1] : SubscriptionCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
ValidUntil[0..1] : dateTime
ShortestPossibleCycle[0..1] : positiveDuration
Siri Rqs::ProducerResponse
ResponseTimeStamp[1] : dateTime
ProducerRef[0..1] : ParticipantCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
RequestMessageRef[0..1] : MessageQualifier
errors
1
Error[1] : AbstractError
Description[1] : ErrorDescription
0..1
Siri Rqs::ServiceDelivery
0..1 errors
Siri Rqs::ErrorCondition
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
MoreData[1] : boolean
1
deliveries
1
Siri Rqs::AbstractItem
RecordedAtTime[1] : dateTime
0..*
Siri Rqs::AbstractIdentifiedItem
IdentifiedItemCode[0..1] : IdentifiedItemCode
Siri Rqs::AbstractReferencedItem
ConnectionTimetableDelivery
1
arrivals
IdentifiedItemRef[0..1] : IdentifiedItemCode
version[1] : versionString
Extensions[1] : any
1
cancellations
0..1
0..*
0..*
«group»
TM-Mdl::StopPointInSequence
StopPointRef[1] : StopPointCode
VisitNumber[0..1] : VisitNumber
Order[0..1] : positiveInteger
StopPointName[0..1] : populatedString
visit
TimetabledFeederArrival
0..1
InterchangeRef[0..1] : InterchangeCode
ConnectionLinkRef[1] : ConnectionLinkCode
StopPointInSequence[0..1] : StopPointInSequence
FeederJourney[1] : InterchangeJourney
AimedArrivalTime[1] : dateTime
Extensions[0..1] : any
1
0..*
TM-Mdl::Interchange
TM-Mdl::DataFrame
0..*
to stop
TM-Mdl::ConnectionLink
0..*
0..1
frame
0..1
TM-Mdl::Direction
0..*
0..1
«group»Siri Mdl::FramedVehicleJourneyRef
TM-Mdl::DatedVehicleJourney
1
TM-Mdl::JourneyPattern
0..1
pattern0..1 TM-Mdl::Line
0..*
0..*
«group»Siri Mdl::JourneyPatternInfo
0..1
0..1 pattern
1
0..1
1
disruption
1
operational info
block
run
TM-Mdl::CourseOfJourney
0..1
«group»Siri Mdl::VehicleJourneyInfo
ServiceInfo[0..1] : ServiceInfo
OriginRef[0..1] : JourneyPlaceCode
DestinationName[0..1] : populatedString
OriginShortName[0..1] : populatedString
Via[0..*] : populatedString
DestinationRef[0..1] : DestinationCode
DestinationName[0..1] : populatedString
1 DestinationShortName[0..1] : populatedString
VehicleJourneyNote[0..1] : populatedString
JourneyNote[0..1] : populatedString
HeadwayService[0..1] : boolean
OriginAimedDepartureTime[0..1] : dateTime
DestinationAimedDepartureTime[0..1] : dateTime
«group»Siri Mdl::DisruptionInfo
1
SituationRef[0..1] : SituationCode
FacilityChange[0..1] : FacilityChange
TM-Mdl::Operator
operator
0..1
0..1situation
0..*
0..1
0..*
0..*
info
0..*0..1
0..1
Siri Mdl::Situation
0..1
origin
0..*
LineRef[1] : NetworkCode
DirectionRef[1] : DirectionCode
FramedVehicleJourneyRef[0..1] : FramedVehicleJourneyRef
JourneyPatternInfo[0..1] : JourneyPatternInfo
VehicleJourneyInfo[0..1] : VehicleJourneyInfo
0..1
DisruptionInfo[0..1] : DisruptionInfo
Monitored[0..1] : boolean
AimedDepartureTime[0..1] : dateTime
OperationalInfo[0..1] : OperationalInfo
Extensions[0..1] : any
TM-Mdl::Route
TM-Mdl::Block
0..1
Siri Mdl::InterchangeJourney
JourneyPatternRef[0..1] : JourneyPatternCode
VehicleMode[0..1] : Mode
RouteRef[0..1] : RouteCode
PublishedLineName[0..1] : populatedString
DirectionName[0..1] : populatedString
ExternalLineRef[0..1] : LineCode
mode
route
0..1
0..*
0..1
0..*
TM-Mdl::Mode
1
TM-Mdl::StopPoint
destination
DataFrameRef[1] : DataFrameCode
1
DatedVehicleJourneyRef[1] : DatedVehicleJourneyCode
journey
0..*
1
0..*
feeder
0..*
at
1
0..1 0..1
1
TimetabledFeederArrivalCancellation
InterchangeRef[0..1] : InterchangeCode
ConnectionLinkRef[1] : ConnectionLinkCode
StopPointInSequence[0..1] : StopPointInSequence
LineRef[1] : LineCode
DirectionRef[1] : DirectionCode
VehicleJourneyRef[1] : VehicleJourneyCode
JourneyPatternInfo[0..1] : JourneyPatternInfo
Reason[0..1] : populatedString
Extensions[0..1] : any
«group»Siri Mdl::ServiceInfo
0..*
0..*
«group»Siri Mdl::OperationalInfo
BlockRef[0..1] : BlockCode
CourseOfJourneyRef[0..1] : CourseOfJourneyCode
VehicleRef[0..1] : VehicleCode
vehicle
TM-Mdl::Vehicle
OperatorRef[0..1] : OperatorCode
ProductCategoryRef[0..1] : ProductCategoryCode
ServiceFeatureRef[0..*] : ServiceFeatureCode
VehicleFeatureRef[0..*] : VehicleFeatureCode
0..*
Figure 10-4 ConnectionTimetableDelivery - Detail
© Copyright Kizoom 2006-2007
Page 60
SIRI Functional Services - UML Diagrams
11. SIRI CONNECTIONMONITORING (CM)
The SIRI Connection Monitoring Service exchanges information between different AVMS to
coordinate the real-time arrival and departure of PTVs at an interchange through which passengers
may make connecting journeys. The departure time of the outgoing ‘distributor’ (or ‘fetcher from’)
service may be adjusted to accommodate delays in the incoming ‘feeder to’ service.
The service ensures that the AVMS are in a position to receive all the necessary data concerning the
feeder vehicles to allow connection monitoring and dispatch to be carried out, and to inform
passengers of changes. The operational methods of dispatch remain unaffected.
The Service can be used in conjunction with the SIRI Connection Timetable Service to exchange
scheduled arrival times in the target connection links.

The Topics allow a Consumer system to specify that only Connection Timetables for a specific
Connection Link, Line, or Line Direction or Vehicle are to be returned.

The Delivery can return information about both changes to feeder (e.g. late arrival) and
departure (e.g. late departure, platform change)
SIRI-CM: SUBSCRIPTION & REQUEST
CONNECTIONMONITORINGREQUEST SUMMARY
requestor
Participant
requestor
1
0..*
SubscriptionRequest
1
0..*
SIRI-CM
ConnectionMonitoringSubscription
& ConnectionMonitoringRequest
requests
1
© 2007 SIRI
0..*
requests
ServiceRequest
policies
1
ConnectionMonitoringSubscriptionRequest
0..*
1
1
1
request
0..1
1
ConnectionMonitoringRequest
topics
ConnectionMonitoringSubscriptionPolicies
1
policies
0..1
ConnectionMonitoringPolicies
ConnectionMonitoringTopics
PreviewInterval
ConnectionLinkRef
ConnectionTimeFilter
ConnectionJourneyFilter
1
line
0..1
link
ConnectionLink
0..1
0..*
journeys
time scope
0..1
0..*
0..1
0..*
1
LineRef
DirectionRef
EarliestArrivalTime
LatestArrivalTime
Line
journey
ConnectionJourneyFilter
ConnectionTimeFilter
direction
0..*
0..1
Direction
DatedVehicleJourneyRef
VisitNumber
TimetabledArrivalTime
1
0..1
DatedVehicleJourney
Figure 11-1 ConnectionMonitoringRequest - Summary
© Copyright Kizoom 2006-2007
Page 61
SIRI Functional Services - UML Diagrams
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.
Other criteria that can be used to filter results include Line (e.g. ‘N45’), Direction, Operator and
Destination.
SIRI-CM
ConnectionMonitoringSubscription
& ConnectionMonitoringRequest
Siri Rqs::SubscriptionRequest
requestor
0..*
RequestTimestamp : dateTime
Address : EndPointAddress
RequestorRef : Participant
MessageIdentifer : MessageQualifier
ConsumerAddress : EndPointAddress
SubscriptionFilterIdentifier : nmtoken
SubscriptionContext : SubscriptionContext
© 2007 SIRI
requests
1
1
Siri Rqs::AbstractFunctionalSubscriptionRequest
subscriber
Siri Mdl::Participant
1
requestor
1
0..*
SubscriberRef : ParticipantCode
SubscriptionIdentifier : SubscriptionCode
InitialTerminationTime : dateTime
0..*
0..*
Siri Rqs::ServiceRequest
ConnectionMonitoringSubscriptionRequest
-RequestContext : RequestContext
-RequestTimestamp : dateTime
-Address : EndPointAddress
-RequestorRef : ParticipantCode
-MessageIdentifer : string
ConnectionMonitoringRequest[1] : ConnectionMonitoringRequest
ConnectionMonitoringSubscriptionPolicies[0..1] : ConnectionMonitoringSubscriptionPolicies
policies
Extensions[0..1] : any
1
request
1
1
0..1
Siri Rqs::AbstractFunctionalServiceRequest
RequestTimestamp : dateTime
MessageIdentifier : MessageQualifier
requests
1
ConnectionMonitoringRequest
1
topics
ConnectionMonitoringSubscriptionPolicies
0..*
policies
ConnectionMonitoringTopics[0..1] : ConnectionMonitoringTopics
ConnectionMonitoringPolicies[0..1] : ConnectionMonitoringPolicies
Extensions[0..1] : any
1
0..1
0..1
ConnectionMonitoringPolicies
Language[0..1] : lang
ConnectionMonitoringTopics
-PreviewInterval[0..1] : duration
-ConnectionLinkRef[0..1] : ConnectionLinkCode
-ConnectionTimeFilter[0..1] : ConnectionTimeFilter
-ConnectionJourneyFilter[0..1] : ConnectionTimeFilter
1
time scope
0..* to stop
link
0..*
journeys
TM-Mdl::ConnectionLink
0..1
0..1
1
0..*
0..*
link
0..1
1
at
TM-Mdl::StopPoint
0..*
0..1
ConnectionJourneyFilter
ConnectionTimeFilter
-DatedVehicleJourneyRef[0..1] : DatedVehicleJourneyCode
«group»
TM-Mdl::StopPointInSequence
StopPointRef : StopPointCode
VisitNumber : VisitNumber
Order : positiveInteger
StopPointName : populatedString
-VisitNumber[0..1] : integer
-LineRef[0..1] : LineCode
-TimetabledArrivalTime[0..1] : dateTime
-DirectionRef[0..1] : DirectionCode
-EarliestArrivalTime[0..1] : dateTime
1
-LatestArrivalTime[0..1] : dateTime
direction
journey
line
0..*
0..1
0..*
TM-Mdl::DatedVehicleJourney
0..1
directions
0..1
TM-Mdl::Direction
TM-Mdl::JourneyPattern
1pattern
TM-Mdl::Line
0..*
1
pattern
0..1
«group»
Siri
Mdl::JourneyPatternInfo
0..1
0..*
2..*
stops
1
Figure 11-2 ConnectionMonitoringRequest - Detail
SIRI-CM: DELIVERY
© Copyright Kizoom 2006-2007
Page 62
SIRI Functional Services - UML Diagrams
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 (DistributureDepartureCancellation) or a platform change (StoppingPositionChangedRecording).
0..*
1
producer
ProducerResponse
SIRI-CM - Summary
ConnectionMonitoringDelivery
Participant
© 2007 SIRI
errors
ServiceDelivery
deliveries
1
ErrorCondition
deliveries
0..1
1
0..*
1
0..*
ConnectionMonitoringDistributorDelivery
ConnectionMonitoringFeederDelivery
1
1
11
cancellations
0..*
1
arrvals
cancels
1
0..*
MonitoredFeederArrivalCancellation
MonitoredFeederArrival
1
1
InterchangeRef[0..1]
ConnectionLinkRef[1]
StopPointInSequence[0..1]
ClearDownRef[0..1]
FeederJourney[1]
VehicleAtStop[1]
NumberOfTransferPassengers[0..1]
ExpectedArrivalTime[1]
Extensions[0..1]
0..1
0..1
1
0..1
interchange
Interchange
link
0..*
1
0..1
0..1
ConnectionLink
0..*
to stop
cancellation
0..1
to stop
stops
AbstractDistributorItem
at
StopPoint
1
1
0..*
0..*
«group»
StopPointInSequence
StopPointRef[1]
VisitNumber[0..1]
Order[0..1]
StopPointName[0..1]
feeder
InterchangeRef[0..1] : InterchangeCode
ConnectionLinkRef[1] : ConnectionLinkCode
StopPointInSequence[0..1] : StopPointInSequence
LineRef[1] : LineCode
DirectionRef[1] : DirectionCode
VehicleJourneyRef[1] : VehicleJourneyCode
1
JourneyPatternInfo[0..1] : JourneyPatternInfo
Reason[0..1] : populatedString
delayed
wait
Extensions[0..1] : any
interchange
distributor
0..1
0..1
1
1
distributor
DatedVehicleJourney
Line
1
0..*
pattern
0..*
0..*
WaitProlongedDeparture
ExpectedDepartureTime[0..1]
Extensions[0..1]
0..1
line
1
journey
position change
InterchangeRef[0..1]
ConnectionLinkRef[1]
StopPointRef[0..1]
DistributorVisitNumber[0..1]
DistributorOrder[0..1]
DistributorJourney[1]
FeederVehicleJourneyRef[0..1]
Extensions[0..1]
feeder
Reason[0..1]
Extensions[0..1]
0..*
0..*
StoppingPositionChangedDeparture
InterchangeJourney
directions
LineRef[1]
DirectionRef[1]
0..*
FramedVehicleJourneyRef[0..1]
1
1
JourneyPatternInfo[0..1]
Direction
VehicleJourneyInfo[0..1]
DisruptionInfo[0..1]
Monitored[0..1]
AimedDepartureTime[0..1]
OperationalInfo[0..1]
Extensions[0..1]
operational info
journey info
1
0..1
«group»
OperationalInfo
1
1
disruption
ChangeNote[0..1]
NewLocation[0..1]
Extensions[0..1]
0..1
0..1
Mode
mode
0..*
0..*
0..1
route
0..1
Route
«group»
VehicleJourneyInfo
«group»
JourneyPatternInfo
JourneyPatternRef[0..1]
VehicleMode[0..1]
RouteRef[0..1]
PublishedLineName[0..1]
DirectionName[0..1]
ExternalLineRef[0..1]
0..*
pattern
0..1
0..1
«group»
DisruptionInfo
0..*
DistributorDepartureCancellation
«group»
FramedVehicleJourneyRef
DataFrameRef[1]
DatedVehicleJourneyRef[1]
See ConnectionTimetable
Service for details
JourneyPattern
Figure 11-3 ConnectionMonitoringDelivery - Summary
© Copyright Kizoom 2006-2007
Page 63
SIRI Functional Services - UML Diagrams
CONNECTIONMONITORINGDELIVERY DETAIL
Figure 11-4 shows attribute types for a ConnectionMonitoringDelivery.
Siri Rqs::ProducerResponse
SIRI-CM
ConnectionMonitoringDelivery
0..1
producer
Siri Mdl::Participant
1
© 2007 SIRI
subscriber
0..*
-ResponseTimeStamp : dateTime
-ProducerRef : ParticipantCode
-Address : EndPointAddress
-ResponseMessageIdentifier : MessageQualifier
-RequestMessageRef : MessageQualifier
Siri Rqs::AbstractFunctionalServiceDelivery
0..*
ResponseTimeStamp[1] : dateTime
Siri Rqs::ServiceDelivery
RequestMessageRef[0..1] : MessageQualifier
1
Status[0..1] : boolean
0..1
SubscriberRef[0..1] : ParticipantCode
errors
ErrorCondition[0..1] : ErrorCondition
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
Siri Rqs::ErrorCondition
MoreData[1] : boolean
SubscriptionRef[0..1] : SubscriptionCode
deliveries
Error[1] : AbstractError
Address[0..1] : EndPointAddress
Description[1] : ErrorDescription
1
1
ResponseMessageIdentifier[0..1] : MessageQualifier
deliveries
0..*
Status[0..1] : boolean
0..*
ErrorCondition[0..1] : ErrorCondition
ValidUntil[0..1] : dateTime
ConnectionMonitoringFeederDelivery
ConnectionMonitoringDistributorDelivery
ShortestPossibleCycle[0..1] : positiveDuration
1
version[1] : versionString
version[1] : versionString
Extensions[1] : BaseSituation
Extensions[1] : any
Siri Rqs::AbstractItem
RecordedAtTime[1] : dateTime
1
1
1
1
Siri Rqs::AbstractReferencedItem
Siri Rqs::AbstractIdentifiedItem
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
StopPointInSequence[0..1] : StopPointInSequence
0..1
1
TM-Mdl::Interchange
11
StopPointInSequence[0..1] : StopPointInSequence
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
0..1
ExpectedArrivalTime[1] : dateTime
Extensions[0..1] : any
0..*TM-Mdl::ConnectionLink
Extensions[0..1] : any
1
at
to
stop
1
«group»Siri Mdl::JourneyPatternInfo
TM-Mdl::Route
0..10..*
1
JourneyPatternRef[0..1] : JourneyPatternCode
TM-Mdl::StopPoint
route 0..*
«group»
VehicleMode[0..1] : Mode
0..1
TM-Mdl::StopPointInSequence
0..1
RouteRef[0..1] : RouteCode
0..*
StopPointRef[1] : StopPointCode
PublishedLineName[0..1] : populatedString
VisitNumber[0..1] : VisitNumber
DirectionName[0..1] : populatedString
CM-Mdl::AbstractDistributorItem
0..*
Order[0..1] : positiveInteger
ExternalLineRef[0..1] : LineCode
InterchangeRef[0..1] : InterchangeCode
feeder StopPointName[0..1] : populatedString
ConnectionLinkRef[1] : ConnectionLinkCode
0..*mode 0..*
1
distributor
0..1
StopPointRef[0..1] : StopPointCode
0..1
pattern
0..1
0..1
DistributorVisitNumber[0..1] : VisitNumber
TM-Mdl::Mode
feeder
0..*
DistributorOrder[0..1] : positiveInteger
DistributorJourney[1] : InterchangeJourney
0..1
«group»
FeederVehicleJourneyRef[0..1] : FramedVehicleJourneyRef
Siri Mdl::FramedVehicleJourneyRef
TM-Mdl::JourneyPattern
Extensions[0..1] : any
distributor
journey
1
0..*
pattern
1
1
Siri Mdl::InterchangeJourney
1
LineRef[1] : NetworkCode
DirectionRef[1] : DirectionCode
FramedVehicleJourneyRef[0..1] : FramedVehicleJourneyRef
JourneyPatternInfo[0..1] : JourneyPatternInfo
VehicleJourneyInfo[0..1] : VehicleJourneyInfo
DisruptionInfo[0..1] : DisruptionInfo
Monitored[0..1] : boolean
AimedDepartureTime[0..1] : dateTime
OperationalInfo[0..1] : OperationalInfo
Extensions[0..1] : any
CM-Mdl::WaitProlongedDeparture
0..*
ExpectedDepartureTime[0..1] : dateTime
Extensions[0..1] : any
1
CM-Mdl::StoppingPositionChangedDeparture
0..*
ChangeNote[0..1] : populatedString
NewLocation[0..1] : Location
Extensions[0..1] : any
0..*
DistributorDepartureCancellation
0..1
TM-Mdl::Line
0..*
line
direction
0..*
TM-Mdl::Direction
See ConnectionTimetable
Service for details
Reason[0..1] : populatedString
Extensions[0..1] : any
0..1
Figure 11-4 ConnectionMonitoringDelivery - Detail
© Copyright Kizoom 2006-2007
Page 64
SIRI Functional Services - UML Diagrams
12. SIRI GENERALMESSAGE (GM)
The SIRI General Message service is used to transmit messages between the participants. The data to
be published will typically be informative messages such as travel news and other operational advice,
entered or forwarded into the system - normally by a control centre. The General Message service
can segregate different types of informative message into separate information channels; each info
channel can be assigned to a different operational message group type (errors, messages, warnings,
traffic information, operational messages, etc.).

The Topics allow a Consumer system to specify that only specific categories of message are
to be returned.
The service allows arbitrary content to be embedded. To exchange structured messages see the SIRISX service.
SIRI-GM: SUBSCRIPTION & REQUEST
GENERALMESSAGEREQUEST SUMMARY
requestor
Participant
1
SIRI-GM - Summary
GeneralMessageSubscription
& GeneralMessageRequest
requests
SubscriptionRequest
requestor
1
0..*
0..*
1
0..*
© 2007 SIRI
policies
GeneralMessageSubscriptionRequest
ServiceRequest
requests
1
topics
1
1
*
GeneralMessageSubscriptionPolicies
1
GeneralMessageRequest
policies
1
0..1
GeneralMessageTopics
GeneralMessagePolicies
InfoChannel[0..1]
0..*
1
request
0..*
0..1
Language[0..1]
channel
InfoChannel
0..1
Figure 12-1 GeneralMessageRequest - Summary
© Copyright Kizoom 2006-2007
Page 65
SIRI Functional Services - UML Diagrams
GENERALMESSAGEREQUEST DETAIL
The GeneralMessageRequest (Figure 12-2) is used to request message data.
Data may be filtered by an InfoChannel.
Siri Rqs::SubscriptionRequest
Siri Rqs::ProducerResponse
RequestTimestamp[1] : dateTime
Address[0..1] : EndPointAddress
RequestorRef[1] : Participant
MessageIdentifer[0..1] : MessageQualifier
ConsumerAddress[0..1] : EndPointAddress
SubscriptionFilterIdentifier[0..1] : nmtoken
SubscriptionContext[0..1] : SubscriptionContext
0..*
requestor
SIRI-GM
GeneralMessageSubscription
& GeneralMessageRequest
© 2007 SIRI
requests
1
producer
0..*
Siri Rqs::AbstractFunctionalSubscriptionRequest
SubscriberRef[1] : ParticipantCode
SubscriptionIdentifier[1] : SubscriptionCode
InitialTerminationTime[1] : dateTime
subscriber
1
1
0..*
Siri Mdl::Participant
requestor
1
0..*
0..*
1
GeneralMessageSubscriptionRequest
Siri Rqs::ServiceRequest
RequestContext[1] : RequestContext
RequestTimestamp[1] : dateTime
Address[1] : EndPointAddress
RequestorRef[1] : ParticipantCode
MessageIdentifer[1] : string
GeneralMessageRequest[1] : GeneralMessageRequest
GeneralMessageSubscriptionPolicies[0..1] : GeneralMessageSubscriptionPolicies
Extensions[0..1] : any
policies
1
*
1 Rqs::AbstractFunctionalServiceRequest
Siri
request
RequestTimestamp[1]
: dateTime
GeneralMessageSubscriptionPolicies
MessageIdentifier[0..1] : MessageQualifier
1
1
requests
topics 0..*1
GeneralMessageRequest
GeneralMessageTopics[0..1] : GeneralMessageTopics
GeneralMessagePolicies[0..1] : GeneralMessagePolicies
Extensions[0..1] : any
policies
0..1
1
0..1
GeneralMessagePolicies
GeneralMessageTopics
channel
Language[0..1] : lang
InfoChannel[0..1] : InfoChannelCode
0..*
0..1
GM-Mdl::InfoChannel
Figure 12-2 GeneralMessageRequest - Detail
© Copyright Kizoom 2006-2007
Page 66
SIRI Functional Services - UML Diagrams
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.
0..*
1
producer
ProducerResponse
Participant
SIRI-GM Summary
GeneralMessageDelivery
deliveries
ServiceDelivery
© 2007 SIRI
0..*
1
*
GeneralMessageDelivery
1
1
0..*
GeneralMessage
situation
1
0..1
Situation
GeneralMessageCancellation
InfoMessageIdentifier[1]
InfoMessageVersion[0..1]
InfoChannelRef[0..1]
ValidUntilTime[0..1]
SituationRef[0..1]
Content[1]
cancels
0..1
0..*
InfoMessageIdentifier[1]
InfoMessageVersion[0..1]
InfoChannelRef[0..1]
ValidUntilTime[0..1]
SituationRef[0..1]
Extensions[0..1]
1
0..*
0..1
*
channel
InfoChannel
Content
format[0..1] : nmtoken
value[0..1] : string
Figure 12-3 GeneralMessageDelivery - Summary
© Copyright Kizoom 2006-2007
Page 67
SIRI Functional Services - UML Diagrams
GENERALMESSAGEDELIVERY DETAIL
Figure 12-4 shows attribute types for a GeneralMessageDelivery.
Siri Rqs::ProducerResponse
SIRI-GM
GeneralMessageDelivery
ResponseTimeStamp[1] : dateTime
ProducerRef[0..1] : ParticipantCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
RequestMessageRef[0..1] : MessageQualifier
© 2007 SIRI
producer
1
0..*
Siri Mdl::Participant
subscriber
Siri Rqs::ServiceDelivery
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
MoreData[1] : boolean
0..1
0..*
0..1
1
Siri Rqs::AbstractFunctionalServiceDelivery
ResponseTimeStamp[1] : dateTime
RequestMessageRef[0..1] : MessageQualifier
SubscriberRef[0..1] : ParticipantCode
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
SubscriptionRef[0..1] : SubscriptionCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
ValidUntil[0..1] : dateTime
ShortestPossibleCycle[0..1] : positiveDuration
1
SIRI Requests::ErrorCondition
-Error[1] : AbstractError
-Description[1] : ErrorDescription
0..1
1
0..*
deliveries
GeneralMessageDelivery
1
version[1] : versionString
Extensions[0..1]
Siri Rqs::AbstractItem
1
-RecordedAtTime[1] : dateTime
Siri Rqs::AbstractReferencedItem
Siri Rqs::AbstractIdentifiedItem
IdentifiedItemRef[0..1] : IdentifiedItemCode
IdentifiedItemCode[0..1] : IdentifiedItemCode
0..1
0..1
GeneralMessage
GeneralMessageCancellation
InfoMessageIdentifier[1] : InfoMessageIdentifier
InfoMessageVersion[0..1] : InfoMessageVersion
InfoChannelRef[0..1] : InfoChannelCode
ValidUntilTime[0..1] : dateTime
SituationRef[0..1] : SituationCode
Content[1] : Content
InfoMessageIdentifier[1] : InfoMessageIdentifier
InfoMessageVersion[0..1] : InfoMessageVersion
InfoChannelRef[0..1] : InfoChannelCode
ValidUntilTime[0..1] : dateTime
SituationRef[0..1] : SituationCode
Extensions[0..1]
situation
0..1
Siri Mdl::Situation
0..1
0..*
info channel
cancels
1
0..1
1
1
«datatype»
GM-Mdl::InfoMessageIdentifier
«datatype»
GM-Mdl::InfoChannelCode
Content
GM-Mdl::InfoChannel
0..1
format[0..1] : nmtoken
value[0..1] : string
«datatype»
GM-Mdl::InfoMessageVersion
Figure 12-4 GeneralMessageDelivery - Detail
© Copyright Kizoom 2006-2007
Page 68
SIRI Functional Services - UML Diagrams
13. SIRI FACILITYMONITORING (FM) DRAFT
SIRI-FM: SUBSCRIPTION & REQUEST
FACILITYMONITORINGREQUEST SUMMARY
[TODO]
Figure 13-1 ProductionTimeTableRequest - Summary
FACILITYMONITORINGREQUEST DETAIL
[TODO]
Figure 13-2 ProductionTimetableRequest - Detail
SIRI-FM: DELIVERY
FACILITYMONITORINGDELVIERY SUMMARY
[TODO]
Figure 13-3 ProductionTimetableDelivery - Summary
FACILITYMONITORINGDELVIERY DETAIL
[TODO]
Figure 13-4 ProductionTimetableDelivery - Detail
© Copyright Kizoom 2006-2007
Page 69
SIRI Functional Services - UML Diagrams
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 Stuctured incidents and updates.
SIRI-SX: SUBSCRIPTION & REQUEST
SITUATIONEXCHANGEREQUEST SUMMARY
Figure 14-1 Summarises the SIRI-SX request elements.
participant
Participant
participant
1
0..*
SIRI-SX Summary
SituationExchangeSubscription
& SituationExchangeRequest
subscriptions
© 2007 SIRI
SubscriptionRequest
1
0..*
1
0..*
policies
ServiceRequest
SituationExchangeSubscriptionRequest
request
requests
1
1
1
*
SituationExchangeSubscriptionPolicies
IncrementalUpdates[0..1]
1
*
policies
SituationExchangePolicies
SituationExchangeRequest
1
topics
Language[0..1]
MaximumNumberOfSituations[0..1]
0..1
1
«enumeration»
PredictabilityEnum
planned
unplanned
both
«enumeration»
TpegSeverityEnum
unknown
verySlight
slight
normal
severe
verySevere
noImpact
undefined
«enumeration»
VehicleModesEnum
air
bus
coach
ferry
metro
rail
tram
underground
0..1
SituationExchangeTopics
1
filter
PreviewInterval[1]
StartTime[0..1]
VehicleMode[0..1]
AffectedSubMode[0..1]
AccessMode[1]
Severity[0..1]
Predictability[0..1]
Keywords[0..*]
SituationNetworkFilter[0..1]
SituationStopPlaceFilter[0..1]
SituationJourneyFilter[0..1]
AccessibilityNeedFilter[0..1]
1
1
filter
1
0..1
0..1
AccessibilityNeedsFilter
0..1
0..1 0..*
network
UserNeed[0..1]
SituationStopPlaceFilter
SituationNetworkFilter
1
unit
0..*
filter
places
Network
«enumeration»
AccessModesEnum
foot
bicycle
car
taxi
shuttle
0..*
operator
OperatorRef[0..1]
OperationalUnitRef[0..1]
NetworkRef[0..1]
LineRef[0..1]
StopPointRef[0..1]
ConnectionLinkRef[0..1]
StopPlaceRef[0..1]
FacilityRef[0..1]
0..*
VehicleJourneyRef[0..1]
InterchangeRef[0..1]
VehicleRef[0..1]
0..1
0..*
vehicle
0..*
stop place
0..*
0..*
interchange
0..1
0..*
1
Interchange
line stop point
user need
journey
connection
0..*0..*
0..1
SituationJourneyFilter
StopPlace
0..1
0..1
UserNeed
0..1
0..1 Operator
0..1
1
VehicleJourney
Vehicle
StopPoint
OperationalUnit
Line
ConnectionLink
Figure 14-1 SituationExchangeRequest - Summary
© Copyright Kizoom 2006-2007
Page 70
SIRI Functional Services - UML Diagrams
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
0..1
RequestTimestamp[1] : dateTime
Address[0..1] : EndPointAddress
1
RequestorRef[1] : Participant
MessageIdentifer[0..1] : string
1
ConsumerAddress[0..1] : EndPointAddress
requests
SubscriptionFilterIdentifier[0..1] : nmtoken
SubscriptionContext[0..1] : SubscriptionContext
1
1
requestor
0..*
0..1
Siri Rqs::ServiceRequest
RequestContext[1] : RequestContext
RequestTimestamp[1] : dateTime
Address[1] : EndPointAddress
RequestorRef[1] : ParticipantCode
MessageIdentifer[1] : string
© 2007 SIRI
SituationExchangeSubscriptionRequest
policies
SituationExchangeRequest[1] : SituationExchangeRequest
SituationExchangeSubscriptionPolicies[0..1] : SituationExchangeSubscriptionPolicies
Extensions[0..1] : any
Siri Rqs::RequestContext
*
SIRI-SX
SituationExchangeSubscription
& SituationExchangeRequest
*
context
1
0..1
requests
1
Siri Rqs::SubscriptionContext
Siri Rqs::SubscriptionRequest
requestor
1
request
SituationExchangeRequest
1
1
0..1
SituationExchangeSubscriptionPolicies
IncrementalUpdates[0..1] : boolean
SituationExchangeTopics[0..1] : SituationExchangeTopics
SituationExchangePolicies[0..1] : SituationExchangePolicies
Extensions[0..1] : any
1
policies
SituationExchangePolicies
«enumeration»
PredictabilityEnum
planned
unplanned
both
1
topic
unit
TM-Mdl::OperationalUnit
TM-Mdl::Network
0..* network
SituationNetworkFilter
operator
1
OperatorRef[0..1] : OperatorCode
OperationalUnitRef[0..1] : OperationalUnitCode
NetworkRef[0..1] : NetworkCode
LineRef[0..1] : LineCode
StopPointRef[0..1] : StopPointCode
ConnectionLinkRef[0..1] : ConnectionLinkCode
0..*
SituationExchangeTopics
PreviewInterval[1] : duration
StartTime[0..1] : dateTime
VehicleMode[0..1] : VehicleModesEnum
AffectedSubMode[0..1] : AccessModesEnum
AccessMode[1] : AccessModesEnum
Severity[0..1] : TpegSeverityEnum
Predictability[0..1] : boolean
Keywords[0..*] : string
SituationNetworkFilter[0..1] : SituationNetworkFilter
SituationStopPlaceFilter[0..1] : SituationStopPlaceFilter
SituationJourneyFilter[0..1] : SituationJourneyFilter
AccessibilityNeedFilter[0..1] : AccessibilityNeedsFilter
1
0..*
1
TM-Mdl::Operator
0..1
Language[0..1] : lang
MaximumNumberOfSituations[0..1] : integer
*
1
0..1
filter
0..*
1
0..*
1
0..1
0..*
connection
1
SituationStopPlaceFilter
0..1
1
TM-Mdl::ConnectionLink
1
stop place
0..*
filter
TM-Mdl::StopPoint
to stop
0..*
StopPlaceRef[0..1] : StopPlaceCode
FacilityRef[0..1] : FacilityCode
1
TM-Mdl::Line
stop
iFOPT-Mdl::StopPlace
1
SituationJourneyFilter
«enumeration»
TpegSeverityEnum
unknown
verySlight
slight
normal
severe
verySevere
noImpact
undefined
0..1
filter
0..*
0..*
0..*
1
TM-Mdl::VehicleJourney
0..*
AccessibilityNeedsFilter
1
needs
interchange
vehicle
1
«enumeration»
AccessModesEnum
foot
bicycle
car
taxi
shuttle
journey
VehicleJourneyRef[0..1] : VehicleJourneyCode
InterchangeRef[0..1] : InterchangeCode
VehicleRef[0..1] : VehicleCode
«enumeration»
VehicleModesEnum
air
bus
coach
ferry
metro
rail
tram
underground
*
1
TM-Mdl::Vehicle
TM-Mdl::Interchange
ACSB-Mdl::UserNeed
Figure 14-2 SituationExchangeRequest - Detail
SIRI-SX: DELIVERY
© Copyright Kizoom 2006-2007
Page 71
SIRI Functional Services - UML Diagrams
SITUATIONEXCHANGEDELIVERY SUMMARY
The SituationExchangeDelivery (Figure 14-3) is returned by the SIRI-SX service and normally contains
one or more Situation elements; these will either be a BaseSituation or an UpdateSituation. The
Situation has a body 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.
Siri Rqs::ProducerResponse
errors
Siri Rqs::ServiceDelivery
SIRI-SX Summary
SituationExchangeDelivery
Siri Rqs::ErrorCondition
1
0..1
© 2006 SIRI
deliveries
1
SituationContext
context
0..*
1
1
0..*
related to
1
situations
RelatedSituation
*
CreationTime[1]
CountryRef[0..1]
ParticipantRef[0..1]
SituationNumber[1]
SituationVersion[0..1]
RelatedAs[1]
references
AbstractSituation
CreationTime[1]
CountryRef[0..1]
ParticipantRef[1]
SituationNumber[1]
RelatedTo[0..*]
SituationBody[1]
body
1
1
body
1
SituationSource
1
made by
1
0..*
Participant
updates
BaseSituation
«enumeration»
RelatedEnum
cause
effect
supercedes
supercededBy
association
0..1
SituationExchangeDelivery
UpdateSituation
SituationVersion[0..1]
0..*whenUpdateParticipantRef[0..1]
1
«group»
PtSituationBody
SituationSource[1]
SituationStatus[1]
TemporalGroup[1]
ClassifierGroup[1]
DescriptionGroup[0..1]
Affects[0..1]
Consequences[0..*]
PublishingActions[0..1]
Extensions[0..1]
1
1
classifiers
description 1
1
reason
1 0..*
1
«group»
TemporalGroup
ValidityPeriod[1]
Repetitions[0..*]
PublicationWindow[1]
1
applies
0..1
«group»
ClassifierGroup
Reason[1]
ReasonName[0..1]
Severity[1]
Priority[0..1]
Sensitivity[0..1]
Audience[0..1]
ReportType[0..1]
ScopeType[0..1]
Planned[0..1]
Keywords[0..*]
0..1
0..1
0..*made
1 by
SX-Mdl::Reason
*
PublishingActions
1
1
«group»
DescriptionGroup
Summary[0..1]
Description[0..1]
Detail[0..1]
Advice[0..1]
Internal[0..1]
Images[0..*]
InfoLink[0..*]
actions
1
source
Country[0..1]
SourceType[1]
Email[0..1]
Phone[0..1]
Fax[0..1]
Web[0..1]
Other[0..1]
AgentReference[0..1]
TimeOfCommunication[1]
ExternalCode[0..1]
1
Consequence
1
consequence
1
0..*
affects
affects
Period[0..1]
Condition[0..1]
Severiity[1]
Affects[0..1]
Suitabilities[0..*]
Advice[1]
Blocking[0..1]
Boarding[0..1]
Delay[0..1]
Casualties[0..1]
Easements[0..1]
Extensions[0..1]
network
ValidityPeriod
-StartTime[1]
-EndTime[1]
1
SX-Affects::AffectedNetwork
0..*
0..* networks
TM-Mdl::Network
1
1
1
operators
0..*
journeys
10..1 0..1
SX-Affects::AffectedVehicleJourney
0..*
SX-Affects::Affects
journey0..*
0..*
operator
1
SX-Affects::AffectedOperator
lines
0..1
0..*
TM-Mdl::Operator
1
0..*
SX-Affects::AffectedScheduledStop
stop place 0..*
0..1
TM-Mdl::StopPoint
place
SX-Affects::AffectedPlace
0..*
0..*
stop
TM-Mdl::Line
TM-Mdl::DatedVehicleJourney
stops
places
0..*
0..1
1
1
places
SX-Affects::AffectedLine
line
1
0..1
iFOPT-Mdl::StopPlace
0..*
0..1
0..*
SX-Affects::AffectedStopPlace
TM-Mdl::Place
0..*
stop place
iFOPT-Mdl::StopPlaceComponent
0..1
Figure 14-3 SituationExchangeDelivery - Summary
© Copyright Kizoom 2006-2007
Page 72
SIRI Functional Services - UML Diagrams
SITUATIONEXCHANGEDELIVERY DETAIL
Figure 14-6 shows attribute types for a SituationExchangeDelivery. For a further summary of the
structured model, see below.
1
Siri Rqs::ProducerResponse
1
subscriber 0..1
0..*
Siri Rqs::AbstractFunctionalServiceDelivery
made by
ResponseTimeStamp[1] : dateTime
RequestMessageRef[0..1] : MessageQualifier
SubscriberRef[0..1] : ParticipantCode
SubscriptionFilterRef[0..1] : SubscriptionFilterCode
SubscriptionRef[0..1] : SubscriptionCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
Status[0..1] : boolean
made by
ErrorCondition[0..1] : ErrorCondition
ValidUntil[0..1] : dateTime
ShortestPossibleCycle[0..1] : positiveDuration
Siri Mdl::Participant
producer
1
0..*
errors
Siri Rqs::ErrorCondition
1
0..1
Error[1] : AbstractError
Description[1] : ErrorDescription
ResponseTimeStamp[1] : dateTime
ProducerRef[0..1] : ParticipantCode
Address[0..1] : EndPointAddress
ResponseMessageIdentifier[0..1] : MessageQualifier
RequestMessageRef[0..1] : MessageQualifier
1
0..1
errors
Siri Rqs::ServiceDelivery
Status[0..1] : boolean
ErrorCondition[0..1] : ErrorCondition
MoreData[1] : boolean
1
deliveries
0..*
SX-Mdl::AbstractSituation
CreationTime[1] : dateTime
CountryRef[0..1] : CountryEnum
ParticipantRef[1] : ParticipantCode
SituationNumber[1] : SituationIdentifier
RelatedTo[0..*] : RelatedSituation
SituationBody[1] : PtSituationBody
0..*
SituationExchangeDelivery
body
version[1] : versionString
Extensions[0..1] : any
SIRI-SX
SituationExchangeDelivery
1
© 2006 SIRI
updates
SX-Mdl::BaseSituation
1
SX-Mdl::UpdateSituation
0..*
SituationVersion[0..1] : SituationVersion
UpdateParticipantRef[0..1] : Participant
1
«group»
SX-Mdl::PtSituationBody
0..*
Figure 14-4 SituationExchangeDelivery - Detail
SITUATION MODEL
© Copyright Kizoom 2006-2007
Page 73
SIRI Functional Services - UML Diagrams
SITUATION
Figure 14-4 shows the main elements and attributes of the Situation model. It has four three basic
groups of elements: the TemporalGroup (time that Situation applies), ClassifierGroup (a
categorisation of incident) and a DescriptionGroup (human readable textual descriptions) and
SituationStatus . Child elements describe the origin (SituationSource),Consequence and scope of
effect (Affects).
SIRI-SX
Situation - Basic
AffectedNetwork
0..*
0..*
© 2006 SIRI
CreationTime[1]
CountryRef[0..1]
ParticipantRef[1]
SituationNumber[1]
RelatedTo[0..*]
SituationBody[1]
0..*
1
made by
1 0..*
AffectedPlace
journeys
0..*
0..*
1
places
operators
1
1
Participant
made by
1
1
1
Affects
1
updates
0..*
networks
stops
body
AffectedOperator
0..*
BaseSituation
AffectedVehicleJourney
AffectedScheduledStop
AbstractSituation
1
0..*
lines
UpdateSituation
0..1
AffectedLine
SituationVersion[0..1]
UpdateParticipantRef[0..1]
places
1
0..1
1
0..*
«group»PtSituationBody
SituationSource
Country[0..1]
SourceType[1]
Email[0..1]
Phone[0..1]
Fax[0..1]
Web[0..1]
Other[0..1]
AgentReference[0..1]
TimeOfCommunication[1]
ExternalCode[0..1]
1
0..1
source
1
1
SituationSource[1]
SituationStatus[1]
TemporalGroup[1]
ClassifierGroup[1]
DescriptionGroup[0..1]
Affects[0..1]
Consequences[0..*]
PublishingActions[0..1]
Extensions[0..1]
1
classifiers
affects
AffectedStopPlace
consequence
affects
1
actions
1
0..1
1
PublishingActions
1
0..*
when
*
1
description
«group»
TemporalGroup
ValidityPeriod[1]
Repetitions[0..*]
PublicationWindow[1]
0..*
1
reason
Reason
«group»
ClassifierGroup
Reason[1]
ReasonName[0..1]
Severity[1]
Priority[0..1]
Sensitivity[0..1]
Audience[0..1]
ReportType[0..1]
ScopeType[0..1]
Planned[0..1]
Keywords[0..*]
Consequence
1
«group»
DescriptionGroup
Summary[0..1]
Description[0..1]
Detail[0..1]
Advice[0..1]
Internal[0..1]
Images[0..*]
InfoLink[0..*]
Period[0..1]
Condition[0..1]
Severiity[1]
Affects[0..1]
Suitabilities[0..*]
Advice[1]
Blocking[0..1]
Boarding[0..1]
Delay[0..1]
Casualties[0..1]
Easements[0..1]
Extensions[0..1]
Figure 14-5 Situation Main elements
© Copyright Kizoom 2006-2007
Page 74
SIRI Functional Services - UML Diagrams
SITUATION BODY
The SituationBody (Figure 14-6Figure 14-5) shows detailed attributes of a Situation.
RelatedSituation
references
1
1
related to
AbstractSituation
0..*
CreationTime[1] : dateTime
CountryRef[0..1] : CountryEnum
ParticipantRef[1] : ParticipantCode
SituationNumber[1] : SituationIdentifier
RelatedTo[0..*] : RelatedSituation
SituationBody[1] : PtSituationBody
CreationTime[1] : dateTime
CountryRef[0..1] : Country
ParticipantRef[0..1] : ParticipantCode
SituationNumber[1] : SituationIdentifier
SituationVersion[0..1] : SituationVersion
RelatedAs[1] : RelatedEnum
updates
1
0..*
made by
1
0..*
UpdateSituation
status
Verication[1] : VerificationEnum
Progress[1] : SituationProgressEnum
Quality[1] : QualityIndexEnum
«enumeration»
SituationProgressEnum
draft
approvedDraft
open
closing
closed
1
1
actions
1
reason
0..1
Affects
affects
1
Consequence 0..1
0..*
«group»ClassifierGroup
Reason[1] : Reason
ReasonName[0..1] : nlString
Severity[1] : TpegSeverityEnum
Priority[0..1] : integer
Sensitivity[0..1] : SensitivityEnum
Audience[0..1] : AudienceEnum
ReportType[0..1] : TpegReportEnum
ScopeType[0..1] : ScopeEnum
Planned[0..1] : boolean
Keywords[0..*] : string
affects
1
classifiers
1
«enumeration»
QualityIndexEnum
certain
veryReliable
reliable
0..*
probablyReliable
unconfirmed
PublishingActions
SituationSource[1] : SituationSource
0..1
SituationStatus[1] : SituationStatus
TemporalGroup[1] : TemporalGroup
11
ClassifierGroup[1] : ClassifierGroup
DescriptionGroup[0..1] : DescriptionGroup
Affects[0..1] : Affects
Consequences[0..*] : Consequence
PublishingActions[0..1] : PublishingActions
1
Extensions[0..1] : any
consequence
1
«enumeration»
SourceEnum
email
phone
fax
post
feed
radio
tv
web
pager
text
other
1
«group»PtSituationBody
«enumeration»
SensitivityEnum
veryHigh
high
medium
low
veryLow
«enumeration»
VerificationEnum
unknown
unverified
verified
1
Country[0..1] : CountryEnum
SourceType[1] : SourceEnum
Email[0..1] : email
Phone[0..1] : phoneNumber
Fax[0..1] : phoneNumber
Web[0..1] : anyURI
0..1
Other[0..1] : string
source
AgentReference[0..1] : string
TimeOfCommunication[1] : dateTime
ExternalCode[0..1] : string
SituationVersion[0..1] : SituationVersion
UpdateParticipantRef[0..1] : Participant
1
«enumeration»
RelatedEnum
cause
effect
supercedes
supercededBy
association
SituationSource
1
«group»SituationStatus
© 2006 SIRI
body
1
0..*made by
1
Participant
BaseSituation
SIRI Situation
when
description
Period[0..1] : HalfOpenTimestampRange
Condition[0..1] : TpegServiceConditionEnum
Severiity[1] : TpegSeverityEnum
Affects[0..1] : Affects
Suitabilities[0..*] : Suitability
Advice[1] : Advice
Blocking[0..1] : Blocking
Boarding[0..1] : Boarding
Delay[0..1] : duration
Casualties[0..1] : Casualties
Easements[0..1] : Easement
Extensions[0..1] : any
1
*
Reason
«group»DescriptionGroup
«group»TemporalGroup
«enumeration»
ScopeEnum
general
operator
network
route
line
place
stopPlace
stopPlaceComponent
stopPoint
vehicleJourney
datedVehicleJourney
connectionLink
interchange
«enumeration»
TpegReportEnum
unknown
network
route
point
individualService
undefined
Summary[0..1] : DefaultedText
Description[0..1] : DefaultedText
Detail[0..1] : DefaultedText
Advice[0..1] : DefaultedText
Internal[0..1] : DefaultedText
Images[0..*] : Image
InfoLink[0..*] : InfoLink
ValidityPeriod[1] : ValidityPeriod
Repetitions[0..*] : DayType
PublicationWindow[1] : ValidityPeriod
applies
«enumeration»
AudienceEnum
public
staff
emergencyServices
management
stationStaff
infoServices
1 days
0..*
DayType
1
0..1
DefaultedText
ValidityPeriod
nlString[1]
overridden[0..1]
StartTime[1] : dateTime
EndTime[1] : dateTime
1
InfoLink
Image
ImageRef[0..1]
ImageBinary[0..1]
ImageContent[0..1]
0..1 image
Uri[1]
Label[1]
Image[1]
LinkContent[1]
Figure 14-6 SituationExchangeDelivery - SituationBody
© Copyright Kizoom 2006-2007
Page 75
SIRI Functional Services - UML Diagrams
SITUATION AFFECTS SCOPE
The Affects is used to
Operator
0..1
operator
SIRI-SX
Situation
Affects Summary
1
© 2007
0..*
1
0..*
0..*
DatedVehicleJourney
operator
AffectedOperator
1
consequence
PtSituationBody
operators
0..*
1
1
journey
Consequence
operators
Network
affects
affects
1
0..1
0..1
1
network
0..1
0..1 1
operators
1
AffectedVehicleJourney
1
0..*
networks 1
AffectedNetwork
places
1
0..*
TopographicPlace
1
AffectedPlace
1
0..*
place
1
1
components
lines
0..*
Affects
places
1
lines
journeys
0..1
0..*
place
*
1
Place
0..1
AffectedStopPlaceComponent
AffectedScheduledStop
0..1
0..1
1
0..1
links1
StopPlace
AffectedCall
0..*
components
0..*
0..* 1
destinations
AffectedLine
line
calls
1
1
component
StopPlaceComponent
0..1
0..1
stop place 0..1
AffectedStopPlace
11
origins
1
0..*
stop
AffectedConnectionLink
1
1
0..1
0..1
1
to stop
0..1
line
Line
StopPoint
1
line
0..1
1
© Copyright Kizoom 2006-2007
Page 76
SIRI Functional Services - UML Diagrams
SITUATION AFFECTS SCOPE – SCHEDULED JOURNEYS
Figure 14-7 shows detailed attributes for the scope elements used to relate Situations to parts of the
network and to specific journeys.
«group»PtSituationB
ody
10..*
1
0..1
0..1
1
1
affects
AffectedStopPlace
affects
Consequence
1
places
1
SEE AFFECTED
STOP PLACE
0..*
Affects
1
TM-Mdl::Network
networks
TM-Mdl::Operator
0..*0..*
1
network
AffectedOperator
OperatorRef[0..1] : OperatorCode
OperatorName[0..1] : nlString
operators
OperatorShortName[0..1] : nlString
0..*
OperationalUnitRef[0..1] : OperationalUnitCode
Extensions[0..1] : any
1
lines
0..*
0..*
AffectedNetwork
NetworkRef[0..1] : NetworkCode
NetworkName[0..1] : nlString
RoutesAffected[0..1] : nlString
AffectedOperators[0..*] : AffectedOperator
AffectedModes[0..1] : Mode
AffectedLines[0..*] : AffectedLine
Extensions[1] : any
TM-Mdl::DatedVehicleJourney
DatedVehicleJourneyRef[0..1] : DatedVehicleJourneyCode
JourneyName[0..1] : nlString
stops
Operator[0..1] : AffectedOperator
LineRef[0..1] : LineCode
0..*
PublishedLineName[0..1] : nlString
DirectionRef[0..1] : DirectionCode
Origins[0..*] : AffectedScheduledStop
Destinations[0..*] : AffectedScheduledStop
0..1
1
OriginAimedDepartureTime[0..1] : dateTime
DestinationAimedArrivalTime[0..1] : dateTime
Calls[0..*] : AffectedCall
AccessibilityDisruptions[0..*]
0..*
journey FacilityChange[1] : FacilityChange
Extensions[0..1] : any
disruptions
1
mode
0..*
0..*
0..*
0..*
disruptions
1
0..*
AffectedScheduledStop
SX-Mdl::LineSection
0..1
line
0..*
stop
0..*
0..*
TM-Mdl::Line
0..1
AffectedCall
AffectedConnectionLink
Order[1] : integer
CallCondition[0..1] : TpegServiceConditionEnum
VehicleAtStop[0..1] : boolean
AffectedInterchanges[0..*] : AffectedInterchange
TM-Mdl::StopPoint
ConnectingVehicleJourneyRef[0..1] : DatedVehicleJourneyCode
ArrivalTimes[0..1] : ArrivalTimes
1
0..1
ArrivalInfo[0..1] : ArrivalInfo
DepartureTimes[0..1] : DepartureTimes
interchanges DepartureInfo[0..1] : DepartureInfo
stop
HeadwayInfo[0..1] : HeadwayInfo
0..1
ConnectionLinkRef[0..1] : ConnectionLinkCode
ConnectionName[0..1] : nlString
LineRef[0..1] : LineCode
PublishedLineName[0..1] : nlString
ConnectingStopPointName[0..1] : nlString
ConnectingZoneName[0..1] : nlString
ConnectionDirection[0..1]
AffectedLinks[0..*] : nmtoken
Extensions[0..1] : any
«enumeration»
Tpeg-Mdl::TpegInterchangeStatusEnum
unknown
connection
replacement
alternative
connectionNotHeld
connectionHeld
statusOfConnectionUndecided
undefined
*
StopPointRef[0..1] : StopPointCode
StopPointName[0..1] : nlString
PrivateRef[1] : string
Location[0..1] : Location
AffectedModes[0..*] : Mode
TopographicPlaceRef[0..1] : PlaceId
PlaceName[0..1] : nlString
AccessibilityDisruptions[0..*] : AccessibilityDisruption
ConnectionLinks[0..*] : ConnectionLink
Extensions[0..1] : any
0..*
0..* section
«enumeration»
SX-Enm::ConnectionDirectionEnum
both
from
to
1
Association4
LineRef[0..1] : LineCode
PublishedineName[0..1] : nlString
0..*
AffectedOperators[0..*] : AffectedOperator
AffectedDestinations[0..*] : AffectedScheduledStop
Direction[0..1] : DirectionCode
AffectedRoutes[0..*] : RouteCode
AffectedSections[0..*] : SectionCode
Extensions[1] : any
line
TM-Mdl::Direction
1
origins
0..* ACSB-Mdl::AccessibilityDisruption
AffectedLine
0..1
1
0..*
TM-Mdl::Mode
mode
TM-Mdl::Route
0..*
outes
0..*
direction 0..*
0..*
AffectedVehicleJourney
1
journeys
operators
1
0..1
0..*
0..*
AffectedInterchange
InterchangeRef[0..1] : InterchangeCode
InterchangeStopPointRef[0..1] : StopPointCode
InterchangeStopPointName[0..1] : nlString
ConnectingVehicleJourneyRef[0..1] : DatedVehicleJourneyCode
InterchangeStatusType[0..1] : TpegInterchangeStatusEnum
AffectedConnectionLinkRef[0..1] : AffectedConnectionLink
Extensions[0..1] : any
interchange
0..*
1
TM-Mdl::Interchange
Figure 14-7 Affects Scope - Scheduled Journeys
© Copyright Kizoom 2006-2007
Page 77
SIRI Functional Services - UML Diagrams
SITUATION AFFECTS SCOPE STOP PLACE
Figure 14-8 shows detailed attributes for the scope elements used to relate Situations to parts of the
stop place. These can include accessibility properties
AffectedPlace
places
Affects
1
0..*
1
PlaceRef[1] : StopPlaceId
PlaceName[0..1] : nlString
PlaceType[0..1] : NMTOKEN
Extensions[0..1] : any
place
Place
1
0..1
places
StopPlace
AffectedStopPlaceElement
accessibility
AccessibilityDisruption[0..1] : AccessibilityDisruption
0..1place
stop
1 0..*
0..1
1
AccessibilityDisruption
AffectedStopPlace
StopPlaceRef[1] : StopPlaceCode
PlaceName[0..1] : nlString
StopPlaceType[1] : StopPlaceTypeEnum
Components[0..*] : AffectedStopPlaceComponent
NavigationPaths[0..*] : ComponentId
Extensions[0..1] : any
components
SIRI-SX
Situation Affects
- Stop Place
«enumeration»
AccessFacilityEnum
unknown
lift
escalator
travelator
ramp
stairs
shuttle
narrowEntrance
barrier
lowFloorAccess
suitabilities
1
1
0..*
© 2007
Suitability
1
«enumeration»
StopPlaceTypeEnum
airport
railStation
metroStation
coachStation
busStation
shipPort
ferryPort
ferryStop
onStreetBus
onStreetTram
skiLift
other
MobilityImpairedAccess[1] : boolean
Liimitations[0..1]
Suitabilities[0..*] : Suitability
«enumeration»
SuitableEnum
suitable
notSuitable
unknown
UserNeed[1] : UserNeed
Suitable[1] : SuitableEnum
«enumeration»
ComponentTypeEnum
quay
0..*
accessSpace
boardingPosition
stoppingPlace
stoppingPosition
entrance
stopPathLink
accessPathLink
other
AffectedStopPlaceComponent
ComponentRef[1] : ComponentId
ComponentName[0..1] : nlString
ComponentType[1] : ComponentTypeEnum
AccessFeatureType[0..1] : AccessFeatureEnum
Extensions[0..1] : any
component
1
«enumeration»
AccessibilityEnum
true
false
unknown
0..*
0..1
Limitation
StopPlaceComponent
1
level
Level
1
AbstractPathLink
StopPathLink
limitation
AccessPathLink
WheelchairAccess[0..1] : AccessibilityEnum
StepFreeAccess[0..1] : AccessibilityEnum
EscalatorFreeAccess[0..1] : AccessibilityEnum
LiftFreeAccess[0..1] : AccessibilityEnum
AudibleSignsAvailable[0..1] : AccessibilityEnum
VisualSignsAvailable[0..1] : AccessibilityEnum
AbstractStopPlaceSpace
AccessSpace
Quay
BoardingPosition
Figure 14-8 Affects Scope - Stop Place
© Copyright Kizoom 2006-2007
Page 78
SIRI Functional Services - UML Diagrams
15. SIRI COMMON DATA TYPES
COMMON SIRI DATA TYPES – XML SIMPLE TYPES
The SIRI-SX services use XML data types for primitive data types where possible (Figure 15-1).
«datatype»
any
«datatype»
boolean
«datatype»
decimal
XML Data Types
«datatype»
integer
© 2006 SIRI
«datatype»
string
«datatype»
dateTime
«datatype»
date
«datatype»
time
«datatype»
duration
«datatype»
nmtoken
«datatype»
anyURI
«datatype»
lang
«datatype»
Common data types::positiveDuration
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).
ErrorCondition
-Error[1] : AbstractError
-Description[1] : ErrorDescription
AbstractError
1
SIRI
Simple ErrorTypes
-ErrorText[1] : string
1
© 2006 SIRI
CapabilityNotSupportedError
AccessNotAllowedError
NoInfoForTopicError
AllowedResourceUsageExceeded
OtherError
CapabilityCode[1] : NMTOKEN
image
DefaultedText
InfoLink
nlString[1] : nlString
overridden[0..1] : boolean
Uri[1] : any
Label[1] : nlString
Image[1] : Image
LinkContent[1] : LinkContentEnum
SIRI
Complex Data Types
© 2006 SIRI
Location
1
Image
0..1
ImageRef[0..1] : anyURI
ImageBinary[0..1] : any
ImageContent[0..1] : ImageContenEnum
«enumeration»
LinkContentEnum
details
advice
timetable
relatedSite
other
«enumeration»
ImageContenEnum
map
graphic
logo
id[0..1] : NMTOKEN
srsName[0..1] : NMTOKEN
Longitude[0..1] : Longtitude
Latitude[0..1] : Latitude
Coordinates[0..1] : Coordinates
Precision[0..1] : Distance
FacilityChange
HalfOpenTimestampRange
EquipmentAvailability[0..1]
SituationRef[0..1] : SituationCode
MobilityDisruption[0..1]
EquipmentAvailability
0..1
1
EquipmentRef[0..1] : EquipmentCode
Description[0..1] : populatedString
EquipmentStatus[1] : EquipmentStatus
ValidityPeriod[0..1] : HalfOpenTimestampRange
EquipmentTypeRef[0..1] : EquipmentTypeCode
EquipmentFeatures[0..*] : EquipmentFeatureCode
1
StartTime[1] : dateTime
EndTime[0..1] : dateTime
MobilityDisruption
0..1
FramedVehicleJourneyRef
Mode
DataFrameRef[1] : DataFrameCode
DatedVehicleJourneyRef[1] : DatedVehicleJourneyCode
-Mode[1] : VehicleModesEnum
-SubMode[0..1] : TpegSubMode
MobilityImpairedAccess[0..1] : boolean
MobilityFacility[0..1] : MobilityFacility
TpegSubMode
Figure 15-2 UML Diagram of Common SIRI Data Types
© Copyright Kizoom 2006-2007
Page 79
SIRI Functional Services - UML Diagrams
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).
«datatype»
XML Data Types::string
SIRI
Simple DataTypes
«datatype»
XML Data Types::integer
© 2006 SIRI
«datatype»
XML Data Types::nmtoken
«datatype»
XML Data Types::positiveInteger
«datatype»
Common data types::populatedString
«datatype»
Loc Mdl::Longtitude
«datatype»
Common data types::nlString
«datatype»
ParticipantCode
«datatype»
Common data types::distance
«datatype»
Loc Mdl::Bearing
«datatype»
Siri Rqs::MessageQualifier
«datatype»
Loc Mdl::Latitude
«datatype»
Loc Mdl::Coordinates
«datatype»
Siri Rqs::ErrorDescription
«datatype»
Siri Rqs::SubscriptionCode
«datatype»
Siri Rqs::SubscriptionFilterCode
«datatype»
IdentifiedItemCode
«datatype»
Siri Rqs::EndPointAddress
«datatype»
Common data types::versionString
«datatype»
SituationCode
«datatype»
Siri DTs::MonitoringCode
«datatype»
ProductCategoryCode
«datatype»
JourneyPlaceCode
«datatype»
EquipmentFeatureCode
«datatype»
VehicleFeatureCode
«datatype»
VisitNumber
«datatype»
EquipmentTypeCode
«datatype»
FacilityCode
«datatype»
ServiceFeatureCode
«datatype»
TM-DTs::DestinationCode
«datatype»
EquipmentCode
«datatype»
SectionCode
«datatype»
Siri DTs::CleardownCode
Figure 15-3 Common SIRI Simple Data types
Figure 15-4 shows simple data types use din SIRI to identify Transmodel entities.
«datatype»
DataFrameCode
«datatype»
OperationalUnitCode
«datatype»
OperatorCode
«datatype»
NetworkCode
«datatype»
ConnectionLinkCode
«datatype»
LineCode
«datatype»
RouteCode
«datatype»
JourneyPatternCode
«datatype»
BlockCode
SIRI
Identifier Simple DataTypes
For Transmodel entities
«datatype»
TimetableVersionCode
«datatype»
PlaceId
«datatype»
DirectionCode
«datatype»
DatedVehicleJourneyCode
«datatype»
CourseOfJourneyCode
© 2006 SIRI
«datatype»
StopPointCode
«datatype»
VehicleJourneyCode
«datatype»
VehicleCode
«datatype»
IFOPT-DTs::StopPlaceId
«datatype»
ZoneCode
«datatype»
TrainPartCode
«datatype»
InterchangeCode
«datatype»
TrainPartCode
«datatype»
IFOPT-DTs::ComponentId
«datatype»
IFOPT-DTs::StopPlaceCode
Figure 15-4 Common Identifier types used in SIRI for Transmodel entities
© Copyright Kizoom 2006-2007
Page 80
SIRI Functional Services - UML Diagrams
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
SIRI
Enumerations
© 2006 SIRI
«enumeration»
VehicleModesEnum
air
bus
coach
ferry
metro
rail
tram
underground
«enumeration»
DepartureActivityEnum
boarding
noBoarding
passThru
«enumeration»
ArrivalActivityEnum
alighting
noAlighting
passThru
«datatype»
CountryEnum
«enumeration»
OccupancyEnum
full
seatsAvailable
standingAvailable
«enumeration»
ProgressRateEnum
noProgress
slowProgress
normalProgress
fastProgress
unknown
«datatype»
EquipmentStatus
«enumeration»
TimeStatusEnum
early
onTime
delayed
arrived
cancelled
noReport
«enumeration»
VM-Mdl::VmDetailLevelEnum
minimum
basic
normal
calls
«enumeration»
FacilityStatusEnum
unknown
available
notAvailable
partiallyAvailable
added
removed
«enumeration»
SM-Mdl::SmDetailLevelEnum
minimum
basic
normal
calls
full
«datatype»
MobilityFacility
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.
SIRI-SX
Enumerations
© 2006 SIRI
«enumeration»
RelatedEnum
cause
effect
supercedes
supercededBy
association
«enumeration»
SituationProgressEnum
draft
approvedDraft
open
closing
closed
«enumeration»
QualityIndexEnum
certain
veryReliable
reliable
probablyReliable
unconfirmed
«enumeration»
AudienceEnum
public
staff
emergencyServices
management
stationStaff
infoServices
«enumeration»
ConnectionDirectionEnum
both
from
to
«enumeration»
SituationNatureEnum
planned
unplanned
both
«enumeration»
SensitivityEnum
veryHigh
high
medium
low
veryLow
«enumeration»
ImageContenEnum
map
graphic
logo
«enumeration»
VerificationEnum
unknown
unverified
verified
«enumeration»
LinkContentEnum
details
advice
timetable
relatedSite
other
«enumeration»
ScopeEnum
general
operator
network
route
line
place
stopPlace
stopPlaceComponent
stopPoint
vehicleJourney
datedVehicleJourney
connectionLink
interchange
Figure 15-6 UML Diagram of SIRI-SX Enumerations
© Copyright Kizoom 2006-2007
Page 81
SIRI Functional Services - UML Diagrams
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.
IFOPT
Enumerations
© 2006 SIRI
«enumeration»
CongestionEnum
noWaiting
queue
crowding
full
«enumeration»
StopPlaceTypeEnum
airport
railStation
metroStation
coachStation
busStation
shipPort
ferryPort
ferryStop
onStreetBus
onStreetTram
skiLift
other
«enumeration»
AcccessSpaceEnum
concours
bookingHall
forecourt
underpass
overpass
gallery
garage
shop
«enumeration»
ComponentTypeEnum
quay
accessSpace
boardingPosition
stoppingPlace
stoppingPosition
entrance
stopPathLink
accessPathLink
other
«enumeration»
QuayTypeEnum
airlineGate
railPlatform
metroPlatform
coachStop
busStop
boatQuay
ferryLanding
tramStop
telecabinPlatform
taxiStand
setDownPlace
unknown
other
«enumeration»
BoardingPositionTypeEnum
doorFromAirlineGate
positionOnRailPlatform
positionOnMetroPlatform
positionAtTramStop
positionAtBusStop
positionAtCoachStop
ferryGangway
boatGangway
telecabinGangway
taxiBay
carSetDownPoint
unknown
other
«enumeration»
AccessFeatureEnum
lift
escalator
travelator
ramp
stairs
shuttle
barrier
narrowEntrance
confinedSpace
queueManagement
none
unknown
«enumeration»
AccessModesEnum
foot
bicycle
car
taxi
shuttle
Figure 15-7 UML Diagram of IFOPT Stop Place Enumerations
© Copyright Kizoom 2006-2007
Page 82
SIRI Functional Services - UML Diagrams
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»
TpegDayTypeEnum
unknown
monday
tuesday
wednesday
thursday
friday
saturday
sunday
mondayToFriday
mondayToSaturday
weekends
publicHoliday
holiday
regionalHoliday
nationalHoliday
sundaysAndPublicHolidays
schooldays
everyday
undefinedDayType
«enumeration»
TpegSeverityEnum
unknown
verySlight
slight
normal
severe
verySevere
noImpact
undefined
Tpeg pti-26
TPEG
Miscellaneous
Enumerations
«enumeration»
TpegServiceConditionEnum
unknown
altered
cancelled
delayed
diverted
noService
disrupted
additionalService
specialService
onTime
normalService
intermittentService
shortFormedService
fullLengthService
extendedService
splitingTrain
replacementTransport
arrivesEarly
shuttleService
replacementService
undefinedServiceInformation
© 2007 SIRI
TPEG pti_34
tpeg pti_13
tpeg pti 31
«enumeration»
TpegInterchangeStatusEnum
unknown
connection
replacement
alternative
connectionNotHeld
connectionHeld
statusOfConnectionUndecided
undefined
«enumeration»
TpegReportEnum
unknown
network
route
point
individualService
undefined
«enumeration»
TpegTicketRestrictionEnum
unknown
allTicketClassesValid
fullFareOnly
certainTicketsOnly
ticketWithReservation
specialFare
onlyTicketsOfSpecifiedOperator
noRestrictions
noOffPeakTickets
noWeekendReturnTickets
noReducedFareTickets
unknwonTicketRestriction
tpeg pti_27
tpeg pti_25
«enumeration»
TpegRoutePointEnum
unknown
startPoint
destination
stop
via
notStopping
temporaryStop
temporarilyNotStopping
exceptionalStop
additionalStop
requestStop
frontTrainDestination
rearTrainDestination
throughServiceDestination
notVia
alteredStartPoint
alteredDestination
undefinedRoutePoint
tpeg pti_5
Figure 15-8 UML Diagram of TPEG Enumerations
© Copyright Kizoom 2006-2007
Page 83
SIRI Functional Services - UML Diagrams
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.
TPEG pti02 + loc13
«enumeration»
TpegRailSubmodeEnum
unknown
highSpeedRailService
LongDistanceRailService
interRegionalRailService
carTransportRailService
sleeperRailService
regionalRail
touristRailway
railShuttle
suburbanRailway
replacementRailService
specialTrainService
lorryTransportRailService
allRailServices
crossCountryRailService
vehiclRailTransportService
rackAndPinionRailway
additionalTrainService
undefined
local
international
TPEG pti05
«enumeration»
TpegVehicleModesEnum
+air
+bus
+coach
+ferry
+metro
+rail
+tram
+underground
«enumeration»
TpegBusSubmodeEnum
unknown
regionalBus
expressBus
bus
localBus
nightBus
postBus
specialNeedsBus
mobilityBus
mobilityBusForRegisteredDisabled
sightseeingBus
shuttleBus
schoolBus
schoolAndPublicServiceBus
railReplacementBus
demandAndResponseBus
airportLinkBus
undefined
TPEG pti06
TPEG pti04
«enumeration»
TpegMetroSubmodeEnum
unknown
metro
tube
urbanRailway
allRailServices
undefined
TPEG pti11
«enumeration»
TpegTaxiSubmodeEnum
unknown
communalTaxi
waterTaxi
railTaxi
bikeTaxi
blackCab
miniCab
allTaxiServices
undefined
«enumeration»
TpegTramSubmodeEnum
unknown
cityTram
localTramService
regionalTram
sightseeingTram
shuttleTram
allTramServices
undefined
TPEG pti10
TPEG pti03
«enumeration»
TpegCoachSubmodeEnum
unknown
internationalCoachService
nationalCoachService
shuttleCoachService
regionalCoachService
specialCoachService
sightseeingCoachService
tourist
commuterCoachService
allCoachServices
undefined
TPEG pti08
«enumeration»
TpegAirSubmodeEnum
unknown
internationalFlight
domesticFlight
intercontinentalFlight
domesticScheduledFlight
shuttleFlight
intercontinentalCharteFlight
internationalCharteFlight
roundTripCharterFlight
sightseeingFlight
helicopterService
domesticCharterFlight
SchengenAreaFlight
airshipService
allAirServices
shortHaulInternationalFlight
undefined
TPEG pti09 + loc14
«enumeration»
TpegFunicularSubmodeEnum
unknown
funicular
allFunicularServices
undefined
TPEG pti07
«enumeration»
TpegWaterSubmodeEnum
unknown
internationalCarFerryService
nationalCarFerryService
regionalCarFerryService
localCarFerryService
internationalPassengerFerry
nationalPassengerFerry
regionalPassengerFerry
localPassengerFerry
postBoat
trainFerry
roadFerryLink
airportBoatLink
highSpeedVehicleService
highSpeedPassengerService
sightseeingService
schoolBoat
cableFerry
riverBus
scheduledFerry
shuttleFerryService
allWaterTransportServices
undefined
«enumeration»
TpegTelecabineSubmodeEnum
unknown
telecabine
allFunicularServices
undefined
cableCar
lift
chairLift
dragLift
smallTelecabin
allTelecabinServices
eggLift
mineralBuckets
undefined
telecabinLink
Figure 15-9 UML Diagram of Tpeg submodes
© Copyright Kizoom 2006-2007
Page 84
SIRI Functional Services - UML Diagrams
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 indicate 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.
© Copyright Kizoom 2006-2007
Page 85
SIRI Functional Services - UML Diagrams

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 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’. For example, the
DatedCalls attribute in Figure 16-2 below.

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’. For example, the StopPointRef attribute in Figure 16-2 below is of type StopPointCode.
In addition
© Copyright Kizoom 2006-2007
Page 86
SIRI Functional Services - UML Diagrams
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 STRCUTURES 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. In the UML diagrams for SIRI
we therefore generally show an attribute with which to implement the 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).
© Copyright Kizoom 2006-2007
Page 87
SIRI Functional Services - UML Diagrams
Route
route
DirectionRef[1] : DirectionCode
RouteCode[1] : RouteCode
0..1
VehicleJourney
pattern
*
Notation – #1
Conventional use of
Inline attributes
JourneyPatternRef[1..1] : JourneyPatternCode
0..*
JourneyPattern
*
DatedVehicleJourney
line
Line
LineCode[1]
PublishedLineName[1]
block 0..*
0..*
0..1
0..1
Block
run
1
StopPoint
dated calls
runs
0..*
1
0..1
*
© 2007 Kizoom
DatedVehicleJourneyCode[1] : DatedVehicleJourneyCode
ExtraJourney[0..1] : boolean
Cancellation[0..1] : boolean
BlockRef[0..1] : BlockCode
CourseOfJourneyRef[0..1] : CourseOfJourneyCode
2..*
1
DatedCall
CourseOfJourney
«enumeration»
ArrivalActivityEnum
alighting
noAlighting
passThru
StopPointRef[1] : StopPointCode
Order[0..1] : integer
StopPointName[0..1] : nlString
DestinationDisplay[1] : nlString
AimedArrivalTime[0..1] : dateTime
ArrivalPlatformName[0..1] : nlString
ArrivalBoardingActivity[0..1] : ArrivalActivityEnum
AimedDepartureTime[0..1] : dateTime
DeparturePlatformName[0..1] : nlString
DepartureBoardingActivity[0..1] : DepartureActivityEnum
stop
0..*
«enumeration»
DepartureActivityEnum
boarding
noBoarding
passThru
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.
Route
JourneyPattern
DirectionRef : DirectionCode
RouteCode : RouteCode
i fo
i fo
0..1
1
1
0..*
«group»JourneyPatternInfo
JourneyPatternRef : JourneyPatternCode pattern
0..1
RouteRef : RouteCode
DirectionRef : DirectionCode
0..*
1
block
0..1
0..*
run
Block
1
runs
*
pattern
*
0..*
VehicleJourney
Notation – #4
Use of aggregations to encapsulate
attributes, & named entries for XML
structures
JourneyPatternRef : JourneyPatternCode
DatedVehicleJourney
DatedVehicleJourneyCode[1] : DatedVehicleJourneyCode
JourneyPatternInfo[0..1] : JourneyPatternInfo
ExtraJourney[0..1] : boolean
Cancellation[0..1] : boolean
BlockRef[0..1] : BlockCode
CourseOfJourneyRef[0..1] : CourseOfJourneyCode
Calls[0..*] : DatedCall
Extensions[0..1] : any
dated calls
0..1
1
1
0..*
«group»StopPointInSequence
stop point
2..*
CourseOfJourney
«enumeration»
DepartureActivityEnum
boarding
noBoarding
passThru
0..1
stop
StopPoint
0..1
StopPointRef[1] : StopPointCode
Order[0..1] : integer
StopPointName[0..1]
DatedCall
call departure 1
StopPointInSequence[1] : StopPointInSequence
DestinationDisplay[0..1] : nlString
AimedArrivalInfo[0..1] : AimedArrivalInfo
AimedDepartureInfo[0..1] : AimedDepartureInfo
Extensions[0..1] : any
0..*
call arrival
1
0..1
«enumeration»
ArrivalActivityEnum
alighting
noAlighting
passThru
«group»AimedDepartureInfo
«group»AimedArrivalInfo
AimedDepartureTime[0..1] : dateTime
DeparturePlatformName[0..1] : nlString
DepartureBoardingActivity[0..1] : DepartureActivityEnum
AimedArrivalTime[0..1] : dateTime
ArrivalPlatformName[0..1] : nlString
ArrivalBoardingActivity[0..1] : ArrivalActivityEnum
Figure 16-2 Explicit representation of references and of groups
© Copyright Kizoom 2006-2007
Page 88
SIRI Functional Services - UML Diagrams
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>
<!—Stop point in sequence Group -->
<StopPointRef>HLTS00102</StopPointRef>
<StopName>Hospital</StopName>
<DestinationDisplay>Station</DestinationDisplay>

<AimedArrivalTime>2001-12-17T09:38:47-05:00</AimedArrivalTime>

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

<DatedCall>
<!—Stop point in sequence Group -->
<StopPointRef>HLTS00103</StopPointRef>
< StopName>Main Station</ StopName >

<AimedArrivalTime>2001-12-17T09:40:47-05:00</AimedArrivalTime>

<AimedDepartureTime>2001-12-17T09:43:47-05:00</AimedDepartureTime>
<DepartureBoardingActivity>NoBoarding</DepartureBoardingActivity>
</DatedCall>
…..
</Calls>
</DatedVehicleJourney>
</DatedTimetableVersionFrame>
© Copyright Kizoom 2006-2007
Page 89
SIRI Functional Services - UML Diagrams
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
© Copyright Kizoom 2006-2007
Page 90

Download Report

SIRI-SM - Easily

Paperzz.com

Your Paperzz