.
Kizoom Limited, 109-123 Clifton Street, London EC2A 4LD. Tel: +44 207 749 2670
SIRI Handbook
& Functional Service Diagrams
Version 0.13
2008/01/10 Njsk Kizoom
DRAFT
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 2
Control sheet
Version control
Date Author Version Description of changes
2006/03/02 Nick Knowles, V.01 Previous Draft
2007/04/15 Nick Knowles, V.02 Word Draft
2007/10/11 Nick Knowles, V.07 Word Draft
2008/01/11 Nick Knowles, V.12 Revised Draft
2008/01/11 Nick Knowles, V.14 Revised Draft
Document automation & Copyright notice
Kizoom Ltd 107-109 Clifton Street, London EC2A 4LD
Telephone: 207 749 2670
Company Registration Number : 3745127
© Copyright 2007, 2008 Kizoom Limited:
All rights Reserved.
Author:
Nicholas Knowles
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 3
Table of Contents
1. Introduction.................................................................................................................................... 8
Acknowledgements ........................................................................................................................ 8
References ..................................................................................................................................... 8
2. Introduction to SIRI ...................................................................................................................... 10
What is SIRI? ................................................................................................................................ 10
What Functional Services are available? ....................................................................................... 11
3. Use of SIRI Services....................................................................................................................... 13
Separation of Concerns................................................................................................................. 14
Communications & message transport ........................................................................................ 14
Roles & Patterns of Interaction ..................................................................................................... 14
Request/Response for a SIRI Functional SERVICE ........................................................................ 15
Publish/Subscribe for a SIRI Functional SERVICE.......................................................................... 15
Publish/Subscribe with Separate Notification & Fetched Delivery .............................................. 16
XML Example of a SIRI Functional Service Request & Delivery ....................................................... 16
Stop Monitoring Request Example............................................................................................... 17
Stop Monitoring Request Delivery Example................................................................................. 17
Stop Monitoring Subscription Request Example.......................................................................... 18
Stop Monitoring Subscription Delivery Example.......................................................................... 18
SIRI & Transmodel ........................................................................................................................ 20
Relationship of SIRI to TRANSMODEL........................................................................................... 20
Transmodel entities relevant for SIRI........................................................................................... 21
Stop Places - SIRI & IFOPT ............................................................................................................. 23
Participant identifiers, Message & Subscription Management....................................................... 24
Request Response Entities & Message Elements......................................................................... 24
publish Subscribe message elements........................................................................................... 26
Recovery & Restart....................................................................................................................... 28
What does a SIRI Implementation require? ................................................................................... 28
4. Service Descriptions ..................................................................................................................... 29
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 4
Organisation................................................................................................................................. 29
Functional Requests & responses.................................................................................................. 29
5. SIRI Stop Monitoring (SM)............................................................................................................ 31
SIRI-SM: Subscription & Request................................................................................................... 31
StopMonitoringRequest Summary ............................................................................................... 31
StopMonitoringRequest Detail ..................................................................................................... 32
SIRI-SM: Delivery .......................................................................................................................... 33
StopMonitoringDelivery Summary ............................................................................................... 33
StopMonitoringDelivery Detail ..................................................................................................... 34
Use of MonitoredVehicleJourney Element for SIRI-SM................................................................ 36
Examples of Live services that USe SIRI-SM................................................................................... 40
Map based web departure boards............................................................................................... 40
WAP mobile departure boards..................................................................................................... 40
SMS departure boards.................................................................................................................. 40
6. SIRI Vehicle Monitoring (VM) ....................................................................................................... 41
SIRI-VM: Subscription & Request .................................................................................................. 41
VehicleMonitoringRequest Summary........................................................................................... 41
VehicleMonitoringRequest Detail................................................................................................. 42
SIRI-VM: Delivery.......................................................................................................................... 43
VehicleMonitoringDelivery Summary........................................................................................... 43
Use of MonitoredVehicleJourney Element for SIRI-VM ............................................................... 44
VehicleMonitoringDelivery Detail................................................................................................. 45
7. SIRI ProductionTimetable (PT) ...................................................................................................... 46
SIRI-PT: Subscription & Request.................................................................................................... 46
ProductionTimetableRequest Summary....................................................................................... 46
ProductionTimetableRequest Detail............................................................................................. 47
SIRI-PT: Delivery ........................................................................................................................... 48
ProductionTimetableDelivery Summary....................................................................................... 48
ProductionTimetableDelivery Detail............................................................................................. 49
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 5
8. SIRI EstimatedTimetable (ET) ....................................................................................................... 50
SIRI-ET: Subscription & Request .................................................................................................... 50
EstimatedTimetableRequest Summary ........................................................................................ 50
EstimatedTimetableRequest Detail .............................................................................................. 51
SIRI-ET: Delivery ........................................................................................................................... 51
EstimatedTimetableDelivery Summary ........................................................................................ 52
EstimatedTimetableDelivery Detail .............................................................................................. 53
9. SIRI Stop Timetable (ST)................................................................................................................ 54
SIRI-ST: Subscription & Request .................................................................................................... 54
StopTimetableRequest Summary ................................................................................................. 54
StopTimetableRequest Detail ....................................................................................................... 55
SIRI-ST: Delivery ........................................................................................................................... 56
StopTimetableDelivery Summary ................................................................................................. 56
StopTimetableDelivery Detail ....................................................................................................... 57
10. SIRI ConnectionTimetable (CT) ..................................................................................................... 58
SIRI-CT: Subscription & Request.................................................................................................... 58
ConnectionTimetableRequest Summary ...................................................................................... 58
ConnectionTimetableRequest Detail ............................................................................................ 59
SIRI-CT: Delivery ........................................................................................................................... 60
ConnectionTimetableDelivery Summary ...................................................................................... 60
ConnectionTimetableDelivery Detail ............................................................................................ 61
11. SIRI ConnectionMonitoring (CM).................................................................................................. 62
SIRI-CM: Subscription & Request .................................................................................................. 62
ConnectionMonitoringRequest Summary .................................................................................... 62
ConnectionMonitoringRequest Detail .......................................................................................... 63
SIRI-CM: Delivery.......................................................................................................................... 63
ConnectionMonitoringDelivery Summary .................................................................................... 64
ConnectionMonitoringDelivery Detail .......................................................................................... 65
12. SIRI GeneralMessage (GM)........................................................................................................... 66
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 6
SIRI-GM: Subscription & Request .................................................................................................. 66
GeneralMessageRequest Summary.............................................................................................. 66
GeneralMessageRequest Detail ................................................................................................... 67
SIRI-GM: Delivery ......................................................................................................................... 68
GeneralMessageDelivery Summary ............................................................................................. 68
GeneralMessageDelivery Detail ................................................................................................... 69
13. SIRI FacilityMonitoring (FM) DRAFT ............................................................................................. 70
SIRI-FM: Subscription & Request................................................................................................... 70
FacilityMonitoringRequest Summary ........................................................................................... 70
FacilityMonitoringRequest Detail ................................................................................................. 70
SIRI-FM: Delivery .......................................................................................................................... 70
FacilityMonitoringDelviery Summary ........................................................................................... 70
FacilityMonitoringDelviery Detail ................................................................................................. 70
14. SIRI SituationExchange (SX) DRAFT .............................................................................................. 71
SIRI-SX: Subscription & Request.................................................................................................... 71
SituationExchangeRequest Summary........................................................................................... 71
SituationExchangeRequest Detail................................................................................................. 72
SIRI-SX: Delivery ........................................................................................................................... 72
SituationExchangeDelivery Summary........................................................................................... 73
SituationExchangeDelivery Detail................................................................................................. 74
Situation Model............................................................................................................................ 75
15. SIRI Common Data Types ............................................................................................................. 80
Common SIRI Data Types XML Simple Types............................................................................... 80
Common SIRI Data Types .............................................................................................................. 80
Common SIRI SImPLE Data Types Codes & Identifiers ................................................................. 81
Common General SIRI Enumerations............................................................................................. 82
SIRI-SX Enumerations ................................................................................................................... 83
IFOPT Enumerations for SIRI-SX .................................................................................................... 84
TPEG Miscellaneous Enumerations for SIRI-SX ............................................................................... 85
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 7
TPEG Mode Enumerations ............................................................................................................ 86
16. Annex A Notation ......................................................................................................................... 87
Entities......................................................................................................................................... 87
Enumerations ............................................................................................................................... 87
Groups ......................................................................................................................................... 87
Notes ........................................................................................................................................... 87
Relationships................................................................................................................................ 87
Use of Colour................................................................................................................................ 88
Serialisation: Containment & Reference........................................................................................ 88
Alternative Representations of XML Strcutures in UML .............................................................. 89
XML Fragment for Example.......................................................................................................... 91
Order of Attributes ....................................................................................................................... 92
Direction of Reading ..................................................................................................................... 92
Simple Data Types ........................................................................................................................ 92
Reusable Complex Data Types ...................................................................................................... 92
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 8
1. INTRODUCTION
This SIRI Handbook provides a short overview of the CEN SIRI (Service Interface for Real Time Information) technical specification and of the individual SIRI functional services.
It is intended to provide both an introduction to SIRI for technical readers and a quick reference guide for developers who are already familiar with SIRI, but wish to check particular points of detail. It does not cover a number of more detailed aspects of SIRI (for example capability discovery, access controls, etc).
A particular purpose of the handbook is to illustrate the relationship between SIRI and Transmodel by diagramming the SIRI message content in such a way that the reference to Transmodel elements is explicit.
Another goal of this handbook is make understanding a simple use of SIRI for common applications as accessible as possible. As a technical standard intended to support many different implementations and countries, and many different applications and usages, SIRI has a large number of features and optional capabilities. Consequently it requires a large specification. Nonetheless, commonly required basic real-time services, such as stop departures or timetable exchange can be understood and implemented simply in SIRI, and this guide is intended to highlight such straightforward uses.
The guide assumes a technical knowledge of XML and web services. and of data modelling with UML notation.
ACKNOWLEDGEMENTS
This document is based on the SIRI technical specification which was developed with sponsorship from VDV, RTIG, Department of Transport and other organizations.
This handbook & diagrams have been prepared & provided by Kizoom.
REFERENCES
SIRI Specification Service interface for real-time information relating to public transport operations
o CEN/TS 00278181-1 Part 1: Introduction
o CEN/TS 00278181-2 Part 2: Communications infrastructure
o CEN/TS 00278181-3 Part 3: Functional Service Interfaces
SIRI Schema
o http://www.siri.org.uk/schema/1.2/siri.xsd
SIRI White Paper
o http://www.siri.org.uk/
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 9
Transmodel
o CEN TC 278 ENV 12896 Reference Data Model for Public Transport
IFOPT
o CEN/TS 00278207 Identification of Fixed Objects in Public Transport
TPEG
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 10
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
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 11
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.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 12
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
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 13
3. USE OF SIRI SERVICES
All the SIRI Functional services follow a common design pattern.
SIRI is for the exchange of data between participant services. The server which provides the data is the Producer. The server which obtains the data is the Consumer.
The same servers may sustain more than one different SIRI functional service, and support either or both Consumer and Producer roles as appropriate. The Producer service itself may be broken down into further roles (e.g. publisher, notification producer) though a Consumer does not need to be aware of these constituent roles.
Each functional service has unique endpoints, the addresses at which the service can be found.
Each Participant, whether consumer or producer, has a unique participant identifier.
Payload content is separated from message management content.
Content may be obtained from a Producer either by an immediate direct request /response interaction, or by an asynchronous publish / subscribe interaction. In both cases the same set of request parameters are supported to specify the desired response content; for a subscription the request is wrapped in an additional subscription request element.
Data exchanged by SIRI services may either be used as input to other computations, or be rendered into end user information views in any one of a number of media: e.g. web (HTML, javascript, etc) , WAP (xHTML), SMS, Smartphones (j2ME, etc) nor Voice (VML etc).
Figure 3-1 illustrates the concept of using multiple SIRI services to connect up different types of PT Information application, for example AVMS, Journey Planners, Incident Capture systems, Web delivery of stop departure and incidents, alerts, etc
5
Example use of SIRI Services
AVMS
JP
ICS ICS Alerts
PTET
STSM
GMSGMS
GMS GMS
PT
AVMS
PTET
STSM
Web& Mobile
SM
ET
SM
SM
GMS
GMS
ETVM
VM
Figure 3-1 Example of use of Services
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 14
Another common use of SIRI would be to separate the load of the real-time systems that manage and operate the public transport from the wider passenger information systems that distribute the data. Thus for example, a SIRI push service could send real-time predictions from the AVMS system to a separate service that supports passenger queries by web and mobile. This allows the latter to be scaled without affecting the reliability of the operational system.
SEPARATION OF CONCERNS
SIRI is designed to separate different software architectural concerns, in particular for communications/content and for scaling.
COMMUNICATIONS & MESSAGE TRANSPORT
SIRI separates message content from message transport related elements so that it may be used with different methods of communication, for example XML over http, XML over SOAP/WSDL. Although a default method of http is currently used, it would be possible to use the SIRI content model, with quite different transport for example TCP IP sockets.
In order to specify an individual SIRI functional service (or indeed any web service), three different aspects of the service need to be specified; (i) the data content model for SIRI based on Transmodel; (ii) the Communications Transport protocol used to serialise and exchange messages (for example, http & XML) and; (iii) the exchange behaviour the rules for use of the each functional protocol as a dynamic sequence of messages subject to certain application dependent behaviour. Figure 3-2 illustrates the concept of separation of concerns. In SIRI the Data content is described as XML messages. In addition, the variables controlling the parameterised parts of the exchange behaviour are specified as XML values in a configuration or capability description.
4
Separation of concerns
DataContent
ExchangeBehaviour
TransportProtocol
well-defined interactionswith XML schemaRepresentations
parameterising behaviour
Independent e.g.HTTP POST,
SOAP.
definedXML SchemaFor payload
Figure 3-2 Separation of Concerns
ROLES & PATTERNS OF INTERACTION
SIRI can be regarded as a software framework: all the SIRI Functional Services are based on common patterns of interaction, populated with specific messages and data elements specific to a particular service. These patterns distinguish the various software roles which occur in real-time data exchange, for example Consumer, Producer, Notification Producer, Subscriber - even if these are combined on a single server for a particular implementation. The main patterns can be summarized as follows:
Functional Service Request Response.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 15
Functional Service Subscription with asynchronous Direct Delivery.
Functional Service Subscription with asynchronous Notification & Fetched Delivery.
REQUEST/ RESPONSE FOR A SIRI FUNCTIONAL SERVICE
For the Request / Response interaction, the Consumer makes a Functional Service Request to the Producer, and receives a Functional Service Delivery message in response. The Functional Service Request may state the filtering criteria as Topics (the desired domain element references) and Policies (criteria as to how the results are to be filtered. The Topics and Policies depend on the specific functional service.
Figure 3-3 Sequence Diagram of Request Response Interaction
A Functional Service Request is always for a specific SIRI service, e.g. Stop Monitoring, General Message, etc. Note that the request / response pattern is also widely in SIRI for the exchange of information as pairs of messages, for example for status checking, to create subscriptions, etc.
PUBLISH/ SUBSCRIBE FOR A SIRI FUNCTIONAL SERVICE
For the Publish / Subscribe interaction, a Subscriber makes a Subscription Request to the Producer, which creates a Subscription for a Consumer (usually but not necessarily the same server as the Consumer) for the requested lease period for a specified Functional Service Request and Subscription Policy The Producer will subsequently send one or more asynchronous Delivery messages if the Request criteria are met and continue doing so in accordance with the subscription policy, up to the end of the lease. The Filtering criteria can include change thresholds or hysteresis values. The Subscription will eventually expire or be terminated.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 16
Figure 3-4 Sequence Diagram of Publish Subscribe Interaction
PUBLISH/ SUBSCRIBE WITH SEPARATE NOTIFICATION & FETCHED DELIVERY
In the simplest use, SIRI services follow of the normal web service paradigm of direct delivery, returning content in response to a request or a subscription. To allow additional optimisation of bandwidth and device queuing, and to provide compatibility with legacy systems, SIRI also supports an additional delivery variant of fetched delivery in which data is returned in two steps: first a notification message from Producer to Consumer that data is available, then a Request/ Response interaction from Consumer to Producer to fetch the data using a delivery message. The payload content of the delivery message is the same as for the delivery of a direct response
Subscriber NotificationProducer NotificationConsumer
SubscriptionRequest(XxxSubscription)
Publish / Subscribe With Fetched Delivery
Subscription Manager
terminate
DataReadyResponse
DataReadyNotification
DataSupplyRequest
DataSupplyDelivery
SubscriptionResponse
TerminationRequest
TerminationResponse
Figure 3-5 Sequence Diagram of Publish Subscribe Interaction with Fetched Delivery
XML EXAMPLE OF A SIRI FUNCTIONAL SERVICE REQUEST & DELIVERY
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 17
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 >
<!-- All LINE77services from stop EH00001to destination PLACE457 in the next 30 minutes-->
<RequestTimestamp>2004-12-17T09:30:47-05:00</RequestTimestamp>
<MessageIdentifier>NDR06756</MessageIdentifier>
<!--=======TOPIC ===================================== -->
<PreviewInterval>P30M</PreviewInterval>
<MonitoringRef> HLTST011</MonitoringRef>
<!--=======POLICY==========================================-->
<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>
<!--=======HEADER================================================== -->
<ResponseTimestamp>2004-12-17T09:30:46-05:00</ResponseTimestamp>
<ProducerRef>KUBRICK</ProducerRef>
<!--=======PAYLOAD============================================== -->
<StopMonitoringDelivery version="0.1d">
<ResponseTimestamp>2004-12-17T09:30:47-05:00</ResponseTimestamp>
<RequestMessageRef>NDR06756</RequestMessageRef>
<!--====FIRST ARRIVAL ============================================ -->
<MonitoredStopVisit>
<RecordedAtTime>2004-12-17T09:25:46-05:00</RecordedAtTime>
<MonitoringRef>HLTST011</MonitoringRef>
<MonitoredVehicleJourney>
<!-- JOURNEY IDENTITY GROUP -->
<LineRef>Line123</LineRef>
<DirectionRef>Out</DirectionRef>
<FramedVehicleJourneyRef>
<DataFrameRef>2004-12-17</DataFrameRef>
<DatedVehicleJourneyRef>03567</DatedVehicleJourneyRef>
</FramedVehicleJourneyRef>
<!-- JOURNEY PATTERN INFO GROUP -->
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 18
<PublishedLineName>123</PublishedLineName>
<DestinationName>Paradise Park</DestinationName>
<VehicleRef>VEH987654</VehicleRef>
<! CALL AT STOP -->
<MonitoredCall>
<VisitNumber>0014</VisitNumber>
<VehicleAtStop>false</VehicleAtStop>
<!-- STOP MONITORING TIMES GROUP -->
<AimedArrivalTime>2004-12-17T09:40:46-05:00</AimedArrivalTime>
<ExpectedArrivalTime>2004-12-17T09:40:46-05:00</ExpectedArrivalTime>
<AimedDepartureTime>2004-12-17T09:42:47-05:00</AimedDepartureTime>
<ExpectedDepartureTime>2004-12-17T09:40:47-05:00</ExpectedDepartureTime>
</MonitoredCall>
<NextStopPointRef>HLTST012</NextStopPointRef>
</MonitoredVehicleJourney>
</MonitoredStopVisit>
</StopMonitoringDelivery>
</ServiceDelivery>
STOP MONITORING SUBSCRIPTION REQUEST EXAMPLE
The following further example shows a StopMonitoringSubscriptionRequest to set up a subscription to be sent updates for a stop asynchronously. It embeds a StopMonitoringRequest which specifies the selection criteria - to see all departures for LINE23 from stop POIT5678 for up to 30 minutes ahead, including the calling pattern. It adds some values to set the subscription policy: updates are only sent if the values have changed by more than 2 Minutes. The producer would return
<SubscriptionRequest>
<RequestorRef>NADER</RequestorRef>
<RequestTimestamp>2004-12-17T09:30:47-05:00</RequestTimestamp>
<!-- All Line23 services from stop POIT5678 in the next 30 mins-->
<StopMonitoringSubscriptionRequest>
<SubscriptionIdentifier>000235</SubscriptionIdentifier>
<InitialTerminationTime>2004-12-17T15:30:47-05:01</InitialTerminationTime>
<StopMonitoringRequest version= 1.0 >
<!--=======TOPIC ===================================== -->
<RequestTimestamp>2004-12-17T09:30:47-05:06</RequestTimestamp>
<PreviewInterval>PT30M</PreviewInterval>
<MonitoringRef>POIT5678</MonitoringRef>
<LineRef>LINE23</LineRef>
<!--=======POLICY==========================================-->
<StopMonitoringDetailLevel>calls</StopMonitoringDetailLevel>
</StopMonitoringRequest>
<! SUBSCRIPTION POLICY -->
<ChangeBeforeUpdates>PT2M</ChangeBeforeUpdates>
</StopMonitoringSubscriptionRequest>
</SubscriptionRequest>
STOP MONITORING SUBSCRIPTION DELIVERY EXAMPLE
The following is an example of a StopMonitoringDelivery in response to a StopMonitoring-SubscriptionRequest. It is almost identical to the earlier response to a StopMonitoringRequest, but also includes subscription identifier data.
<ServiceDelivery>
<!--=======HEADER================================================== -->
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 19
<ResponseTimestamp>2004-12-17T09:30:46-05:00</ResponseTimestamp>
<ProducerRef>KUBRICK</ProducerRef>
<!--=======PAYLOAD============================================== -->
<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>
<!--====FIRST ARRIVAL ============================================ -->
<MonitoredStopVisit>
<RecordedAtTime>2004-12-17T09:25:46-05:00</RecordedAtTime>
<MonitoringRef>HLTST011</MonitoringRef>
<MonitoredVehicleJourney>
<!-- JOURNEY IDENTITY GROUP -->
<LineRef>Line123</LineRef>
<DirectionRef>Out</DirectionRef>
<FramedVehicleJourneyRef>
<DataFrameRef>2004-12-17</DataFrameRef>
<DatedVehicleJourneyRef>03567</DatedVehicleJourneyRef>
</FramedVehicleJourneyRef>
<!-- JOURNEY PATTERN INFO GROUP -->
<PublishedLineName>123</PublishedLineName>
<DestinationName>Paradise Park</DestinationName>
<VehicleRef>VEH987654</VehicleRef>
<! CALL AT STOP -->
<MonitoredCall>
<VisitNumber>0014</VisitNumber>
<VehicleAtStop>false</VehicleAtStop>
<!-- STOP MONITORING TIMES GROUP -->
<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>
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 20
SIRI & TRANSMODEL
The payload
content of SIRI messages is intended to be compatible with Transmodel, the CEN
Reference Data Model for Public Transport, which sets out common terminology and data abstractions for representing public transport information systems. Thus it should be possible to map data readily from a Transmodel compliant database or application into SIRI messages for data exchange and vice versa, and someone familiar with Transmodel should be able to recognize the application payload elements of the SIRI content model.
SIRI uses Transmodel terms and data elements wherever they exist, and assumes the same cardinalities as Transmodel for any associations between elements.
In some cases, SIRI introduces additional elements or attributes for additional concepts not yet in Transmodel. Mostly this consists of adding additional attributes to existing Transmodel concepts.
In certain other cases, additional elements are introduced in SIRI for convenience to group existing elements, for example, a SIRI Call
element groups the Transmodel entities STOP IN SEQUENCE, various PASSING TIMEs, and other additional attributes. These additional elements do not break conformity with Transmodel but can be regarded as implementation views.
RELATIONSHIP OF SIRI TO TRANSMODEL
Although SIRI is based on Transmodel, there is nonetheless some subtlety involved in understanding the mapping of SIRI content onto Transmodel. Most SIRI functional services are only concerned with exchanging small parts of the information models described by Transmodel - and need to perform this exchange efficiently in real-time. The serialisation of the abstract Transmodel content model into concrete SIRI messages is therefore selective: only those specific elements that are needed for each particular functional service are included; often these will be just the changes to a previously established data set, rather than the full data set. As a consequence, SIRI message content cannot and should not be read as a full or canonical representation of Transmodel, even for the subset of it with which it is concerned. Nor can all the associations of Transmodel be discerned from just their use in SIRI messages.
When exchanging real-time information, there is frequently a need to exchange just one or two properties of an associated entity without exchanging the full definition of that entity. For example, when exchanging information about a vehicle journey it may be useful to know certain attributes of its journey pattern - or of the attributes that can be found though knowledge of that journey pattern by navigating the associations from the vehicle journey to its related entities and onwards. Similarly when exchanging a real-time data for a Call at a stop, it may be useful to include the stop name even though this is properly part of a separate Stop Point entity and could be found through the with a stop point identifier on the call element. To handle this practical requirement, SIRI makes use of groups of elements that include the necessary identifiers of the referenced entities, annotated with selected attributes. In a few cases in SIRI these groupings are implemented as additional entities, for example a SIRI Call. In most other cases the SIRI XMl schema simply includes groups of attributes from associated elements at the appropriate point in payload content (indicated in diagrams by a <<group>> stereotype). Again, such groups should be regarded as implementation artefacts, i.e. views of small parts of the Transmodel model that are
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 21
introduced for convenience, derived through Transmodel associations and which can be mapped back to a full Transmodel representation on source and destination systems.
There is also a need to support different levels of detail for population of the message content for different applications and different implementations. For example, some departure boards will show just a single departure time for each service, others will wish to show for each service a full calling pattern for all previous and onwards stops, with arrival and departure times at each destination. Most attributes and associations are therefore optional in SIRI messages, even if they are mandatory in the underlying data model.
Some SIRI services are designed to exchange or differences in values to previously exchanged values, or in some cases differences that differ by more than an agreed amount.
To some extent the ordering and nesting of elements has been constrained by a requirement to enable a straightforward migration from legacy standards, in particular VDV453 and VDV454, upon which many of the SIRI services are based.
Since SIRI was developed as a harmonisation of existing working national standards that reflect many actual real-time implementation requirements, SIRI is not perfectly uniform in its design or its expression of Transmodel concepts. Nonetheless it achieves a close and useful correspondence.
TRANSMODEL ENTITIES RELEVANT FOR SIRI
Figure 3-6 shows some key Transmodel schedule related entities that are relevant for SIRI message content, including a couple of SIRI artefacts (for example, DatedCall, and VehicleJourneyInfo).
TM-Mdl::JourneyPattern
TM-Mdl::Route
TM-Mdl::Block
TM-Mdl::CourseOfJourney
«group»TM-Mdl::StopPointInSequence
0..*
1
at
1
2..*
stops
TM-Mdl::ServicePattern
0..*
0..1
run
0..*
0..1 pattern
0..*
0..1
block
1
*
runs
1
0..*
stops
1
0..*
route 1
0..*
route
1
0..*
line
1
0..1
info
TM-Mdl::PassingTime
Siri Mdl::DatedCall
1
2..*
calls
0..*
0..1
stop point1
* time
1
0..*
passing times
1
*
service pattern
SIRI - Summary of relevant Transmodel entities
© 2007 SIRI
TM-Mdl::VehicleJourney
TM-Mdl::Line
TM-Mdl::DatedVehicleJourney
TM-Mdl::StopPoint
«group»Siri Mdl::VehicleJourneyInfo
0..*
0..1destination
0..*
0..1
origin
Siri Mdl::MonitoredVehicleJourney
Figure 3-6 Transmodel entities relevant for SIRI
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 22
See the Transmodel specification for full definitions. The following notes outline the relevance of some key elements:
A VEHICLE JOURNEY describes a timetabled journey on a public transport route that runs regularly at a particular time: a DATED VEHICLE JOURNEY is a planned journey run on a specific date.
A VEHICLE JOURNEY follows a JOURNEY PATTERN, which specifies a particular sequence of stops and timings for covering the links between them. A JOURNEY PATTERN may be a specific instance of a more general SERVICE PATTERN associated with a ROUTE, a particular sequence of stops independent of timing. The sequence of STOP POINTs IN SEQUENCE of such patterns identifies the STOP POINTs and order of visit of stops of the vehicle journey. A VEHICLE JOURNEY will have PASSING TIMEs at each stop point. Most SIRI services are concerned primarily with the individual VEHICLE JOURNEYs (in effect a column of a timetable) rather than with the JOURNEY PATTERN, which is typically shared between many journeys of a timetable. However it is sometimes useful to be able to determine the JOURNEY PATTERN in order to access common shared properties of a service, so SIRI messages generally allow the specification of the identifier of the JOURNEY PATTERN of the VEHICLE JOURNEY.
SIRI groups together the set of passing times and other real-time attributes of a vehicle calling at a stop point as part of a vehicle journey as a Call.
A dated vehicle journey that is being tracked and monitored by an AVL system (and so for which real time data may be available) is a MONITORED VEHICLE JOURNEY.
An important point to note is that the labelling of groups of VEHICLE JOURNEYs as belonging to a named LINE (as marketed to the public) and that make up a timetable is independent of any individual journey and may be quite arbitrary: different journeys of the LINE may follow different journey patterns that follow different branches, or that omit stops on some journeys.
For vehicle and crew scheduling, a DATED VEHICLE JOURNEY may be linked up end-to-end with other dated vehicle journeys to make a BLOCK, comprising one or more runs
or in Transmodel terminology, COURSE OF JOURNEYs. Real-time messages may want to include these references to support operational management systems.
The SIRI VehicleJourneyInfo group is a named subset of particular VEHICLE JOURNEY attributes which are often required in SIRI content to give context to real time data for a journey. It is shown with a <<group>> stereotype to indicate that in concrete implementations they are embedded in-line. Similar groupings exist for JourneyPatternInfo etc
Other variant views of DATED VEHICLE JOURNEY used in SIRI, not shown in Figure 3-6, each including particular subsets of timetabled or real[time attributes include TargetedVehicle-Journey, EstimatedVehicleJourney, and InterchangeJourney.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 23
STOP PLACES - SIRI & IFOPT
The CEN IFOPT (Identification of Fixed objects in Public Transport) technical specification extends Transmodel to describe the structure of STOP PLACEs that is, stations, bus stops, airports, and other points of access to transport. One point it clarifies is the distinction between a reference to a stop in a timetable (as a point in a journey pattern of a vehicle journey) a SCHEDULED STOP POINT, and its possible meanings for a real time application, which may be concerned variously with the STOP PLACE as (i) a group of stops; (ii) an individual QUAY i.e. platform, bay, berth, stop pole, etc within the STOP PLACE; or (iii) a BOARDING POSITION within a QUAY. This is summarised in Figure 3-7, which shows that a stop point in the timetable may be variously associated with different levels of detail within a stop place. In practice assignment of a SCHEDULED STOP POINT to a STOP PLACE is very done implicitly by using the same identifier for both, but it might be done more explicitly by an PASSENGER STOP POINT assignment.
Figure 3-7 IFOPT Stop Assignment
IFOPT was developed after the SIRI specification, but aspects of it are useful as a conceptual model for understanding SIRI s use of reference data. It will typically be up to specific applications and implementations to assign appropriate identifiers of stop points to SIRI message elements to reflect the groupings and correspondences for their own configuration. For example, a MonitoringRef of the SIRI Stop Monitoring service might refer to the STOP PLACE if it shows the whole departure board for a station or pair of stops, or to a QUAY if it shows just departures for a particular platform.
The SIRI-SX service was developed after the IFOPT specification and does make explicit use of IFOPT concepts to distinguish components of a STOP PLACE.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 24
PARTICIPANT IDENTIFIERS, MESSAGE & SUBSCRIPTION MANAGEMENT
The requests and responses of SIRI functional services use a common set of header elements to track messages and subscriptions - see Figure 3-8.
Each Participant system is given a unique identifier. This ParticipantCode is used to provide uniqueness of reference for data entities from each system. It is used as the RequestorRef on request messages and the ProducerRef on response messages.
Each request message can be given an identifier by the requestor (MessageIdentifier) that is echoed back in the response (RequestMessageRef). This allows a requestor to match request and responses.
The Requestor needs to be configured to know the address, i.e. url to which new requests for a SIRI functional service are to be sent. The request can contain an EndPointAddress to which responses are to be sent.
All messages are timestamped with an identifier in UTC.
REQUEST RESPONSE ENTITIES & MESSAGE ELEMENTS
Figure 3-8 Illustrates the common elements involved in SIRI request/response interactions.
SIRI functional service requests are sent from a ConsumerService to a ProducerService, which returns a delivery which satisfies the request Topics and Policies
A ServiceRequest contains one or more SIRI functional requests for specific functional services; each concrete SIRI functional service request (SiriFsXXXRequest) inherits common properties from an AbstractFunctionalServiceRequest.
A ServiceDelivery contains one or more delivery elements for a specific SIRI functional service (SiriXxxFsDelivery) - or ErrorConditions if responses cannot be returned. Each SIRI functional service delivery inherits common properties from an Abstract-FunctionalServiceDelivery. (Note: Subscription attributes are not populated for deliveries for request/response).
The RequestMessageRef on the ServiceDelivery messages references the MessageIdentifier of a ServiceRequest to which it responds. The RequestMessageRef on each individual functional service delivery (SiriXxxFsDelivery) within the ServiceDelivery references a MessageIdentifier on the corresponding functional service request (SiriXxxFsRequest).
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 25
Figure 3-8 SIRI Request/Response entities
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 26
PUBLISH SUBSCRIBE MESSAGE ELEMENTS
Figure 3-8 Illustrates the common elements involved in SIRI publish/subscribe interactions.
The SubscribingService requests subscriptions from a SubscriptionManager associated with the ProducerService which creates and manages subscriptions.
Each subscription is given a unique identifier (SubscriptionCode) by the subscriber, which is specified on the subscription request for a specific SIRI functional service (SiriXxxFs-SubscriptionRequest) as the SubscriptionIdentifier, and then included on all deliveries sent back in response to that subscription. The identifier must be unique within the ParticipantCode of the subscriber (SubscriberRef).
One or more functional service subscription requests may be submitted at a time as part of a single SubscriptionRequest. All must be for the same type of service. In response to the subscription request, a SubscriptionResponse message is returned with a ResponseStatus containing the identifier of each functional service subscription (SubscriptionRef) and whether it has been successfully created.
A subscription request includes an InitialTerminationTime which specifies a desired lease period. This will be echoed back as the ValidUntil time on responses.
The ProducerService subsequently monitors the real-time feed and if the request criteria of the subscription are matched, creates deliveries that are sent by the ProducerService to the ConsumerService nominated on the subscription request. Each delivery message includes the subscription identifier (SubscriptionRef) and the ParticipantCode of the subscriber, termed the SubscriberRef.
The subscriber, consumer and producer service keep mirrored representations of the active subscriptions. Recovery from system failure or loss of connection is discussed separately below.
The SubscribingService requests needs to be configured to know the address i.e. url of the system to which new subscription requests are to be sent. The request can contain a ConsumerEndPointAddress to which delivery responses are to be sent and a distinct SubscriberEndPointAddress to which an acknowledgement for the subscription request is to be sent.
An optional capability of SIRI is to have a SubscriptionFilter that will group subscriptions from the same participant for the same type of service so that notifications and delivery data can be sent as a single message. Otherwise each subscription will give rise to separate notification and delivery messages.
All messages are timestamped with an identifier in UTC.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 27
RequestTimestamp[1] : dateTimeMessageIdentifier[0..1] : MessageQualifier
AbstractFunctionalServiceRequest
ParticipantCode[1]LastUsedSituationNumber[0..1]
Siri Mdl::Participant
SubscriberRef[1] : ParticipantCodeSubscriptionIdentifier[1] : SubscriptionCodeInitialTerminationTime[1] : dateTime
AbstractFunctionalSubscriptionRequest
1
0..*
subscriber
SubscriberRef[1] : ParticipantCodeSubscriptionIdentifier[1] : SubscriptionCodeSubscriberEndPoint[1] : EndPointAddressConsumerEndPoint[1] : EndPointAddressValidUntil[1] : dateTime
SubscriptionResponseTimeStamp[1] : dateTimeRequestMessageRef[0..1] : MessageQualifierSubscriberRef[0..1] : ParticipantCodeSubscriptionFilterRef[0..1] : SubscriptionFilterCodeSubscriptionRef[0..1] : SubscriptionCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierStatus[0..1] : booleanErrorCondition[0..1] : ErrorConditionValidUntil[0..1] : dateTimeShortestPossibleCycle[0..1] : positiveDuration
AbstractFunctionalServiceDelivery
0..1
0..*
subscriber
0..1
0..*
fulfils
0..*
1
subscription
SiriXxxFsRequest
Topics, Policies
SubscriptionManager
ProducerRef[1] : ParticipantCodeEndPoint[1] : EndPointAddressLastUsedIdentifier[0..1] : MessageQualifier
ProducerService
10..*
manager for
1
0..*
subscriptions
creates
1
1serves
SiriXxxFsSubscriptionRequest
SiriXxxFsRequest, SubscriptionPolicy
FilterCode[1] : SubscriptionFilterCodeSubscriberRef[1] : ParticipantCode
SubscriptionFilter
1
*
filters
0..1
0..*
filter 0..1
0..*
filtered by
1
0..*
subscriber
1
0..*
producer
SubscriberRef[1] : ParticipantCodeEndpoint[1] : EndPointAddressLastUsedSubscription[1] : SubscriptionCode
SubscribingService
1
1
request
11
request
creates
* *
subscriber
SiriXxxFsDelivery
payload
SIRI Publish Subscribe Entities& Generic messages
© 2007 SIRI
matches
ConsumerRef[1] : ParticipantCodeConsumerEndPoint[1] : EndPointAddressLastUsedMessageIdentifier[1] : MessageQualifier
ConsumerService
0..1
1
consumer for
RecordedAtTime[1] : dateTime
AbstractItem
1
0..*
subscriptions
subscriber, consumer and producer serviceseach keep their own subscription store of active subscriptions.
SiriXxxItem
payload
1
*
contents
ResponseTimeStamp[1] : dateTimeAddress[0..1] : EndPointAddressResponderRef[0..1] : ParticipantCodeRequestMessageRef[0..1] : MessageQualifierResponseStatus[0..1] : ResponseStatusSubscriptionManagerAddress[0..1] : EndPointAddressServiceStartedTime[0..1] : dateTimeExtensions[0..1] : any
SubscriptionResponse
ResponseTimeStamp[1] : dateTimeRequestMessageRef[0..1] : MessageQualifierSubscriberRef[0..1] : ParticipantCodeSubscriptionFilterRef[0..1] : SubscriptionFilterCodeSubscriptionRef[0..1] : SubscriptionCodeStatus[0..1] : booleanErrorCondition[0..1] : ErrorConditionValidUntil[0..1] : dateTimeShortestPossibleCycle[0..1] : positiveDuration
ResponseStatus
1 *
statuses
1
1
granted for
1
1
status for
returns
RequestTimestamp[1] : dateTimeAddress[0..1] : EndPointAddressRequestorRef[1] : ParticipantMessageIdentifer[0..1] : MessageQualifierConsumerAddress[0..1] : EndPointAddressSubscriptionFilterIdentifier[0..1] : nmtokenSubscriptionContext[0..1] : SubscriptionContext
SubscriptionRequest
1
0..*
requests
1
*
requests
Figure 3-9 SIRI Publish/Subscribe entities
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 28
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.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 29
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.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 30
Figure 4-1 Summary of SIRI Functional Service Requests
Figure 4-2 shows a summary of the various SIRI functional service delivery messages produced in response to functional service requests. One or more functional service delivery can be contained within a SIRI ServiceDelivery.
Figure 4-2 Summary of SIRI Functional Service Deliveries
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 31
5. SIRI STOP MONITORING (SM)
The SIRI Stop Monitoring Service provides a stop-centric view of vehicle arrivals and departures at a designated stop. It can be used by displays and other delivery services to provide departure board and other presentations of timetabled and real-time journey information both at stops and remotely. The choice of data elements to display and the presentation format is up to the client system. The service can be used in conjunction with the SIRI Stop Timetable service, which provides scheduled data.
The Topics allow a Consumer system to specify that only stop departures and arrivals for a specific Monitoring point, Operator, Line, or Direction are to be returned.
The Request Policies allow a Consumer system to control the amount of data returned, both in terms of the number of elements and level of detail.
The Subscription Policies allow a Consumer system to control the change threshold for returning an update, so that for example an update is only sent if prediction has changed by more than a given amount.
The Delivery message can include not only service arrival and departure times, but also text notices and the identifiers of Situation elements associated with the stop and/or line.
SIRI-SM: SUBSCRIPTION & REQUEST
STOPMONITORINGREQUEST SUMMARY
Figure 5-1 StopMonitoringRequest - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 32
STOPMONITORINGREQUEST DETAIL
The StopMonitoringRequest is used to request stop arrival and departure data for a given stop or stops identified by a MonitoringRef - which will normally correspond to the identifier of a physical stop or platform, but might also be a logical stop which groups several departure boards.
Other criteria that can be used to filter results include Line (e.g. N45 ), Direction, Operator and Destination.
Figure 5-2 StopMonitoringRequest - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 33
SIRI-SM: DELIVERY
The StopMonitoringDelivery (Figure 5-3) is returned by the SIRI-SM service and normally contains one or more MonitoredStopVisit elements for each monitored stop, each recording a MonitoredVehicle-Journey with a MonitoredCall at the stop with passing times. The level of detail to include may vary considerably; for example the full calling pattern of previous and onward calls may be included for each journey. It may also include StopLineNotices associated with the stop. Previous stop visits or line notices may be retracted with a StopVisitCancellation or StopLineNoticeCancellation.
STOPMONITORINGDELIVERY SUMMARY
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 34
MonitoringRef[1]CleardownRef[0..1]MonitoredVehicleJourney[1]StopVisitNote[0..1]Extensions[0..1]
MonitoredStopVisit
MonitoringRef[1]VisitNumber[1]LineRef[1]DirectionRef[1]VehicleJourneyRef[0..1]ClearDownRef[0..1]JourneyPatternInfo[0..1]Reason[0..1]Extensions[0..1]
MonitoredStopVisitCancellation
MonitoringRef[1]LineRef[1]DirectionRef[1]LineNote[0..1]SituationRef[0..1]Extensions[0..1]
StopLineNotice
MonitoringRef[1]LineRef[1]DirectionRef[1]Extensions[0..1]
StopLineNoticeCancellation0..*
0..1
montor
SIRI-SM Summary StopMonitoringDelivery
© 2006 SIRI
version[1]Note[0..1]Extensions[0..1]
StopMonitoringDelivery
1
0..*
line notices
1
0..*
visits
1
0..*
notice cancellations
1
0..*cancellations
0..1 1
cancels
0..1 1
cancels
0..*
0..1montor
1
0..1
1
0..*
line
ServiceDelivery ErrorCondition
1 0..1
errors
Monitor
Direction
1
*
deliveries
MonitoredVehicleJourneyIdentity[1]JourneyPatternInfo[1]VehicleJourneyInfo[1]DisruptionInfo[0..1]JourneyProgress[0..1]TrainBlockPart[0..1]OperationalInfo[0..1]PreviousCalls[0..*]MonitoredCall[0..1]OnwardCalls[0..*]IsCompleteCallSequence[0..1]Extensions[0..1]
MonitoredVehicleJourney
VehicleAtStop[0..1]ArrivalTimes[0..1]DepartureTimes[0..1]Extensions[0..1]
PreviousCall
1
0..*
previous
Line
VehicleAtStop[0..1]VehicleLocationAtStop[0..1]ReversesAtStop[0..1]PlatformTraversal[0..1]SignalStatus[0..1]CallNote[0..1]Disruption[0..1]ArrivalTimes[0..1]ArrivalInfo[0..1]DepartureTimes[0..1]DepartureInfo[0..1]HeadwayInfo[0..1]Extensions[0..1]
MonitoredCall
1
0..1
current
VehicleAtStop[0..1]TimingPoint[0..1]AimedArrivalTimes[0..1]ArrivalInfo[0..1]AimedDepartureTimes[0..1]DepartureInfo[0..1]HeadwayInfo[0..1]Extensions[0..1]
OnwardCall
1
0..*
onward
LineRef[0..1]DirectionRef[0..1]FramedVehicleJourneyRef[1..1]
«group»MonitoredJourneyIdentity
SituationRef[0..1]FacilityChange[0..1]
«group»DisruptionInfo
1
0..1
disruption
1
0..1
disruption
DataFrameRef[1]DatedVehicleJourneyRef[1]
«group»FramedVehicleJourneyRef
DatedVehicleJourney
1
0..*
journey
1
1 journey
JourneyPatternRef[0..1]VehicleMode[0..1]RouteRef[0..1]PublishedLineName[0..1]DirectionName[0..1]ExternalLineRef[0..1]
«group»JourneyPatternInfo
10..1 pattern
1
0..1pattern info
«group»ServiceInfo
JourneyPattern
StopPointRef[0..1]VisitNumber[0..1]Order[0..1]StopPointName[0..1]
AbstractMonitoredCall
StopPoint
Route
0..*
0..1
route
0..*
0..1
pattern
0..1
0..*line
1
1..1
identity
0..*
0..1
stop
AbstractProducerResponse Participant
10..* producer
See MonitoredVehicle Journey Diagrams for details
1
1
journey
«group»VehicleJourneyInfo
«group»ProgressInfo
10..1 progress
1
0..1
info
10..1journey info
Location
1
0..1
location
«group»SituationReference
1
0..1
reference
Figure 5-3 StopMonitoringDelivery - Summary
STOPMONITORINGDELIVERY DETAIL
Figure 5-4 shows detailed attributes of a Stop Monitoring delivery further details of the MonitoredVehicleJourney are described in further diagrams below.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 35
RecordedAtTime[1] : dateTime
Siri Rqs::AbstractItem
IdentifiedItemCode[0..1] : IdentifiedItemCode
Siri Rqs::AbstractIdentifiedItem IdentifiedItemRef[0..1] : IdentifiedItemCode
Siri Rqs::AbstractReferencedItem
1
1
journey
SIRI-SM StopMonitoringDelivery
© 2006 SIRI
Siri Mdl::Monitor
0..*
0..1monitor
1
0..*
line
1
0..1situation
1
0..*directions
Error[1] : AbstractErrorDescription[1] : ErrorDescription
Siri Rqs::ErrorCondition
ResponseTimeStamp[1] : dateTimeRequestMessageRef[0..1] : MessageQualifierSubscriberRef[0..1] : ParticipantCodeSubscriptionFilterRef[0..1] : SubscriptionFilterCodeSubscriptionRef[0..1] : SubscriptionCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierStatus[0..1] : booleanErrorCondition[0..1] : ErrorConditionValidUntil[0..1] : dateTimeShortestPossibleCycle[0..1] : positiveDuration
Siri Rqs::AbstractFunctionalServiceDelivery
Status : booleanErrorCondition : ErrorConditionMoreData : boolean
Siri Rqs::ServiceDelivery
10..*
errors
Siri Mdl::Participant
MonitoredVehicleJourneyIdentity[1] : MonitoredJourneyIdentityJourneyPatternInfo[1] : JourneyPatternInfoVehicleJourneyInfo[1] : VehicleJourneyInfoDisruptionInfo[0..1] : DisruptionInfoJourneyProgress[0..1] : ProgressInfoTrainBlockPart[0..1] : TrainBlockPartOperationalInfo[0..1] : OperationalInfoPreviousCalls[0..*] : PreviousCallMonitoredCall[0..1] : MonitoredCallOnwardCalls[0..*] : OnwardCallIsCompleteCallSequence[0..1] : booleanExtensions[0..1] : any
Siri Mdl::MonitoredVehicleJourney
DataFrameRef[1] : DataFrameCodeDatedVehicleJourneyRef[1] : DatedVehicleJourneyCode
«group»Siri Mdl::FramedVehicleJourneyRef
TM-Mdl::Line
TM-Mdl::Direction
SX-Mdl::AbstractSituationElement
LineRef[0..1] : LineCodeDirectionRef[0..1] : DirectionCodeFramedVehicleJourneyRef[1..1] : FramedVehicleJourneyRef
«group»Siri Mdl::MonitoredJourneyIdentity
1
1
journey0..1
0..*
line1
1..1
identity
Siri Mdl::PreviousCall
10..*
previous
Siri Mdl::OnwardCall
10..*
onward
Siri Mdl::MonitoredCall
1
0..1
current
TM-Mdl::DatedVehicleJourney
10..*journey
TM-Mdl::DataFrame
0..1
0..*frame
10..1 errors
0..1
0..*
subscriber
ResponseTimeStamp : dateTimeProducerRef : ParticipantCodeAddress : EndPointAddressResponseMessageIdentifier : MessageQualifierRequestMessageRef : MessageQualifier
Siri Rqs::AbstractProducerResponse
1 0..*
producer
See MonitoredVehicle Journey Diagrams for details
MonitoringRef[1] : MonitoringCodeCleardownRef[0..1] : CleardownCodeMonitoredVehicleJourney[1] : MonitoredVehicleJourneyStopVisitNote[0..1] : populatedStringExtensions[0..1] : any
MonitoredStopVisit
0..*
0..1
montor
MonitoringRef[1] : MonitoringCodeVisitNumber[1] : VisitNumberLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeVehicleJourneyRef[0..1]ClearDownRef[0..1] : CleardownCodeJourneyPatternInfo[0..1] : JourneyPatternInfoReason[0..1] : populatedStringExtensions[0..1] : any
MonitoredStopVisitCancellation
0..1 1
cancels
MonitoringRef[1] : MonitoringCodeLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeExtensions[0..1]
StopLineNoticeCancellation
MonitoringRef[1] : MonitoringCodeLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeLineNote[0..1] : populatedStringSituationRef[0..1] : SituationCodeExtensions[0..1]
StopLineNotice
1
0..1
direction
0..1 1
cancels
1
0..*
line notices
1
0..*
visits
1
0..*
notice cancellations
1
* deliveries
1
0..*
cancellations
version[1] : versionStringNote[0..1] : populatedStringExtensions[0..1]
StopMonitoringDelivery
Figure 5-4 StopMonitoringDelivery Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 36
USE OF MONITOREDVEHICLEJOURNEY ELEMENT FOR SIRI-SM
LEVELS OF DETAIL
The MonitoredVehicleJourney element represents an individual vehicle journey that is being monitored: it can be populated with different amounts of data for different applications. For example, for the Stop Monitoring service, it might contain just information about the time of the vehicle at the monitored stop (if say the requested DetailLevel=normal), or it might also included predicted times at all the subsequent stops along the route (if say DetailLevel=calls).
Detail Level
Definition. Purpose
minimum Return only minimum data: a single MonitoredCall with a stop ids and passing time
Used for exchanging just real-time data between systems that are not concerned with other details.
basic Return useful basic minimum data. A single MonitoredCall for each MonitoredVehicleJourney visiting the Stop, with passing times, and line id.
Used to drive simple displays with limited space that show just lines and passing times and line numbers.
normal Return a single MonitoredCall at the stop for each MonitoredVehicleJourney, populated with with times, stop id, Stop name, DestinationDisplay values (i.e. headings), status etc.
Use for normal departure boards that show arrival/departure times for each vehicle along with names (but not a calling pattern).
calls Return additional information including Onwards and Previous elements with the previous and onward calling pattern, modulated by the NumberOfCalls on the request.
Use for departure boards that need to show the full calling pattern or the onward calling pattern.
full Return all information including full calling pattern, operational data (BlockRef, VehicleRef, etc), progress data, journey pattern references etc
Used for data exchange between operational services, or for advanced display services.
Table 5-1 StopMonitoringRequest Detail Levels
For train services, where there may be different carriages going to different places representing different vehicle journeys, train block parts can be used to identify which section of the train is involved. There will be separate deliveries for each vehicle journey.
PASSING TIMES
The times that are included on each call may include an arrival or departure time or both (depending whether it is the start, end or middle of a route), and planned (Aimed), predicted (Expected) or observed (Actual) - (depending whether it has reached the stop yet. Times are always absolute (i.e. in UTC): it is up to the delivery system to render these often they will be shown on signs as relative e.g. in two minutes . Some systems only return average or predicted headway intervals instead of times.
Event Time Arrival Time Departure Time
Target Aimed Arrival Time Aimed Departure Time
Estimated Expected Arrival Time Expected Departure Time
Observed Actual Arrival Time Actual Departure Time
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 37
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.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 38
MONITOREDVEHICLEJOURNEY SUMMARY
The MonitoredVehicleJourneyElement (Figure 5-5) represents a vehicle journey that is being monitored in real-time and for which predictions are being generated. It is used in both the SIRI-SM and SIRI-VM services. Not all elements will usually be populated.
MonitoredCall records the time at the monitored point. PreviousCall and OnwardsCall can be used optionally to record the times at previous and onward stops.
JourneyPatternInfo, VehicleJourneyInfo provide information describing the journey.
Progress Info groups real-time properties such as location, congestion status, occupancy etc.
MonitoredVehicleJourneyIdentity[1]JourneyPatternInfo[1]VehicleJourneyInfo[1]DisruptionInfo[0..1]JourneyProgress[0..1]TrainBlockPart[0..1]OperationalInfo[0..1]PreviousCalls[0..*]MonitoredCall[0..1]OnwardCalls[0..*]IsCompleteCallSequence[0..1]Extensions[0..1]
MonitoredVehicleJourney
LineRef[0..1]DirectionRef[0..1]FramedVehicleJourneyRef[1..1]
«group»MonitoredJourneyIdentity
DataFrameRef[1]DatedVehicleJourneyRef[1]
«group»FramedVehicleJourneyRef
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]
«group»VehicleJourneyInfo
JourneyPatternRef[0..1]VehicleMode[0..1]RouteRef[0..1]PublishedLineName[0..1]DirectionName[0..1]ExternalLineRef[0..1]
«group»JourneyPatternInfo
StopPointRef[0..1]VisitNumber[0..1]Order[0..1]StopPointName[0..1]
AbstractMonitoredCall
VehicleAtStop[0..1]VehicleLocationAtStop[0..1]ReversesAtStop[0..1]PlatformTraversal[0..1]SignalStatus[0..1]CallNote[0..1]Disruption[0..1]ArrivalTimes[0..1]ArrivalInfo[0..1]DepartureTimes[0..1]DepartureInfo[0..1]HeadwayInfo[0..1]Extensions[0..1]
MonitoredCall
SituationRef[0..1]FacilityChange[0..1]
«group»DisruptionInfo
VehicleAtStop[0..1]ArrivalTimes[0..1]DepartureTimes[0..1]Extensions[0..1]
PreviousCall
AimedArrivalTime[0..1]ExpectedArrivalTime[0..1]
«group»AimedArrivalTimes
AimedDepartureTime[0..1]ExpectedDepartureTime[0..1]
«group»AimedDepartureTimes
VehicleAtStop[0..1]TimingPoint[0..1]AimedArrivalTimes[0..1]ArrivalInfo[0..1]AimedDepartureTimes[0..1]DepartureInfo[0..1]HeadwayInfo[0..1]Extensions[0..1]
OnwardCall
ArrivalStatus[0..1]ArrivalPlatformName[0..1]ArrivalBoardingActivity[0..1]
«group»ArrivalInfo
DepartureStatus[0..1]DeparturePlatformName[0..1]DepartureBoardingActivity[0..1]
«group»DepartureInfo
AimedHeadWayInterval[0..1]ExpectedHeadwayInterval[0..1]
«group»HeadwayInfo
Monitored[0..1]MonitoringError[0..1]InCongestion[0..1]InPanic[0..1]PredictionInaccurate[0..1]DataSource[0..1]ConfidenceLevel[0..1]VehicleLocation[0..1]Bearing[0..1]ProgressRate[0..1]Occupancy[0..1]Delay[0..1]ProgressStatus[0..1]
«group»ProgressInfo
BlockRef[0..1]CourseOfJourneyRef[0..1]VehicleRef[0..1]
«group»OperationalInfo
NumberOfBlockParts[0..1]TrainPartRef[0..1]PositionOfTrainBlockPart[0..1]
TM-Mdl::TrainBlockPart
SIRI SummaryMonitoredVehicleJourney
© 2006 SIRI
TimingPoint[0..1]BoardingStretch[0..1]RequestStop[0..1]DestinationDisplay[0..1]
«group»CallInfo
AimedArrivalTime[0..1]ActualArrivalTimes[0..1]ExpectedArrivalTime[0..1]
«group»ArrivalTimes
AimedDepartureTime[0..1]ActualDepartureTimes[0..1]ExpectedDepartureTime[0..1]
«group»DepartureTimes
TM-Mdl::TrainPart
OperatorRef[0..1]ProductCategoryRef[0..1]ServiceFeatureRef[0..*]VehicleFeatureRef[0..*]
«group»ServiceInfo
TM-Mdl::Route
TM-Mdl::JourneyPattern
TM-Mdl::Line
TM-Mdl::DatedVehicleJourney
TM-Mdl::Block
TM-Mdl::Operator
TM-Mdl::Vehicle
TM-Mdl::CourseOfJourney
TM-Mdl::StopPoint
1
1
journey
0..1
0..*
line
11..1
identity
1
0..*
journey
0..*
0..1
block
1
0..1
pattern info0..*
0..1route
0..*
0..1
pattern
1
0..1
pattern
1
0..1
call
1
0..1
headway
1
0..1
headway
1*
arrival
1
0..1
departure
1
0..1
departure
10..1
departure
1
0..1 arrival times
1
0..1
times
1
0..1
times
10..1departure times
0..*
0..1
origin
0..*
0..1 stop
0..*0..1
operator
1
0..1
info
1
0..1
arrival
1
0..1
arrival
ServiceFeature
VehicleFeature
0..*
0..*0..1
0..*0..1
1
0..*
1
0..1
operational
0..*
0..1
0..*
0..1
0..*
0..1
0..*0..1
0..*
0..1
destination
1
0..1
10..1
train block
0..* 0..1train
fullseatsAvailablestandingAvailable
«enumeration»OccupancyEnum
10..1
progress1
0..1
disruption
1 0..1
disruption
boardingnoBoardingpassThru
«enumeration»DepartureActivityEnum early
onTimedelayedarrivedcancellednoReport
«enumeration»TimeStatusEnum
alightingnoAlightingpassThru
«enumeration»ArrivalActivityEnum
TM-Mdl::DataFrame
noProgressslowProgressnormalProgressfastProgressunknown
«enumeration»ProgressRateEnum
Loc Mdl::Location1
0..1location
«group»SituationReference
1
0..1
reference
Figure 5-5 Monitored VehicleJourney - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 39
MONITOREDVEHICLEJOURNEY DETAIL
Figure 5-6 shows the detailed data attributes for a MonitoredVehicleJourney.
Figure 5-6 Monitored vehicle Journey detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 40
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
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 41
6. SIRI VEHICLE MONITORING (VM)
The SIRI Vehicle Monitoring Service reports the position and other real-time properties of a vehicle or group of vehicles making monitored journeys in real-time. It can be used for example to monitor the progress of vehicles; to provide information for systems which present visualisations of the movement of vehicles, for instance on maps, lists or line diagrams; and to exchange information about roaming vehicles between control centres. A particular use is to log data.
SIRI-VM: SUBSCRIPTION & REQUEST
VEHICLEMONITORINGREQUEST SUMMARY
The VehicleMonitoringRequest (Figure 6-1) is used to request real-time data for a vehicle or vehicles. The vehicles can be identified by an arbitrary prearranged grouping, a VehicleMonitoringRef or other criteria such a Line (e.g. N45 ), Direction, or individual VehicleRef.
The Topics allow a Consumer system to specify that only vehicle movements for a specific Vehicle Monitoring group, Line, or Line Direction or Vehicle are to be returned.
The Request Policies allow a Consumer system to control the amount of data returned.
The Subscription Policies allow a Consumer system to control the change threshold for update.
Figure 6-1 VehicleMonitoringRequest - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 42
VEHICLEMONITORINGREQUEST DETAIL
Figure 6-2 shows detailed attributes for a VehicleMonitoring request.
Figure 6-2 VehicleMonitoringRequest - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 43
SIRI-VM: DELIVERY
VEHICLEMONITORINGDELIVERY SUMMARY
The VehicleMonitoringDelivery (Figure 5-3) is returned by the SIRI-VM service and normally contains one or more VehicleActivity elements for each monitored vehicle, each recording a MonitoredVehicleJourney with at least some ProgressInfo, such as the current Location. The level of detail to include may vary considerably; for example, the calling pattern of previous, current and onward calls may be included for each journey. Previously active vehicles may be removed with a VehicleActivityCancellation.
Figure 6-3 VehicleMonitoringDelivery - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 44
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.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 45
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
RecordedAtTime[1] : dateTime
Siri Rqs::AbstractItem
IdentifiedItemCode[0..1] : IdentifiedItemCode
Siri Rqs::AbstractIdentifiedItem IdentifiedItemRef[0..1] : IdentifiedItemCode
Siri Rqs::AbstractReferencedItem
1
1
journey
SIRI-SM StopMonitoringDelivery
© 2006 SIRI
Siri Mdl::Monitor
0..*
0..1monitor
1
0..*
line
1
0..1situation
1
0..*directions
Error[1] : AbstractErrorDescription[1] : ErrorDescription
Siri Rqs::ErrorCondition
ResponseTimeStamp[1] : dateTimeRequestMessageRef[0..1] : MessageQualifierSubscriberRef[0..1] : ParticipantCodeSubscriptionFilterRef[0..1] : SubscriptionFilterCodeSubscriptionRef[0..1] : SubscriptionCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierStatus[0..1] : booleanErrorCondition[0..1] : ErrorConditionValidUntil[0..1] : dateTimeShortestPossibleCycle[0..1] : positiveDuration
Siri Rqs::AbstractFunctionalServiceDelivery
Status : booleanErrorCondition : ErrorConditionMoreData : boolean
Siri Rqs::ServiceDelivery
10..*
errors
Siri Mdl::Participant
MonitoredVehicleJourneyIdentity[1] : MonitoredJourneyIdentityJourneyPatternInfo[1] : JourneyPatternInfoVehicleJourneyInfo[1] : VehicleJourneyInfoDisruptionInfo[0..1] : DisruptionInfoJourneyProgress[0..1] : ProgressInfoTrainBlockPart[0..1] : TrainBlockPartOperationalInfo[0..1] : OperationalInfoPreviousCalls[0..*] : PreviousCallMonitoredCall[0..1] : MonitoredCallOnwardCalls[0..*] : OnwardCallIsCompleteCallSequence[0..1] : booleanExtensions[0..1] : any
Siri Mdl::MonitoredVehicleJourney
DataFrameRef[1] : DataFrameCodeDatedVehicleJourneyRef[1] : DatedVehicleJourneyCode
«group»Siri Mdl::FramedVehicleJourneyRef
TM-Mdl::Line
TM-Mdl::Direction
SX-Mdl::AbstractSituationElement
LineRef[0..1] : LineCodeDirectionRef[0..1] : DirectionCodeFramedVehicleJourneyRef[1..1] : FramedVehicleJourneyRef
«group»Siri Mdl::MonitoredJourneyIdentity
1
1
journey0..1
0..*
line1
1..1
identity
Siri Mdl::PreviousCall
10..*
previous
Siri Mdl::OnwardCall
10..*
onward
Siri Mdl::MonitoredCall
1
0..1
current
TM-Mdl::DatedVehicleJourney
10..*journey
TM-Mdl::DataFrame
0..1
0..*frame
10..1 errors
0..1
0..*
subscriber
ResponseTimeStamp : dateTimeProducerRef : ParticipantCodeAddress : EndPointAddressResponseMessageIdentifier : MessageQualifierRequestMessageRef : MessageQualifier
Siri Rqs::AbstractProducerResponse
1 0..*
producer
See MonitoredVehicle Journey Diagrams for details
MonitoringRef[1] : MonitoringCodeCleardownRef[0..1] : CleardownCodeMonitoredVehicleJourney[1] : MonitoredVehicleJourneyStopVisitNote[0..1] : populatedStringExtensions[0..1] : any
MonitoredStopVisit
0..*
0..1
montor
MonitoringRef[1] : MonitoringCodeVisitNumber[1] : VisitNumberLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeVehicleJourneyRef[0..1]ClearDownRef[0..1] : CleardownCodeJourneyPatternInfo[0..1] : JourneyPatternInfoReason[0..1] : populatedStringExtensions[0..1] : any
MonitoredStopVisitCancellation
0..1 1
cancels
MonitoringRef[1] : MonitoringCodeLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeExtensions[0..1]
StopLineNoticeCancellation
MonitoringRef[1] : MonitoringCodeLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeLineNote[0..1] : populatedStringSituationRef[0..1] : SituationCodeExtensions[0..1]
StopLineNotice
1
0..1
direction
0..1 1
cancels
1
0..*
line notices
1
0..*
visits
1
0..*
notice cancellations
1
* deliveries
1
0..*
cancellations
version[1] : versionStringNote[0..1] : populatedStringExtensions[0..1]
StopMonitoringDelivery
Figure 6-4 VehicleMonitoringDelivery - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 46
7. SIRI PRODUCTIONTIMETABLE (PT)
The SIRI Production Timetable Service transmits daily timetables that include any planned updates that are known about at the time of transmission. The service is used typically to communicate between Scheduling systems and AVMS systems, and also between AVMS systems and intelligent clients of the AVMS system to distributed the latest timetables. The timetables exchanged should cover all lines covered by the AVMS system. SIR-PT may be used in conjunction with the SIRI Estimated Timetable service to provide a base timetable.
The SIRI Production Timetable Service is also used to transmit the planned interchanges between journeys, including information about the linking of vehicle parts through the interchange, such as whether passengers are able to remain seated in the vehicle.
The Request Topics allow a Consumer system to specify that only timetables for a specific timetable version. Operator, line, or direction are to be returned.
The Delivery can include the times at stops, block and journey pattern information, and information about available connections.
SIRI-PT: SUBSCRIPTION & REQUEST
PRODUCTIONTIMETABLEREQUEST SUMMARY
ServiceRequest
SubscriptionRequestParticipant SIRI-PT SummaryProductionTimetableSubscription
& ProductionTimetableRequest© 2007 SIRI
ProductionTimetableSubscriptionRequest
ProductionTimetableRequest
ValidityPeriod[0..1]TimetableVersionRef[0..1]OperatorRef[0..1]LineRef[0..1]DirectionRef[0..1]
ProductionTimetableTopicsLanguage[0..1]IncrementalUpdates[0..1]
ProductionTimetablePoliciesTimetableVersion
Operator
Line Direction StartTime[1]EndTime[1]
ValidityPeriod
ProductionTimetableSubscriptionPolicies1
0..*
requests
1
0..*
requestor1 0..*
requestor
0..1 0..*
operator
1
0..1
topics
0..1
0..*
version
0..1
0..*direction0..1
0..*
line
1 0..1
period
1 0..1
policies
1
1
request1 0..1
policies
1
0..*
requests
Figure 7-1 ProductionTimeTableRequest - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 47
PRODUCTIONTIMETABLEREQUEST DETAIL
Figure 7-2 shows the detailed attributes of the ProductionTimetableRequest which is used to request the timetable of a given service or services
Timetables may be requested by operator, Line Direction, Operator and Destination.
RequestContext[1] : RequestContextRequestTimestamp[1] : dateTimeAddress[1] : EndPointAddressRequestorRef[1] : ParticipantCodeMessageIdentifer[1] : string
Siri Rqs::ServiceRequest
RequestTimestamp[1] : dateTimeAddress[0..1] : EndPointAddressRequestorRef[1] : ParticipantMessageIdentifer[0..1] : MessageQualifierConsumerAddress[0..1] : EndPointAddressSubscriptionFilterIdentifier[0..1] : nmtokenSubscriptionContext[0..1] : SubscriptionContext
Siri Rqs::SubscriptionRequest Siri Rqs::SubscriptionContext
Siri Rqs::RequestContext
Siri Mdl::Participant 10..1
context
1 0..*
requestor
1
0..*
requests
1
0..1
context
1
0..*
requestor
1
0..1
topics
1
0..1
policies
0..1
0..*
version
0..1
0..*
operator
0..1
0..*line
SIRI-PT ProductionTimetableSubscription
& ProductionTimetableRequest© 2007 SIRI
ProductionTimetableRequest[1] : ProductionTimetableRequestProductionTimetableSubscriptionPolicies[0..1] : ProductionTimetableSubscriptionPoliciesExtensions[0..1] : any
ProductionTimetableSubscriptionRequest
ProductionTimetableTopics[0..1] : ProductionTimetableTopicsProductionTimetablePolicies[0..1] : ProductionTimetablePoliciesExtensions[0..1] : any
ProductionTimetableRequest
ValidityPeriod[0..1]TimetableVersionRef[0..1] : TimetableVersionCodeOperatorRef[0..1] : OperatorCodeLineRef[0..1] : LineCodeDirectionRef[0..1] : DirectionCode
ProductionTimetableTopics Language[0..1] : langIncrementalUpdates[0..1] : boolean
ProductionTimetablePolicies
0..1
0..*
direction
1
0..1
period
RequestTimestamp[1] : dateTimeMessageIdentifier[0..1] : MessageQualifier
Siri Rqs::AbstractFunctionalServiceRequest
SubscriberRef[1] : ParticipantCodeSubscriptionIdentifier[1] : SubscriptionCodeInitialTerminationTime[1] : dateTime
Siri Rqs::AbstractFunctionalSubscriptionRequest
TM-Mdl::TimetableVersion
TM-Mdl::Operator
TM-Mdl::Line
TM-Mdl::Direction
1
0..*
directions
StartTime[1] : dateTimeEndTime[1] : dateTime
Siri Mdl::ValidityPeriod
ProductionTimetableSubscriptionPolicies
1
0..*
subscriber
1
1
request
1
0..1
policies
1
0..*
requests
Figure 7-2 ProductionTimetableRequest - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 48
SIRI-PT: DELIVERY
PRODUCTIONTIMETABLEDELIVERY SUMMARY
In essence the ProductionTimetableDelivery returns a timetable as a Versioned set of DatedVehicleJourney instances, each having two or more DatedCalls, as shown in Figure 7-3 which also shows attributes and associated entity references, for example that that a DatedVehicleJourney may have JourneyPatternInfo and ServiceInfo. DatedCalls may also have TargetedInterchange elements giving information about timetabled connections.
Figure 7-3 ProductionTimetableDelivery - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 49
PRODUCTIONTIMETABLEDELIVERY DETAIL
Figure 7-4 shows attribute types for a ProductionTimetableDelivery as well.
SIRI-PTProductionTimetableDelivery
© 2006 SIRI
version[1] : versionStringExtensions[0..1] : any
ProductionTimetableDelivery
VersionRef[0..1] : TimetableVersionCodeLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeJourneyPatternInfo[0..1] : JourneyPatternInfoServiceInfo[0..1] : ServiceInfoDatedVehicleJourneyInfo[0..1] : DatedVehicleJourneyInfoExtensions[0..1] : any
PT-Mdl::DatedTimetableVersionFrame
10..*
timetables
1
0..*
deliveries
1
0..1
default
1
0..1default
DatedVehicleJourneyCode[0..1] : DatedVehicleJourneyCodeVehicleJourneyRef[0..1] : VehicleJourneyCodeExtraJourney[0..1] : booleanCancellation[0..1] : booleanJourneyPatternInfo[0..1] : JourneyPatternInfoServiceInfo[0..1] : ServiceInfoVehicleJourneyNote[0..1] : populatedStringJourneyNote[0..1] : populatedStringBlockRef[0..1] : BlockCodeCourseOfJourneyRef[0..1] : CourseOfJourneyCodeCalls[0..*] : DatedCallExtensions[0..1] : AllowedResourceUsageExceeded
PT-Mdl::DatedVehicleJourney
1
0..*
journeys
DestinationDisplay[0..1] : populatedStringLineNote[0..1] : populatedStringHeadwayService[0..1] : booleanMonitored[0..1] : boolean
«group»PT-Mdl::DatedVehicleJourneyInfo
1
0..1
default
1
0..1
pattern1
0..1
10..1
journey info
StopPointInSequence[1]CallInfo[0..1] : CallInfoCallNote[0..1] : populatedStringFacilityChange[0..1] : FacilityChangeAimedArrivalInfo[0..1] : AimedArrivalInfoAimedDepartureInfo[0..1] : AimedDepartureInfoAimedHeadwayInterval[0..1] : positiveDurationExtensions[0..1] : any
PT-Mdl::DatedCall
1
2..*calls
AimedArrivalTime[0..1] : dateTimeArrivalPlatformName[0..1] : populatedStringArrivalBoardingActivity[0..1] : ArrivalActivityEnum
«group»PT-Mdl::AimedArrivalInfo
AimedDepartureTime[0..1] : dateTimeDeparturePlatformName[0..1] : populatedStringDepartureBoardingActivity[0..1] : DepartureActivityEnum
«group»PT-Mdl::AimedDepartureInfo
1
0..1
1
0..1
0..*0..1
stop point
InterchangeCode[0..1] : InterchangeCodeDistributorVehicleJourneyRef[1] : DatedVehicleJourneyCodeDistributorConnectionLinkRef[0..1] : ConnectionLinkCodeDistributorConnectionLink[0..1] : ConnectionLinkDistributorVisitNumber[0..1] : VisitNumberDistributorOrder[0..1] : positiveIntegerStaySeated[0..1] : booleanGuaranteed[0..1] : booleanAdvertised[0..1] : booleanMaximumWaitTime[0..1] : positiveDurationExtensions[0..1] : any
PT-Mdl::TargetedInterchange
1
0..1
ref
0..* 0..1
1
0..* connection
10..1 call
0..*
0..1
block
0..*0..1 run
1
0..*
to stop
0..*
0..1
TM-Mdl::TimetableVersion
0..*0..1
RecordedAtTime[1] : dateTime
Siri Rqs::AbstractItem
1
0..1
errors
Error[1] : AbstractErrorDescription[1] : ErrorDescription
Siri Rqs::ErrorCondition
Status[0..1] : booleanErrorCondition[0..1] : ErrorConditionMoreData[1] : boolean
Siri Rqs::ServiceDelivery10..1errors
ResponseTimeStamp[1] : dateTimeRequestMessageRef[0..1] : MessageQualifierSubscriberRef[0..1] : ParticipantCodeSubscriptionFilterRef[0..1] : SubscriptionFilterCodeSubscriptionRef[0..1] : SubscriptionCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierStatus[0..1] : booleanErrorCondition[0..1] : ErrorConditionValidUntil[0..1] : dateTimeShortestPossibleCycle[0..1] : positiveDuration
Siri Rqs::AbstractFunctionalServiceDelivery
Siri Mdl::Participant
TM-Mdl::VehicleJourney
TM-Mdl::JourneyPattern
JourneyPatternRef[0..1] : JourneyPatternCodeVehicleMode[0..1] : ModeRouteRef[0..1] : RouteCodePublishedLineName[0..1] : populatedStringDirectionName[0..1] : populatedStringExternalLineRef[0..1] : LineCode
«group»Siri Mdl::JourneyPatternInfo
0..*
0..1
pattern
TM-Mdl::Mode TM-Mdl::Route
0..*
0..1route
OperatorRef[0..1] : OperatorCodeProductCategoryRef[0..1] : ProductCategoryCodeServiceFeatureRef[0..*] : ServiceFeatureCodeVehicleFeatureRef[0..*] : VehicleFeatureCode
«group»Siri Mdl::ServiceInfo
TimingPoint[0..1] : booleanBoardingStretch[0..1] : booleanRequestStop[0..1] : booleanDestinationDisplay[0..1] : populatedString
«group»Siri Mdl::CallInfo
ConnectionLinkCode[0..1] : ConnectionLinkCodeStopPointRef[0..1] : StopPointCodeStopPointName[0..1] : nlStringDefaultDuration[0..1] : durationFrequentTravellerDuration[0..1] : durationOccasionalTravellerDuration[0..1] : durationImpairedAccessDuration[0..1] : duration
TM-Mdl::ConnectionLink
StopPointRef[1] : StopPointCodeVisitNumber[0..1] : VisitNumberOrder[0..1] : positiveIntegerStopPointName[0..1] : populatedString
«group»TM-Mdl::StopPointInSequence
1
2..*
stops
TM-Mdl::StopPoint
0..* 1stop
TM-Mdl::Block
TM-Mdl::CourseOfJourney
1
*
runs
0..1
0..*
subscriber
ResponseTimeStamp[1] : dateTimeProducerRef[0..1] : ParticipantCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierRequestMessageRef[0..1] : MessageQualifier
Siri Rqs::AbstractProducerResponse
1 0..*
producer
TM-Mdl::Line
10..*
line
1
0..* line
Figure 7-4 ProductionTimetableDelivery - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 50
8. SIRI ESTIMATEDTIMETABLE (ET)
The SIRI Estimated Timetable service is used by an AVMS or real-time hub to inform interested systems of the current status of all known vehicle journeys. This enables schedule information systems to provide up-to-the-minute information for short-term journey planning. It can also be used to support intelligent displays that calculate the deviations from the timetables themselves using a timetable and a real time difference delay by the SIRI Stop Monitoring Service. A further use is the historic logging of changes to journey times. It can be used to exchange changes to a timetable established by the SIRI Production timetable service.
The Request Topics allow a Consumer system to specify that only timetables for a specific timetable version. Operator, Line, or Direction are to be returned.
The Subscription Policies allow a subscriber to specify the amount of change to allow before sending an update.
The Delivery returns predicted real-time changes to the timetable.
SIRI-ET: SUBSCRIPTION & REQUEST
ESTIMATEDTIMETABLEREQUEST SUMMARY
EstimatedTimetableSubscriptionRequest
IncrementalUpdates[0..1]ChangeBeforeUpdate[0..1]
EstimatedTimetableSubscriptionPolicies
EstimatedTimetableRequest
Language[0..1]
EstimatedTimetablePolicies
PreviewInterval[0..1]TimetableVersionRef[0..1]OperatorRef[0..1]LineRef[0..1]DirectionRef[0..1]
EstimatedTimetableTopics
SIRI-ET SummaryEstimatedTimeTableSubscription
& EstimatedTimeTableRequest© 2006 SIRI
Direction
Line
Operator
TimetableVersion
ServiceRequest
SubscriptionRequest
Participant
1
0..*
requestor
1
0..*
requestor
10..1
policies
1
*
subscriptions
1
0..*
topics
0..*0..1 operator
0..*0..1 version
0..*0..1
direction
0..*0..1
line
10..1
policies
1 0..*
requests
1
*
request
Figure 8-1 EstimatedTimetableRequest - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 51
ESTIMATEDTIMETABLEREQUEST DETAIL
Figure 8-2 shows the detailed attributes of the EstimatedTimetableRequest which is used to request the real-time timetable of a given service or services.
Timetables may be requested by operator, Line, Direction, Operator and Destination.
Figure 8-2 EstimatedTimetableRequest - Detail
SIRI-ET: DELIVERY
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 52
ESTIMATEDTIMETABLEDELIVERY SUMMARY
Figure 7-3 shows the attributes of an EstimatedTimetableDelivery, which the SIRI-ET service uses to return a timetable as a versioned set of EstimatedVehicleJourney instances, each having an ordered collection of EstimatedCalls. These structures are similar to those of a TargetedVehicleJourney elements of the SIRI-PT service but additionally include expected times i.e. real-time predictions as well.
SIRI-PT - SummaryEstimatedTimeTableDelivery
© 2006 SIRI
VersionRef[0..1]Extensions[0..1]
EstimatedJourneyVersionFrame
EstimatedTimetableDelivery
LineRef[1]DirectionRef[1]DatedVehicleJourneyRef[0..1]DatedVehicleJourneyIndirectRef[0..1]EstimatedVehicleJourneyCode[0..1]ExtraJourney[0..1]Cancellation[0..1]JourneyPatternInfo[0..1]ServiceInfo[0..1]VehicleJourneyName[0..1]JourneyNote[0..1]HeadwayService[0..1]DisruptionInfo[0..1]Monitored[0..1]PredictionInaccurate[0..1]Occupancy[0..1]OperationalInfo[0..1]EstimatedCalls[2..*]IsCompleteStopSequence[0..1]Extensions[0..1]
EstimatedVehicleJourney
StopPointInSequence[0..1]ExtraCall[0..1]Cancellation[0..1]CallInfo[0..1]DestinationDisplay[0..1]CallNote[0..1]FacilityChange[0..1]AimedArrivalTimes[0..1]ArrivalInfo[0..1]AimedDepartureTimes[0..1]DepartureInfo[0..1]HeadwayInterval[0..1]Extensions[0..1]
EstimatedCall
OriginRef[1]AimedDepartureTime[1]DestinationRef[1]AimedArrivalTime[1]
«group»DatedVehicleJourneyIndirectRef
ErrorConditionServiceDelivery
JourneyPatternRef[0..1]VehicleMode[0..1]RouteRef[0..1]PublishedLineName[0..1]DirectionName[0..1]ExternalLineRef[0..1]
«group»JourneyPatternInfo
OperatorRef[0..1]ProductCategoryRef[0..1]ServiceFeatureRef[0..*]VehicleFeatureRef[0..*]
«group»ServiceInfo
BlockRef[0..1]CourseOfJourneyRef[0..1]VehicleRef[0..1]
«group»OperationalInfo
StopPointRef[1]VisitNumber[0..1]Order[0..1]StopPointName[0..1]
«group»StopPointInSequence
AimedArrivalTime[0..1]ExpectedArrivalTime[0..1]
«group»AimedArrivalTimes
ArrivalStatus[0..1]ArrivalPlatformName[0..1]ArrivalBoardingActivity[0..1]
«group»ArrivalInfo
DepartureStatus[0..1]DeparturePlatformName[0..1]DepartureBoardingActivity[0..1]
«group»DepartureInfo
AimedDepartureTime[0..1]ExpectedDepartureTime[0..1]
«group»AimedDepartureTimes
AimedHeadWayInterval[0..1]ExpectedHeadwayInterval[0..1]
«group»HeadwayInfo
TimingPoint[0..1]BoardingStretch[0..1]RequestStop[0..1]DestinationDisplay[0..1]
«group»CallInfo
earlyonTimedelayedarrivedcancellednoReport
«enumeration»TimeStatusEnum
StopPoint
Vehicle
CourseOfJourney
Block
Operator
JourneyPatternDirection
Line
Route
Mode
SituationRef[0..1]FacilityChange[0..1]
«group»DisruptionInfo
TimetableVersion
alightingnoAlightingpassThru
«enumeration»ArrivalActivityEnum
boardingnoBoardingpassThru
«enumeration»DepartureActivityEnum
ServiceFeature
0..* 0..1
feature
ProductCategory0..*
0..1
category
0..*0..1
operator
VehicleFeature
0..*
0..1feature
1
0..*
delivery
1
0..*
deliveries1 0..1
errors
1
0..1
call info
1 0..1
disruption
0..*
0..1
vehicle
1
*
runs
0..*
0..1
run
1
0..1
departure info
1
0..1 arrival
1
0..1 arrival times
1
0..1
headway1
0..1
departure times
0..*
1 stop
0..*
1
at
1
2..*
stops
1
0..1
between
0..*
1
from
10..1pattern info
0..*
0..1
route
0..*
0..1
mode
0..*
0..1pattern
0..*
0..1
line
0..*
1
direction
0..11
Association1
10..*
journeys
1
0..1
service
1
0..1
operational info
0..* 0..1
block
1
0..*
calls
AbstractProducerResponse Participant
10..* producer
«group»SituationReference
1
0..1
reference
Figure 8-3 EstimatedTimetableDelivery - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 53
ESTIMATEDTIMETABLEDELIVERY DETAIL
Figure 7-4 shows the detailed attributes of an EstimatedTimetableDelivery.
SIRI-PT EstimatedTimeTableDelivery
© 2006 SIRI
VersionRef[0..1] : TimetableVersionCodeExtensions[0..1] : any
ET-Mdl::EstimatedJourneyVersionFrame
version[1] : versionStringExtensions[0..1] : any
EstimatedTimetableDelivery
10..* delivery
LineRef[1] : LineCodeDirectionRef[1] : DirectionCodeDatedVehicleJourneyRef[0..1] : DatedVehicleJourneyCodeDatedVehicleJourneyIndirectRef[0..1] : DatedVehicleJourneyIndirectRefEstimatedVehicleJourneyCode[0..1] : EstimatedVehicleJourneyExtraJourney[0..1] : booleanCancellation[0..1] : booleanJourneyPatternInfo[0..1] : JourneyPatternInfoServiceInfo[0..1] : ServiceInfoVehicleJourneyName[0..1] : populatedStringJourneyNote[0..1] : populatedStringHeadwayService[0..1] : booleanDisruptionInfo[0..1] : DisruptionInfoMonitored[0..1] : booleanPredictionInaccurate[0..1] : booleanOccupancy[0..1] : OccupancyEnumOperationalInfo[0..1] : OperationalInfoEstimatedCalls[2..*] : EstimatedCallIsCompleteStopSequence[0..1] : booleanExtensions[0..1] : any
ET-Mdl::EstimatedVehicleJourney
1
0..*
1
0..1
pattern info
1
0..1service
10..1
1
0..1
operational info
StopPointInSequence[0..1] : StopPointInSequenceExtraCall[0..1] : booleanCancellation[0..1] : booleanCallInfo[0..1] : CallInfoDestinationDisplay[0..1] : populatedStringCallNote[0..1] : populatedStringFacilityChange[0..1] : FacilityChangeAimedArrivalTimes[0..1] : ArrivalTimesArrivalInfo[0..1] : ArrivalInfoAimedDepartureTimes[0..1] : DatedVehicleJourneyIndirectRefDepartureInfo[0..1] : DepartureInfoHeadwayInterval[0..1] : HeadwayInfoExtensions[0..1] : any
ET-Mdl::EstimatedCall
1
0..1
1
0..1
1
0..1
departure info
10..*
deliveries
0..*
1
stop
1 0..11
0..1arrival times
OriginRef[1] : StopPointCodeAimedDepartureTime[1] : dateTimeDestinationRef[1] : StopPointCodeAimedArrivalTime[1] : dateTime
«group»Siri Mdl::DatedVehicleJourneyIndirectRef
1
0..*
calls
0..*
0..10..*
10..*1
1
0..*
0..11
1
0..1
ResponseTimeStamp[1] : dateTimeRequestMessageRef[0..1] : MessageQualifierSubscriberRef[0..1] : ParticipantCodeSubscriptionFilterRef[0..1] : SubscriptionFilterCodeSubscriptionRef[0..1] : SubscriptionCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierStatus[0..1] : booleanErrorCondition[0..1] : ErrorConditionValidUntil[0..1] : dateTimeShortestPossibleCycle[0..1] : positiveDuration
Siri Rqs::AbstractFunctionalServiceDelivery
-RecordedAtTime : dateTime
Siri Rqs::AbstractItem
-Error : AbstractError-Description : ErrorDescription
Siri Rqs::ErrorCondition
10..1
errors-Status : boolean-ErrorCondition : ErrorCondition-MoreData : boolean
Siri Rqs::ServiceDelivery1
0..1errors
ResponseTimeStamp[1] : dateTimeProducerRef[0..1] : ParticipantCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierRequestMessageRef[0..1] : MessageQualifier
Siri Rqs::AbstractProducerResponse
JourneyPatternRef[0..1] : JourneyPatternCodeVehicleMode[0..1] : ModeRouteRef[0..1] : RouteCodePublishedLineName[0..1] : populatedStringDirectionName[0..1] : populatedStringExternalLineRef[0..1] : LineCode
«group»Siri Mdl::JourneyPatternInfo
OperatorRef[0..1] : OperatorCodeProductCategoryRef[0..1] : ProductCategoryCodeServiceFeatureRef[0..*] : ServiceFeatureCodeVehicleFeatureRef[0..*] : VehicleFeatureCode
«group»Siri Mdl::ServiceInfo
BlockRef[0..1] : BlockCodeCourseOfJourneyRef[0..1] : CourseOfJourneyCodeVehicleRef[0..1] : VehicleCode
«group»Siri Mdl::OperationalInfo
StopPointRef[1] : StopPointCodeVisitNumber[0..1] : VisitNumberOrder[0..1] : positiveIntegerStopPointName[0..1] : populatedString
«group»TM-Mdl::StopPointInSequence
-AimedArrivalTime : dateTime-ExpectedArrivalTime : dateTime
«group»Siri Mdl::AimedArrivalTimes
ArrivalStatus[0..1] : TimeStatusEnumArrivalPlatformName[0..1] : populatedStringArrivalBoardingActivity[0..1] : ArrivalActivityEnum
«group»Siri Mdl::ArrivalInfo
DepartureStatus[0..1] : TimeStatusEnumDeparturePlatformName[0..1] : populatedStringDepartureBoardingActivity[0..1] : DepartureActivityEnum
«group»Siri Mdl::DepartureInfo
AimedDepartureTime[0..1] : dateTimeExpectedDepartureTime[0..1] : dateTime
«group»Siri Mdl::AimedDepartureTimes
AimedHeadWayInterval[0..1] : positiveDurationExpectedHeadwayInterval[0..1] : positiveDuration
«group»Siri Mdl::HeadwayInfo
TimingPoint[0..1] : booleanBoardingStretch[0..1] : booleanRequestStop[0..1] : booleanDestinationDisplay[0..1] : populatedString
«group»Siri Mdl::CallInfo
earlyonTimedelayedarrivedcancellednoReport
«enumeration»Siri Enm::TimeStatusEnum
TM-Mdl::StopPoint
0..*1
TM-Mdl::Vehicle
0..*
0..1
vehicle
TM-Mdl::CourseOfJourney
0..*0..1run
TM-Mdl::Block
TM-Mdl::Operator
TM-Mdl::JourneyPattern
0..*
0..1
pattern
1
2..*
stops
TM-Mdl::DirectionTM-Mdl::Line
TM-Mdl::Route0..*0..1
TM-Mdl::Mode
0..*
0..1
Siri Mdl::Participant
1
0..*
producer
1
0..1
SituationRef[0..1] : SituationReferenceFacilityChange[0..1] : FacilityChange
«group»Siri Mdl::DisruptionInfo
TM-Mdl::TimetableVersion
0..*0..1
operator
0..*0..1block
0..*
1
from
0..1
0..* subscriber
«group»SX-Mdl::SituationReference
1 0..1
reference
Figure 8-4 EstimatedTimetableDelivery - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 54
9. SIRI STOP TIMETABLE (ST)
The SIRI Stop Timetable Service provides a timetabled for vehicle arrivals and departures at a designated stop. It can be used to reduce the amount of information that needs to be transmitted in real-time to stops and displays, as reference data for a Stop Monitoring Service; and provides a data feed of the static timetables.
The Request Topics allow a Consumer system to specify that only stop timetables for a specific monitoring point, line, or direction are to be returned.
The Delivery returns departures from the stop for a specified window.
SIRI-ST: SUBSCRIPTION & REQUEST
STOPTIMETABLEREQUEST SUMMARY
Figure 9-1 StopTimetableRequest - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 55
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.
1
0..1
policies
1
0..*
requests
10..1
policies
10..1
topics
SIRI-STStopTimetableSubscription
& StopTimetableRequest© 2007 SIRI
StopTimetableTopics[0..1] : StopTimetableTopicsStopTimetablePolicies[0..1] : StopTimetablePoliciesExtensions[0..1] : any
StopTimetableRequest
StopTimetableRequest[1] : StopTimetableRequestStopTimetableSubscriptionPolicies[0..1] : StopTimetableSubscriptionPoliciesExtensions[0..1] : any
StopTimetableSubscriptionRequest
StopTimetableSubscriptionPolicies
MonitoringWindow[0..1] : HalfOpenTimestampRangeMonitoringRef[0..1] : MonitoringCodeLineRef[0..1] : LineCodeDirectionRef[0..1] : DirectionCode
StopTimetableTopics
Language[0..1] : lang
StopTimetablePolicies
0..*
0..1
direction0..*
0..1
monitor
0..*
0..1
line
RequestContext[1] : RequestContextRequestTimestamp[1] : dateTimeAddress[1] : EndPointAddressRequestorRef[1] : ParticipantCodeMessageIdentifer[1] : string
Siri Rqs::ServiceRequest
RequestTimestamp[1] : dateTimeAddress[0..1] : EndPointAddressRequestorRef[1] : ParticipantMessageIdentifer[0..1] : MessageQualifierConsumerAddress[0..1] : EndPointAddressSubscriptionFilterIdentifier[0..1] : nmtokenSubscriptionContext[0..1] : SubscriptionContext
Siri Rqs::SubscriptionRequest
Siri Rqs::SubscriptionContext
Siri Rqs::RequestContext
11..1
context
Siri Mdl::Participant 1
0..*
requests
RequestTimestamp[1] : dateTimeMessageIdentifier[0..1] : MessageQualifier
Siri Rqs::AbstractFunctionalServiceRequest
SubscriberRef[1] : ParticipantCodeSubscriptionIdentifier[1] : SubscriptionCodeInitialTerminationTime[1] : dateTime
Siri Rqs::AbstractFunctionalSubscriptionRequest
TM-Mdl::Line TM-Mdl::Direction1 0..*
directions
1 0..*
subscriber
1 0..1
context
1
0..*
requestor
1
0..*
requestor
Siri Mdl::Monitor
1
1
request
Figure 9-2 StopTimetableRequest - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 56
SIRI-ST: DELIVERY
The StopTimetableDelivery (Figure 5-3) is returned by the SIRI-ST service and normally contains one or more TargetedStopVisit elements for each monitored stop, each recording a TargetedVehicle-Journey with a TargetedCall at the stop with passing times.
STOPTIMETABLEDELIVERY SUMMARY
StopTimetableDelivery
MonitoringRef[1]TargetedVehicleJourney[1]Extensions[1]
TimetabledStopVisit
VehicleJourneyIdentity[1]JourneyPatternInfo[0..*]VehicleJourneyInfo[0..1]MonitoringRef[0..1]Extensions[0..1]
TargetedVehicleJourney
MonitoringRef[1]VisitNumber[0..1]VehicleJourneyIdentity[1]JourneyPatternInfo[0..1]Extensions[0..1]
TimetabledStopVisitCancellation
LineRef[1]DirectionRef[1]FramedVehicleJourneyRef[0..1]
«group»VehicleJourneyIdentity
StopPointRef[0..1]VisitNumber[1]Order[0..1]TimingPoint[0..1]ServiceInfo[0..1]AimedArrivalInfo[0..1]AimedDepartureInfo[0..1]AimedHeadwayInterval[0..1]Extensions[0..1]
TargetedCall
AimedArrivalTime[0..1]ArrivalPlatformName[0..1]ArrivalBoardingActivity[0..1]
«group»AimedArrivalInfo
SIRI-ST SummaryStopTimetableDelivery
© 2006 SIRI
AimedDepartureTime[0..1]DeparturePlatformName[0..1]DepartureBoardingActivity[0..1]
«group»AimedDepartureInfo
Monitor
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]
«group»VehicleJourneyInfo
OperatorRef[0..1]ProductCategoryRef[0..1]ServiceFeatureRef[0..*]VehicleFeatureRef[0..*]
«group»ServiceInfo
Operator
VehicleFeature
JourneyPatternRef[0..1]VehicleMode[0..1]RouteRef[0..1]PublishedLineName[0..1]DirectionName[0..1]ExternalLineRef[0..1]
«group»JourneyPatternInfo
alightingnoAlightingpassThru
«enumeration»ArrivalActivityEnum
boardingnoBoardingpassThru
«enumeration»DepartureActivityEnum
ProductCategory
Line
Route
JourneyPattern
airbuscoachferrymetrorailtramunderground
«enumeration»VehicleModesEnum
DataFrameRef[1]DatedVehicleJourneyRef[1]
«group»FramedVehicleJourneyRef
StopPoint
ProducerResponse
ServiceDeliveryErrorCondition
ServiceFeature
DataFrame 0..*
0..1 frame
StopPointRef[1]VisitNumber[0..1]Order[0..1]StopPointName[0..1]
«group»StopPointInSequence
0..*
1
at
1
2..*
stops
Mode0..*
0..1
mode
1
1
cancels
1
1
journey
1
*
visits
1 0..1
errors
1 0..*
cancellations
1
0..1
departure info
0..*
0..1
stop
1
0..1
arrival info
1
0..*
calls
1 0..1
service info
0..*0..1
feature
0..*
0..1
operator
0..*
0..1
category
0..*
0..1
feature
1
0..1
info
0..*
0..1
route
1
0..1
line
0..*
0..1
monitor
0..*
0..1
monitoring point
1
1
for
0..11
journey
1
1
identity
0..*
0..1
destination
0..*0..1
origin
0..*
0..1pattern
1
0..*
deliveries
Figure 9-3 StopTimetableDelivery - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 57
STOPTIMETABLEDELIVERY DETAIL
Figure 9-4 Figure 7-4 shows attribute types for a StopTimetableDelivery as well.
Figure 9-4 StopTimetableDelivery - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 58
10. SIRI CONNECTIONTIMETABLE (CT)
The SIRI Connection Timetable Service is used for the exchange of schedule data for potential feeder vehicle journeys to a connection zone. It is normally used in conjunction with the SIRI Connection Monitoring Service to establish the reference data of planned connections to be monitored by the real time systems. The service is location-related, i.e. all requests and replies relate to specific connection links, as identified by connection link identifiers.
The Topics allow a Consumer system to specify that only Connection Timetables for a specific Connection Link, Line, or Line Direction or Vehicle are to be returned.
The Delivery returns planned connections as InterchangeJourneys
SIRI-CT: SUBSCRIPTION & REQUEST
CONNECTIONTIMETABLEREQUEST SUMMARY
Figure 10-1 ConnectionTimetableRequest - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 59
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.
Figure 10-2 ConnectionTimetableRequest - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 60
SIRI-CT: DELIVERY
CONNECTIONTIMETABLEDELIVERY SUMMARY
The ConnectionTimetableDelivery (Figure 10-3Figure 5-3) is returned by the SIRI-CT service and normally contains one or more TimetabledFeedArrival elements for each monitored connection link, each recording a InterchangeJourney.
ConnectionTimetableDelivery
InterchangeRef[0..1]ConnectionLinkRef[1]StopPointInSequence[0..1]FeederJourney[1]AimedArrivalTime[1]Extensions[0..1]
TimetabledFeederArrival
InterchangeRef[0..1]ConnectionLinkRef[1]StopPointInSequence[0..1]LineRef[1]DirectionRef[1]VehicleJourneyRef[1]JourneyPatternInfo[0..1]Reason[0..1]Extensions[0..1]
TimetabledFeederArrivalCancellation
LineRef[1]DirectionRef[1]FramedVehicleJourneyRef[0..1]JourneyPatternInfo[0..1]VehicleJourneyInfo[0..1]DisruptionInfo[0..1]Monitored[0..1]AimedDepartureTime[0..1]OperationalInfo[0..1]Extensions[0..1]
InterchangeJourney
ErrorConditionServiceDelivery
ParticipantProducerResponse SIRI-CT SummaryConnectionTimetableDelivery
© 2006 SIRI
JourneyPatternRef[0..1]VehicleMode[0..1]RouteRef[0..1]PublishedLineName[0..1]DirectionName[0..1]ExternalLineRef[0..1]
«group»JourneyPatternInfo
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]
«group»VehicleJourneyInfo
OperatorRef[0..1]ProductCategoryRef[0..1]ServiceFeatureRef[0..*]VehicleFeatureRef[0..*]
«group»ServiceInfo
BlockRef[0..1]CourseOfJourneyRef[0..1]VehicleRef[0..1]
«group»OperationalInfo
StopPoint
Interchange
ConnectionLink
StopPointRef[1]VisitNumber[0..1]Order[0..1]StopPointName[0..1]
«group»StopPointInSequence
Operator
DataFrameRef[1]DatedVehicleJourneyRef[1]
«group»FramedVehicleJourneyRef
SituationRef[0..1]FacilityChange[0..1]
«group»DisruptionInfo
Vehicle
CourseOfJourney
Block
Mode RouteSituation
DataFrame
Direction
Line
JourneyPattern
DatedVehicleJourney
1 0..1
errors
1
0..*
arrivals
1 0..*
cancellations
1 0..*
deliveries
0..* 0..1
interchange1
0..1
visit
10..1 visit
0..*
1
at
1
2..*
stops
VehicleFeature
0..*
0..1
feature
ProductCategory
0..*
0..1
categoryServiceFeature
1
0..1
operational info
0..*
0..1
vehicle
0..*
0..1
run0..*
0..1
block
1
0..1
info
0..*0..1destination 0..*
0..1 origin
1 0..1
journey info
0..*
0..1
operator
1
0..1 disruption
0..*
0..1
situation
1
0..1
pattern
0..*
0..1
route0..*
0..1
mode
0..*
0..1
pattern
1
0..1 pattern
0..*0..1 line
10..*
directions
0..*0..1 direction
10..*
journey
1
0..*
journey
0..*
0..1 frame0..1
0..*to stop
0..10..*
link
0..*
0..1
feature
10..* producer
1
1
feeder
1
0..* directions
Figure 10-3 ConnectionTimetableDelivery - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 61
CONNECTIONTIMETABLEDELIVERY DETAIL
Figure 10-4 shows attribute types for a ConnectionTimetableDelivery as well.
Figure 10-4 ConnectionTimetableDelivery - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 62
11. SIRI CONNECTIONMONITORING (CM)
The SIRI Connection Monitoring Service exchanges information between different AVMS to coordinate the real-time arrival and departure of PTVs at an interchange through which passengers may make connecting journeys. The departure time of the outgoing distributor
(or fetcher from )
service may be adjusted to accommodate delays in the incoming feeder to service.
The service ensures that the AVMS are in a position to receive all the necessary data concerning the feeder vehicles to allow connection monitoring and dispatch to be carried out, and to inform passengers of changes. The operational methods of dispatch remain unaffected.
The Service can be used in conjunction with the SIRI Connection Timetable Service to exchange scheduled arrival times in the target connection links.
The Topics allow a Consumer system to specify that only Connection Timetables for a specific Connection Link, Line, or Line Direction or Vehicle are to be returned.
The Delivery can return information about both changes to feeder (e.g. late arrival) and departure (e.g. late departure, platform change)
SIRI-CM: SUBSCRIPTION & REQUEST
CONNECTIONMONITORINGREQUEST SUMMARY
Figure 11-1 ConnectionMonitoringRequest - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 63
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.
Figure 11-2 ConnectionMonitoringRequest - Detail
SIRI-CM: DELIVERY
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 64
CONNECTIONMONITORINGDELIVERY SUMMARY
The SIRI-CM service returns two types of delivery (Figure 10-3Figure 5-3) that provide information about real-time changes at a monitored connection link.
A ConnectionMonitoringFeedeDelivery contains one or more MonitoredFeedArrival instances, each with an a InterchangeJourney describing the real-time arrival time of a feeder.
A ConnectionMonitoringDistributorDelivery contains different types of change to the departing distributor: a delay (WaitProlongedDeparture); a cancellation (Distributure-DepartureCancellation) or a platform change (StoppingPositionChangedRecording).
Figure 11-3 ConnectionMonitoringDelivery - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 65
CONNECTIONMONITORINGDELIVERY DETAIL
Figure 11-4 shows attribute types for a ConnectionMonitoringDelivery.
RecordedAtTime[1] : dateTime
Siri Rqs::AbstractItem
IdentifiedItemCode[0..1] : IdentifiedItemCode
Siri Rqs::AbstractIdentifiedItemIdentifiedItemRef[0..1] : IdentifiedItemCode
Siri Rqs::AbstractReferencedItem
Error[1] : AbstractErrorDescription[1] : ErrorDescription
Siri Rqs::ErrorCondition
ResponseTimeStamp[1] : dateTimeRequestMessageRef[0..1] : MessageQualifierSubscriberRef[0..1] : ParticipantCodeSubscriptionFilterRef[0..1] : SubscriptionFilterCodeSubscriptionRef[0..1] : SubscriptionCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierStatus[0..1] : booleanErrorCondition[0..1] : ErrorConditionValidUntil[0..1] : dateTimeShortestPossibleCycle[0..1] : positiveDuration
Siri Rqs::AbstractFunctionalServiceDelivery
Status[0..1] : booleanErrorCondition[0..1] : ErrorConditionMoreData[1] : boolean
Siri Rqs::ServiceDelivery
Siri Mdl::Participant-ResponseTimeStamp : dateTime-ProducerRef : ParticipantCode-Address : EndPointAddress-ResponseMessageIdentifier : MessageQualifier-RequestMessageRef : MessageQualifier
Siri Rqs::ProducerResponse
version[1] : versionStringExtensions[1] : BaseSituation
ConnectionMonitoringFeederDelivery
InterchangeRef[0..1] : InterchangeCodeConnectionLinkRef[1] : ConnectionLinkCodeStopPointInSequence[0..1] : StopPointInSequenceClearDownRef[0..1] : CleardownCodeFeederJourney[1] : InterchangeJourneyVehicleAtStop[1] : booleanNumberOfTransferPassengers[0..1] : integerExpectedArrivalTime[1] : dateTimeExtensions[0..1] : any
CM-Mdl::MonitoredFeederArrival InterchangeRef[0..1] : InterchangeCodeConnectionLinkRef[1] : ConnectionLinkCodeStopPointInSequence[0..1] : StopPointInSequenceLineRef[1] : LineCodeDirectionRef[1] : DirectionCodeVehicleJourneyRef[1] : VehicleJourneyCodeJourneyPatternInfo[0..1] : JourneyPatternInfoReason[0..1] : populatedStringExtensions[0..1] : any
MonitoredFeederArrivalCancellation
1
1
feeder
11
version[1] : versionStringExtensions[1] : any
ConnectionMonitoringDistributorDelivery1
0..*
arrvals
1
0..*cancellations
InterchangeRef[0..1] : InterchangeCodeConnectionLinkRef[1] : ConnectionLinkCodeStopPointRef[0..1] : StopPointCodeDistributorVisitNumber[0..1] : VisitNumberDistributorOrder[0..1] : positiveIntegerDistributorJourney[1] : InterchangeJourneyFeederVehicleJourneyRef[0..1] : FramedVehicleJourneyRefExtensions[0..1] : any
CM-Mdl::AbstractDistributorItem
ExpectedDepartureTime[0..1] : dateTimeExtensions[0..1] : any
CM-Mdl::WaitProlongedDeparture
ChangeNote[0..1] : populatedStringNewLocation[0..1] : LocationExtensions[0..1] : any
CM-Mdl::StoppingPositionChangedDeparture
Reason[0..1] : populatedStringExtensions[0..1] : any
DistributorDepartureCancellation
11
distributor
1
0..1
1
0..*
1
0..*
1
0..*
See ConnectionTimetableService for details
SIRI-CM ConnectionMonitoringDelivery
© 2007 SIRI
10..1
0..1
0..*
1
0..1distributor
0..*0..1 feeder
0..1
1
10..1errors
1
0..*
deliveries
10..* deliveries
LineRef[1] : NetworkCodeDirectionRef[1] : DirectionCodeFramedVehicleJourneyRef[0..1] : FramedVehicleJourneyRefJourneyPatternInfo[0..1] : JourneyPatternInfoVehicleJourneyInfo[0..1] : VehicleJourneyInfoDisruptionInfo[0..1] : DisruptionInfoMonitored[0..1] : booleanAimedDepartureTime[0..1] : dateTimeOperationalInfo[0..1] : OperationalInfoExtensions[0..1] : any
Siri Mdl::InterchangeJourney
StopPointRef[1] : StopPointCodeVisitNumber[0..1] : VisitNumberOrder[0..1] : positiveIntegerStopPointName[0..1] : populatedString
«group»TM-Mdl::StopPointInSequence
JourneyPatternRef[0..1] : JourneyPatternCodeVehicleMode[0..1] : ModeRouteRef[0..1] : RouteCodePublishedLineName[0..1] : populatedStringDirectionName[0..1] : populatedStringExternalLineRef[0..1] : LineCode
«group»Siri Mdl::JourneyPatternInfo
1
0..1
pattern
TM-Mdl::Line
0..*0..1 line
TM-Mdl::Direction
0..*
0..1
direction
TM-Mdl::StopPoint
0..*
1at
«group»Siri Mdl::FramedVehicleJourneyRef
1 0..*journey
TM-Mdl::Route
TM-Mdl::Mode
0..* 0..1mode
TM-Mdl::JourneyPattern
0..*
0..1
pattern
TM-Mdl::Interchange
TM-Mdl::ConnectionLink
1 0..*
producer0..1
0..*
subscriber
0..1
0..*to stop
0..*0..1route
0..*
0..1link
Figure 11-4 ConnectionMonitoringDelivery - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 66
12. SIRI GENERALMESSAGE (GM)
The SIRI General Message service is used to transmit messages between the participants. The data to be published will typically be informative messages such as travel news and other operational advice, entered or forwarded into the system - normally by a control centre. The General Message service can segregate different types of informative message into separate information channels; each info channel can be assigned to a different operational message group type (errors, messages, warnings, traffic information, operational messages, etc.).
The Topics allow a Consumer system to specify that only specific categories of message are to be returned.
The service allows arbitrary content to be embedded. To exchange structured messages see the SIRI-SX service.
SIRI-GM: SUBSCRIPTION & REQUEST
GENERALMESSAGEREQUEST SUMMARY
Figure 12-1 GeneralMessageRequest - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 67
GENERALMESSAGEREQUEST DETAIL
The GeneralMessageRequest (Figure 12-2) is used to request message data.
Data may be filtered by an InfoChannel.
Figure 12-2 GeneralMessageRequest - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 68
SIRI-GM: DELIVERY
GENERALMESSAGEDELIVERY SUMMARY
The GeneralMessageDelivery (Figure 12-3) is returned by the SIRI-GM service and normally contains one or more GeneralMessage elements, each recording a Content message in a specified format.
Figure 12-3 GeneralMessageDelivery - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 69
GENERALMESSAGEDELIVERY DETAIL
Figure 12-4 shows attribute types for a GeneralMessageDelivery.
ResponseTimeStamp[1] : dateTimeRequestMessageRef[0..1] : MessageQualifierSubscriberRef[0..1] : ParticipantCodeSubscriptionFilterRef[0..1] : SubscriptionFilterCodeSubscriptionRef[0..1] : SubscriptionCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierStatus[0..1] : booleanErrorCondition[0..1] : ErrorConditionValidUntil[0..1] : dateTimeShortestPossibleCycle[0..1] : positiveDuration
Siri Rqs::AbstractFunctionalServiceDelivery
-Error[1] : AbstractError-Description[1] : ErrorDescription
SIRI Requests::ErrorCondition
10..1
1
0..1
version[1] : versionStringExtensions[0..1]
GeneralMessageDelivery
InfoMessageIdentifier[1] : InfoMessageIdentifierInfoMessageVersion[0..1] : InfoMessageVersionInfoChannelRef[0..1] : InfoChannelCodeValidUntilTime[0..1] : dateTimeSituationRef[0..1] : SituationCodeContent[1] : Content
GeneralMessage
«datatype»GM-Mdl::InfoMessageIdentifier
«datatype»GM-Mdl::InfoMessageVersion
«datatype»GM-Mdl::InfoChannelCode
InfoMessageIdentifier[1] : InfoMessageIdentifierInfoMessageVersion[0..1] : InfoMessageVersionInfoChannelRef[0..1] : InfoChannelCodeValidUntilTime[0..1] : dateTimeSituationRef[0..1] : SituationCodeExtensions[0..1]
GeneralMessageCancellation
1
0..1
1
0..1
format[0..1] : nmtokenvalue[0..1] : string
Content
1
1
SIRI-GM GeneralMessageDelivery
© 2007 SIRI
GM-Mdl::InfoChannel
0..1
0..*
info channel
1 0..1
cancels
IdentifiedItemCode[0..1] : IdentifiedItemCode
Siri Rqs::AbstractIdentifiedItemIdentifiedItemRef[0..1] : IdentifiedItemCode
Siri Rqs::AbstractReferencedItem
-RecordedAtTime[1] : dateTime
Siri Rqs::AbstractItem
ResponseTimeStamp[1] : dateTimeProducerRef[0..1] : ParticipantCodeAddress[0..1] : EndPointAddressResponseMessageIdentifier[0..1] : MessageQualifierRequestMessageRef[0..1] : MessageQualifier
Siri Rqs::AbstractProducerResponse
Siri Mdl::Participant
10..*
producer
Status[0..1] : booleanErrorCondition[0..1] : ErrorConditionMoreData[1] : boolean
Siri Rqs::ServiceDelivery
1
0..* deliveries
0..10..*
subscriber
«group»SX-Mdl::SituationReference
0..1
1
situation
Figure 12-4 GeneralMessageDelivery - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 70
13. SIRI FACILITYMONITORING (FM) DRAFT
SIRI-FM: SUBSCRIPTION & REQUEST
FACILITYMONITORINGREQUEST SUMMARY
[TODO]
Figure 13-1 ProductionTimeTableRequest - Summary
FACILITYMONITORINGREQUEST DETAIL
[TODO]
Figure 13-2 ProductionTimetableRequest - Detail
SIRI-FM: DELIVERY
FACILITYMONITORINGDELIVERY SUMMARY
[TODO]
Figure 13-3 ProductionTimetableDelivery - Summary
FACILITYMONITORINGDELIVERY DETAIL
[TODO]
Figure 13-4 ProductionTimetableDelivery - Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 71
14. SIRI SITUATIONEXCHANGE (SX) DRAFT
The SIRI-SX Service is for exchanging Situation content in real-time. It uses a structured Situation model for describing disruptions to services. The structured model includes element references that relate directly to the entities of other SIRI services. Incidents can thus be directly linked to stop points, lines, journeys, pathways, etc: and provide an explanation of the disruption. The service can be used to exchange incident information between control systems, and to distribute to journey planners and alert systems that wish to process and match incidents based on structured elements.
The Topics allow a Consumer system to specify that only specific categories of message are to be returned.
The Delivery embeds Structured incidents and updates.
SIRI-SX: SUBSCRIPTION & REQUEST
SITUATIONEXCHANGEREQUEST SUMMARY
Figure 14-1 Summarises the SIRI-SX request elements.
SIRI-SX SummarySituationExchangeSubscription
& SituationExchangeRequest© 2007 SIRI
ServiceRequest
1
*
requests
SubscriptionRequest
SituationExchangeRequestLanguage[0..1]MaximumNumberOfSituations[0..1]
SituationExchangePolicies
PreviewInterval[1]StartTime[0..1]VehicleMode[0..1]AffectedSubMode[0..1]AccessMode[1]Severity[0..1]Predictability[0..1]Keywords[0..*]SituationNetworkFilter[0..1]SituationStopPlaceFilter[0..1]SituationJourneyFilter[0..1]AccessibilityNeedFilter[0..1]
SituationExchangeTopics
SituationExchangeSubscriptionRequest
UserNeed[0..1]
AccessibilityNeedsFilter
IncrementalUpdates[0..1]
SituationExchangeSubscriptionPolicies
1 0..1
policies
10..1
topics
unknownverySlightslightnormalsevereverySeverenoImpactundefined
«enumeration»TpegSeverityEnum
OperatorRef[0..1]OperationalUnitRef[0..1]NetworkRef[0..1]LineRef[0..1]StopPointRef[0..1]ConnectionLinkRef[0..1]
SituationNetworkFilter
0..1
0..*operator
airbuscoachferrymetrorailtramunderground
«enumeration»VehicleModesEnum
OperationalUnit
1
0..1
filter
VehicleJourneyRef[0..1]InterchangeRef[0..1]VehicleRef[0..1]
SituationJourneyFilter
Vehicle
InterchangeVehicleJourney0..1
1unit
0..*
0..1
vehicle
0..*
0..1
interchange0..*
0..1
journey
1
0..*
filter
0..*
0..1
stop point
0..*0..1network
ConnectionLink
0..*
0..1
connection
0..1
0..*
user need
1 0..*
participant
10..*
participant
footbicyclecartaxishuttle
«enumeration»AccessModesEnum
StopPoint
Operator
plannedunplannedboth
«enumeration»PredictabilityEnum
Line
Network
Participant
1
0..*
line
UserNeed
1
0..1
filter
StopPlaceRef[0..1]FacilityRef[0..1]
SituationStopPlaceFilter
10..1
places
StopPlace
1
0..*stop place
10..*
subscriptions
1
1
request1
*policies
Figure 14-1 SituationExchangeRequest - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 72
SITUATIONEXCHANGEREQUEST DETAIL
The SituationExchangeRequest (Figure 12-2) is used to request message data.
Data may be filtered by various structured message attributes such as a Severity, Mode, etc as well as filters for the Network, Line Stop place, etc.
SIRI-SX SituationExchangeSubscription
& SituationExchangeRequest© 2007 SIRI
RequestContext[1] : RequestContextRequestTimestamp[1] : dateTimeAddress[1] : EndPointAddressRequestorRef[1] : ParticipantCodeMessageIdentifer[1] : string
Siri Rqs::ServiceRequest
RequestTimestamp[1] : dateTimeAddress[0..1] : EndPointAddressRequestorRef[1] : ParticipantMessageIdentifer[0..1] : MessageQualifierConsumerAddress[0..1] : EndPointAddressSubscriptionFilterIdentifier[0..1] : nmtokenSubscriptionContext[0..1] : SubscriptionContext
Siri Rqs::SubscriptionRequest
SituationExchangeTopics[0..1] : SituationExchangeTopicsSituationExchangePolicies[0..1] : SituationExchangePoliciesExtensions[0..1] : any
SituationExchangeRequest
Language[0..1] : langMaximumNumberOfSituations[0..1] : integer
SituationExchangePolicies
PreviewInterval[1] : durationStartTime[0..1] : dateTimeVehicleMode[0..1] : VehicleModesEnumAffectedSubMode[0..1] : AccessModesEnumAccessMode[1] : AccessModesEnumSeverity[0..1] : TpegSeverityEnumPredictability[0..1] : booleanKeywords[0..*] : stringSituationNetworkFilter[0..1] : SituationNetworkFilterSituationStopPlaceFilter[0..1] : SituationStopPlaceFilterSituationJourneyFilter[0..1] : SituationJourneyFilterAccessibilityNeedFilter[0..1] : AccessibilityNeedsFilter
SituationExchangeTopics
SituationExchangeRequest[1] : SituationExchangeRequestSituationExchangeSubscriptionPolicies[0..1] : SituationExchangeSubscriptionPoliciesExtensions[0..1] : any
SituationExchangeSubscriptionRequest
AccessibilityNeedsFilter
IncrementalUpdates[0..1] : boolean
SituationExchangeSubscriptionPolicies
unknownverySlightslightnormalsevereverySeverenoImpactundefined
«enumeration»TpegSeverityEnum
OperatorRef[0..1] : OperatorCodeOperationalUnitRef[0..1] : OperationalUnitCodeNetworkRef[0..1] : NetworkCodeLineRef[0..1] : LineCodeStopPointRef[0..1] : StopPointCodeConnectionLinkRef[0..1] : ConnectionLinkCode
SituationNetworkFilter
airbuscoachferrymetrorailtramunderground
«enumeration»Siri Enm::VehicleModesEnum
TM-Mdl::OperationalUnit
StopPlaceRef[0..1] : StopPlaceCodeFacilityRef[0..1] : FacilityCode
SituationStopPlaceFilter
VehicleJourneyRef[0..1] : VehicleJourneyCodeInterchangeRef[0..1] : InterchangeCodeVehicleRef[0..1] : VehicleCode
SituationJourneyFilter
TM-Mdl::Vehicle
TM-Mdl::VehicleJourney
TM-Mdl::ConnectionLink
1
0..1
requestor
footbicyclecartaxishuttle
«enumeration»Siri Enm::AccessModesEnum
TM-Mdl::StopPoint
TM-Mdl::Operatorplannedunplannedboth
«enumeration»SX-Enm::PredictabilityEnum
TM-Mdl::Line
TM-Mdl::Network
Siri Mdl::Participant
ACSB-Mdl::UserNeed
10..1
1
0..*
filter1
0..* journey
10..*
1
0..1filter
1
0..* stop
1
0..* network
TM-Mdl::Interchange
1
0..1
filter
1
*
requests
1
*
policies
1
*
needs
1
0..*connection
10..*stop place
1
0..*
interchange
1
0..*
vehicle
1
0..1
topic
1
0..*
operator
10..*
unit
Siri Rqs::SubscriptionContext
Siri Rqs::RequestContext
1
0..1
context
1
0..1
context
1
0..*
to stop
10..*
requestor
iFOPT-Mdl::StopPlace
1
0..*
subscriptions
1
*
policies
11 request
Figure 14-2 SituationExchangeRequest - Detail
SIRI-SX: DELIVERY
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 73
SITUATIONEXCHANGEDELIVERY SUMMARY
The SituationExchangeDelivery (Figure 14-3) is returned by the SIRI-SX service and normally contains one or more SituationElement instances; these will either be a BaseSituationElement or an UpdateSituationElement. A Series of one ore more SituationElements describes a Situation. Each SituationElement has a body (either of type PtSItuationBody or RoadSituationBody not shown) which is itself made up of a number of groups of attributes and child elements (eg SituationSource, Consequence). For a further summary of the structured model, see below.
AbstractProducerResponse
ServiceDelivery1 0..1
errors
SituationExchangeDelivery
1
0..*
deliveries
SituationSource[1]SituationStatus[1]TemporalGroup[1]ClassifierGroup[1]DescriptionGroup[0..1]Affects[0..1]Consequences[0..*]PublishingActions[0..1]Extensions[0..1]
«group»PtSituationBody
AffectsScope
AffectedLine
AffectedOperator
AffectedScheduledStop
AffectedVehicleJourneyStartTime[1]EndTime[1]
ValidityPeriod
SituationContext
1
*
situations
1
0..1
context
10..*
operators 1
0..* lines1
0..*
stops
1
0..*
journeys
SIRI-SX Summary PTSituationExchangeDelivery
© 2006 SIRI
Operator
StopPoint
0..*
0..1
stop
CreationTime[1]CountryRef[0..1]ParticipantRef[1]SituationNumber[1]RelatedTo[0..*]VersionedAtTime[0..1]SituationBody[1]
AbstractSituationElement
SituationVersion[0..1]UpdateParticipantCountry[0..1]UpdateParticipantRef[0..1]
UpdateSituationElement
CreationTime[1]SituationRef[1]RelatedAs[1]Extensions[0..1]
RelatedSituation
BaseSituationElement
Country[0..1]SourceType[1]SourceMethod[0..1]Email[0..1]Phone[0..1]Fax[0..1]Web[0..1]Other[0..1]AgentReference[0..1]TimeOfObservation[1]TimeOfCommunication[1]ExternalCode[0..1]Extensions[0..1]
SituationSource
causeeffectcorrectssupercedessupercededByassociation
«enumeration»RelatedEnum
1 0..*
related to
ValidityPeriod[1]Repetitions[0..*]PublicationWindow[1]
«group»TemporalGroup
1
*
when
Reason[1]ReasonName[0..1]PublicEvent[0..1]Severity[1]Priority[0..1]Sensitivity[0..1]Audience[0..1]ReportType[0..1]ScopeType[0..*]Planned[0..1]Keywords[0..*]
«group»ClassifierGroup
1
1
classifiers
Summary[0..1]Description[0..1]Detail[0..1]Advice[0..1]Internal[0..1]Images[0..*]InfoLink[0..*]
«group»DescriptionGroup
11 description
Participant
1
0..*
places
DatedVehicleJourney
Line
0..*
0..1
line
PublishingActions
1
0..1
actions
1
0..*journeyAffectedNetwork
1
0..*
networksNetwork
1 0..*
network
Reason
0..*1reason 1
0..1
source
AffectedPlace
1
0..*
places
Place
0..* 0..1
place
Period[0..1]Condition[0..1]Severiity[1]Affects[0..1]Suitabilities[0..*]Advice[1]Blocking[0..1]Boarding[0..1]Delays[0..1]Casualties[0..1]Easements[0..*]Extensions[0..1]
Consequence
1
0..1
affects
1
0..*
made by
ErrorCondition
AffectedStopPlace
1
0..1
applies
0..*
0..1
operator
0..1
1
affects
1
0..*
consequence
StopPlace
0..*
0..1 stop placeStopPlaceComponent
0..*
0..1
stop place
1 0..*
updates *0..*updated by
AffectedRoute
1
0..*
routes
Route
1
0..*
routes
CountryRef[0..1]ParticipantRef[0..1]
«group»SituationReference
1 1
identifier
Verification[1]Progress[1]Quality[0..1]Reality[0..1]Likelihood[0..1]
«group»SituationStatus
1
1
status
SituationNumber[1]UpdateCountryRef[0..1]UpdateParticipantRef[0..1]SituationVersion[0..1]
«group»SituationElementReference
1 0..*reference to
Reference[1]
ExternalReference
AffectedRoads
1
0..1
roads
GroupOfLocations1
0..1locations
SituationBody
1 1
body
Figure 14-3 SituationExchangeDelivery - Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 74
SITUATIONEXCHANGEDELIVERY DETAIL
Figure 14-6 shows attribute types for a SituationExchangeDelivery. For a further summary of the structured model, see below.
Figure 14-4 SituationExchangeDelivery Detail
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 75
SITUATION MODEL
SITUATION
Figure 14-4 shows the main elements and attributes of the SituationElementl. It has four three basic groups of elements: the TemporalGroup (the time over which that Situation applies), ClassifierGroup (a categorisation of the situation) and a DescriptionGroup (human readable textual descriptions) and SituationStatus . Child elements describe the origin (SituationSource),Consequence and scope of effect (Affects).
Figure 14-5 Situation Main elements
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 76
SITUATION BODY
The PtSituationBody (Figure 14-6Figure 14-5) shows detailed attributes of a SituationElement.
SituationSource[1] : SituationSourceSituationStatus[1] : SituationStatusTemporalGroup[1] : TemporalGroupClassifierGroup[1] : ClassifierGroupDescriptionGroup[0..1] : DescriptionGroupAffects[0..1] : AffectsScopeConsequences[0..*] : ConsequencePublishingActions[0..1] : PublishingActionsExtensions[0..1] : any
«group»PtSituationBody
AffectsScope
StartTime[1] : dateTimeEndTime[1] : dateTime
ValidityPeriod
SIRI PT Situation Body© 2006 SIRI AbstractSituationElement
Country[0..1] : CountryEnumSourceType[1] : SourceEnumSourceMethod[0..1] : SourceMethodEnumEmail[0..1] : emailPhone[0..1] : phoneNumberFax[0..1] : phoneNumberWeb[0..1] : anyURIOther[0..1] : stringAgentReference[0..1] : stringTimeOfObservation[1] : dateTimeTimeOfCommunication[1] : dateTimeExternalCode[0..1] : stringExtensions[0..1] : any
SituationSource
ValidityPeriod[1] : ValidityPeriodRepetitions[0..*] : DayTypePublicationWindow[1] : ValidityPeriod
«group»TemporalGroup
Reason[1] : ReasonReasonName[0..1] : nlStringPublicEvent[0..1] : PublicEventTypeEnumSeverity[1] : TpegSeverityEnumPriority[0..1] : integerSensitivity[0..1] : SensitivityEnumAudience[0..1] : AudienceEnumReportType[0..1] : TpegReportEnumScopeType[0..*] : ScopeTypeEnumPlanned[0..1] : booleanKeywords[0..*] : string
«group»ClassifierGroup
Summary[0..1] : DefaultedTextDescription[0..1] : DefaultedTextDetail[0..1] : DefaultedTextAdvice[0..1] : DefaultedTextInternal[0..1] : DefaultedTextImages[0..*] : ImageInfoLink[0..*] : InfoLink
«group»DescriptionGroup
PublishingActions
ReasonCode[1] : ReasonEnumSubReasonCode[0..1] : SubReasonEnum
Reason
Consequence
emailphonefaxpostfeedradiotvwebpagertextother
«enumeration»SourceEnum
Verification[1] : VerificationEnumProgress[1] : SituationProgressEnumQuality[0..1] : QualityIndexEnumReality[0..1] : InformationStatusEnumLikelihood[0..1] : ProbabilityOfOccurenceEnum
«group»SituationStatus
unknownunverifiedverifiedverifiedAsDuplicate
«enumeration»VerificationEnum draft
draftPendingApprovalapprovedDraftopenclosingclosed
«enumeration»SituationProgressEnum
certainveryReliablereliableunreliableunconfirmed
«enumeration»QualityIndexEnum
veryHighhighmediumlowveryLow
«enumeration»SensitivityEnum
generaloperatornetworkroutelineplacestopPlacestopPlaceComponentstopPointvehicleJourneydatedVehicleJourneyconnectionLinkinterchange
«enumeration»ScopeTypeEnum
publicstaffemergencyServicesmanagementstationStaffinfoServicesauthoritiestransportOperators
«enumeration»AudienceEnum
unknownnetworkroutepointindividualServiceundefined
«enumeration»TpegReportEnum
DayType
unknownverySlightslightnormalsevereverySeverenoImpactundefined
«enumeration»Tpeg-Mdl::TpegSeverityEnum
Image
10..1
image
InfoLink10..1image
1
0..1
image
1
1
classifiers
11status
10..1
actions
1
*
when
1
0..1source
1
0..*
body
1
1
description
10..*
consequence
1
0..*
days1
0..1
applies
0..*
1
reason
10..1 affects0..11affectsrealsecurityExercisetechnicalExercisetest
«enumeration»InformationStatusEnum
certainprobableriskOfimprobable
«enumeration»ProbabilityOfOccurenceEnum
Figure 14-6 SituationExchangeDelivery - SituationBody
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 77
SITUATION AFFECTS SCOPE
The AffectsScope element is used to specify which part sof the network and which services are affected.
AffectsScope
AffectedLine
AffectedOperator
AffectedScheduledStop
AffectedVehicleJourney
Operator
DatedVehicleJourney
Line
AffectedNetwork
Network
Consequence«group»PtSituationBody
AffectedConnectionLink
AffectedCall
AffectedInterchange
Interchange
Route
LineSection
Direction
AffectedStopPlace
Mode
AccessibilityDisruption
SIRI-SX SummarySituation Affects
Scope© 2007
AffectedRoute
RouteLink
10..1
affects1 0..*
consequence
0..11
affects
TopographicPlace
1
0..*
calls
1
0..*
disruptions
1
*
destinations
1
0..*
operator
10..*
journeys
StopPoint
0..*
0..1
stop
Place
AffectedPlace
1
0..*
places
0..*0..1
place
1
0..*
connections
10..*
places
ConnectionLink
1 0..*to stop
0..1
1
link
1
0..*
interchanges
1
0..*
journey
0..*
0..1
line
1
0..*
routes
1
0..*
lines
0..*0..1
direction
0..1 0..1
at
0..*
0..*
mode
1
0..* networks
1
0..*
operators
0..*0..1
operator
1
0..*
operators
1
0..*
network
1
0..*
directions
1
0..*
lines
1
0..*
stops
AffectedStopPlaceComponent
1 0..*components
1
0..*routes
1 0..*
links
1
0..*
links
StopPlace
0..*
0..1
stop place
StopPlaceComponent0..*0..1component
0..1
0..*
section
1
0..*
component
0..*
0..*
mode
0..*
1
interchange0..*
0..1 stop
1
0..*
journey
0..10..*
link
1
0..*
lines
0..*
0..*
affected stops
1
0..*disruptions10..*
accessibility
1
0..*
routes
1
0..1roads
AffectedRoads
Figure 14-7 SIRI-SX Affects Summary
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 78
SITUATION AFFECTS SCOPE
SCHEDULED JOURNEYS
Figure 14-8 shows detailed attributes for the scope elements used to relate Situations to parts of the network and to specific journeys.
Figure 14-8 Affects Scope - Scheduled Journeys
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 79
SITUATION AFFECTS SCOPE STOP PLACE
Figure 14-9 shows detailed attributes for the scope elements used to relate SituationElements to parts of the stop place. These can include accessibility properties
PlaceRef[1] : PlaceIdPlaceName[0..1] : nlStringPlaceType[0..1]Location[0..1] : LocationAccessibilityDisruption[0..1] : AccessibilityDisruptionExtensions[0..1] : any
AffectedPlace
ComponentRef[1] : ComponentIdComponentName[0..1] : nlStringComponentType[1] : ComponentTypeEnumAccessFeatureType[0..1]Extensions[0..1]
AffectedStopPlaceComponent
MobilityImpairedAccess[1] : booleanLiimitations[0..1] : LimitationSuitabilities[0..*] : Suitability
ACSB-Mdl::AccessibilityDisruption
0..*
0..1
component
UserNeed[1] : nmtokenSuitable[1] : SuitableEnum
ACSB-Mdl::Suitability
StopPlaceRef[1] : StopPlaceCodePlaceName[0..1] : nlStringStopPlaceType[1] : StopPlaceTypeEnumComponents[0..*] : AffectedStopPlaceComponentNavigationPaths[0..*] : ComponentIdExtensions[0..1] : any
AffectedStopPlace
1
0..*
components
SIRI-SX Situation Affects
Scope - Stop Place© 2007
AccessibilityDisruption[0..1] : AccessibilityDisruption
AffectedStopPlaceElement
iFOPT-Mdl::QuayiFOPT-Mdl::AccessSpace
AbstractStopPlaceSpace
iFOPT-Mdl::StopPathLink
iFOPT-Mdl::StopPlaceComponent
1
0..*suitabilities
WheelchairAccess[0..1] : AccessibilityEnumStepFreeAccess[0..1] : AccessibilityEnumEscalatorFreeAccess[0..1] : AccessibilityEnumLiftFreeAccess[0..1] : AccessibilityEnumAudibleSignsAvailable[0..1] : AccessibilityEnumVisualSignsAvailable[0..1] : AccessibilityEnum
ACSB-Mdl::Limitation
1
0..*
limitation
iFOPT-Mdl::BoardingPosition
iFOPT-Mdl::Level
AbstractPathLink
0..* 1
level
0..*
0..1
stop place
1
0..1accessibility
truefalseunknown
«enumeration»ACSB-Mdl::AccessibilityEnum
1
0..*
stops
1
0..*
accessibility
airportrailStationmetroStationcoachStationbusStationshipPortferryPortferryStoponStreetBusonStreetTramskiLiftother
«enumeration»iFOPT-Mdl::StopPlaceTypeEnum
quayaccessSpaceboardingPositionstoppingPlacestoppingPositionentrancestopPathLinkaccessPathLinkother
«enumeration»iFOPT-Mdl::ComponentTypeEnum
iFOPT-Mdl::AccessPathLink
unknownliftescalatortravelatorrampstairsshuttlenarrowEntrancebarrierlowFloorAccess
«enumeration»iFOPT-Mdl::AccessFacilityEnum
AreaOfInterest[0..1] : AreaOfInterestEnumOperators[0..*] : AffectedNetworkNetworks[0..*] : AffectedOperatorLines[0..*] : AffectedLineStopPlaces[0..*] : AffectedStopPlaceStopPoints[0..*] : AffectedScheduledStopPlaces[0..*] : AffectedPlaceVehicleJourneys[0..*] : AffectedVehicleJourneyRoads[0..1] : AffectedRoadsExtensions[0..1] : any
AffectsScope
1
0..*
places
TM-Mdl::Place
0..*
0..1
suitablenotSuitableunknown
«enumeration»ACSB-Mdl::SuitableEnum
iFOPT-Mdl::StopPlace
continentWidenationalneighbouringCountriesnotSpecifiedregional
«enumeration»DX2-DTs::AreaOfInterestEnum
AffectedRoads
1
0..1
DX2-Mdl::GroupOfLocations
1
0..1
locations
Figure 14-9 Affects Scope - Stop Place
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 80
15. SIRI COMMON DATA TYPES
COMMON SIRI DATA TYPES
XML SIMPLE TYPES
The SIRI-SX services use XML data types for primitive data types where possible (Figure 15-1).
Figure 15-1 XML simple data types
COMMON SIRI DATA TYPES
The SIRI-SX services use a number of common SIRI complex data types (Figure 15-2).
CapabilityCode[1]
Errors::CapabilityNotSupportedError Errors::OtherError
-ErrorText[1] : string
Errors::AbstractError-Error[1] : AbstractError-Description[1] : ErrorDescription
Siri Rqs::ErrorCondition
1 1
Errors::NoInfoForTopicErrorErrors::AccessNotAllowedError
SIRI Simple ErrorTypes
© 2006 SIRI
id[0..1] : nmtokensrsName[0..1] : stringLongitude[0..1] : LongtitudeLatitude[0..1] : LatitudeCoordinates[0..1] : CoordinatesPrecision[0..1] : distance
Loc Mdl::Location
SIRI Complex Data Types
© 2006 SIRI
Errors::AllowedResourceUsageExceeded
EquipmentAvailability[0..1]SituationRef[0..1] : SituationCodeMobilityDisruption[0..1]
FacilityChange
EquipmentRef[0..1] : EquipmentCodeDescription[0..1] : populatedStringEquipmentStatus[1] : EquipmentStatusValidityPeriod[0..1] : HalfOpenTimestampRangeEquipmentTypeRef[0..1] : EquipmentTypeCodeEquipmentFeatures[0..*] : EquipmentFeatureCode
EquipmentAvailability
MobilityImpairedAccess[0..1]MobilityFacility[0..1] : MobilityFacility
MobilityDisruption
1
0..1
1
0..1
StartTime[1] : dateTimeEndTime[0..1] : dateTime
HalfOpenTimestampRange
nlString[1] : nlStringoverridden[0..1]
SX-Mdl::DefaultedTextUri[1] : anyURILabel[1] : nlStringImage[1] : ImageLinkContent[1] : LinkContentEnum
InfoLink
ImageRef[0..1]ImageBinary[0..1]ImageContent[0..1] : ImageContentEnum
Image
1 0..1
image
mapgraphiclogo
«enumeration»Siri Enm::ImageContentEnum
detailsadvicetimetablerelatedSiteother
«enumeration»Siri Enm::LinkContentEnum
-Mode[1]-SubMode[0..1] : TpegSubMode
TM-Mdl::ModeTpegSubMode
-DataFrameRef : DataFrameCode-DatedVehicleJourneyRef : DatedVehicleJourneyCode
«group»FramedVehicleJourneyRef
Figure 15-2 UML Diagram of Common SIRI Data Types
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 81
COMMON SIRI SIMPLE DATA TYPES
CODES & IDENTIFIERS
As well as the XML simple data types, SIRI uses a number of additional simple data types see Figure 15-3. Many of these are just explicitly typed identifiers for entities These have primitive type of string or NMTOKEN).
Figure 15-3 Common SIRI Simple Data types
Figure 15-4 shows simple data types use din SIRI to identify Transmodel entities.
«datatype»DataFrameCode
«datatype»OperationalUnitCode
«datatype»OperatorCode
«datatype»DirectionCode
«datatype»ConnectionLinkCode
«datatype»JourneyPatternCode
«datatype»NetworkCode
«datatype»StopPointCode
«datatype»CourseOfJourneyCode
«datatype»BlockCode
«datatype»DatedVehicleJourneyCode
«datatype»VehicleJourneyCode
«datatype»InterchangeCode
«datatype»VehicleCode
«datatype»RouteCode
«datatype»LineCode
«datatype»PlaceId
«datatype»TrainPartCode
SIRIIdentifier Simple DataTypes
For Transmodel entities© 2006 SIRI
«datatype»IFOPT-DTs::ComponentId
«datatype»IFOPT-DTs::StopPlaceCode
«datatype»TimetableVersionCode
«datatype»TrainPartCode
«datatype»ZoneCode
«datatype»IFOPT-DTs::StopPlaceId
Figure 15-4 Common Identifier types used in SIRI for Transmodel entities
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 82
COMMON GENERAL SIRI ENUMERATIONS
The SIRI-SX services use a number of common SIRI enumerations. The common SIRI enumerations are listed in Figure 15-5
Figure 15-5 UML Diagram of SIRI enumerations
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 83
SIRI-SX ENUMERATIONS
Figure 15-6 summaries the enumerations that are specific to SIRI-SX. These also appear in context on individual diagrams.
unknownunverifiedverifiedverifiedAsDuplicate
«enumeration»VerificationEnum
certainveryReliablereliableunreliableunconfirmed
«enumeration»QualityIndexEnum
draftdraftPendingApprovalapprovedDraftopenclosingclosed
«enumeration»SituationProgressEnum
publicstaffemergencyServicesmanagementstationStaffinfoServicesauthoritiestransportOperators
«enumeration»AudienceEnum
veryHighhighmediumlowveryLow
«enumeration»SensitivityEnum
bothfromto
«enumeration»ConnectionDirectionEnum
SIRI-SX Enumerations
© 2006 SIRI
plannedunplannedboth
«enumeration»PredictabilityEnum
generaloperatornetworkroutelineplacestopPlacestopPlaceComponentstopPointvehicleJourneydatedVehicleJourneyconnectionLinkinterchange
«enumeration»ScopeTypeEnum
causeeffectcorrectssupercedessupercededByassociation
«enumeration»RelatedEnum
emailphonefaxpostfeedradiotvwebpagertextother
«enumeration»SourceEnum
editableversionedreleased
«enumeration»ElementStatusEnum
continentWidenationalneighbouringCountriesnotSpecifiedregional
«enumeration»DX2-DTs::AreaOfInterestEnum
automobileClubPatrolcameraObservationfreightVehicleOperatorinductionLoopMonitoringStationmicrowavedMonitoringStationmobileTelephoneCallernonPoliceEmergencyServicesPatrolotherInformationotherOfficialVehiclepolicePatrolprivateBreakdownServicepublicAndPrivateUtilitiesregisteredMobileObserverroadAuthoritiesroadOperatorPatrolroadsideTelephoneCallerspotterAircrafttrafficMonitoringStationtransitOperatorvehicleProbeMeasurementvideoProcessingMonitoringStation
«enumeration»DX2-DTs::RoadSourceMethodEnum
realsecurityExercisetechnicalExercisetest
«enumeration»DX2-DTs::InformationStatusEnum
SIRI-SX / Datex2 Enumerations
© 2008 SIRI
«enumeration»SX-Enm-DTX::SourceMethodEnum
certainprobableriskOfimprobable
«enumeration»DX2-DTs::ProbabilityOfOccurenceEnum
delayLongerThanSixHoursdelayBetweenThreeHoursAndSixHoursdelayBetweenOneHourAndThreeHoursdelayBetweenThirtyMinutesAndOneHoursdelayLessThanThirtyMinutesnegligble
«enumeration»DX2-DTs::DelayBandEnum
delaysdelaysOfLongDurationlongDelaysveryLongDelays
«enumeration»DX2-DTs::DelayTypeEnum
athleticsMeetingballGamebaseballGamebasketballGamebycycleRaceboatRaceboxingTournamentbullFightceremonialEventconcertcricketMatchexhibitionfairfestivalfilmTVMakingfootballMatchfunfairgolfTournamenthockeyGamehorseRaceMeetinginternationalSportsMeetingmajorEventmarathonmarketmatchmotorSportRaceMeetingparaderaceMeetingrugbyMatchseveralMajorEventsshowshowJumpingsportsMeetingstateOccassiontennisTournamenttournamenttradeFairwaterSportsMeetingwinterSportsMeetingother
«enumeration»DX2-DTs::PublicEventTypeEnum
Figure 15-6 UML Diagram of SIRI-SX Enumerations
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 84
IFOPT ENUMERATIONS FOR SIRI-SX
Figure 15-7 summarises the IFOPT STOP PLACE enumerations that are used in SIRI-SX. These mostly also appear in context on individual UML diagrams.
Figure 15-7 UML Diagram of IFOPT Stop Place Enumerations
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 85
TPEG MISCELLANEOUS ENUMERATIONS FOR SIRI-SX
Figure 15-8 summarises the miscellaneous TPEG enumerations that are used in SIRI-SX. These mostly also appear in context on individual UML diagrams.
unknownalteredcancelleddelayeddivertednoServicedisruptedadditionalServicespecialServiceonTimenormalServiceintermittentServiceshortFormedServicefullLengthServiceextendedServicesplitingTrainreplacementTransportarrivesEarlyshuttleServicereplacementServiceundefinedServiceInformation
«enumeration»TpegServiceConditionEnum
unknownverySlightslightnormalsevereverySeverenoImpactundefined
«enumeration»TpegSeverityEnum
TPEG MiscellaneousEnumerations
© 2007 SIRI
unknownmondaytuesdaywednesdaythursdayfridaysaturdaysundaymondayToFridaymondayToSaturdayweekendspublicHolidayholidayregionalHolidaynationalHolidaysundaysAndPublicHolidaysschooldayseverydayundefinedDayType
«enumeration»TpegDayTypeEnum
TPEG pti_34
Tpeg pti-26
unknownallTicketClassesValidfullFareOnlycertainTicketsOnlyticketWithReservationspecialFareonlyTicketsOfSpecifiedOperatornoRestrictionsnoOffPeakTicketsnoWeekendReturnTicketsnoReducedFareTicketsunknwonTicketRestriction
«enumeration»TpegTicketRestrictionEnum
tpeg pti_25
tpeg pti_13
unknownnetworkroutepointindividualServiceundefined
«enumeration»TpegReportEnum
tpeg pti_27
unknownstartPointdestinationstopvianotStoppingtemporaryStoptemporarilyNotStoppingexceptionalStopadditionalStoprequestStopfrontTrainDestinationrearTrainDestinationthroughServiceDestinationnotViaalteredStartPointalteredDestinationundefinedRoutePoint
«enumeration»TpegRoutePointEnum
tpeg pti_5
unknownconnectionreplacementalternativeconnectionNotHeldconnectionHeldstatusOfConnectionUndecidedundefined
«enumeration»TpegInterchangeStatusEnum
tpeg pti 31
Figure 15-8 UML Diagram of TPEG Enumerations
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 86
TPEG MODE ENUMERATIONS
Figure 15-9 summarises the TPEG mode enumerations that are used in SIRI-SX. These mostly also appear in context on individual UML diagrams.
Figure 15-9 UML Diagram of Tpeg submodes
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 87
16. ANNEX A NOTATION
The diagrams in this document follow normal UML notation for class diagrams with the addition of colour (see below), and the use of certain conventions to represent composition as used in XML.
ENTITIES
Classes are indicated by square boxes with the name of the class across the top. Operations and Visibility are omitted. The attributes types, or all of the attributes may be suppressed in summary diagrams, or to show a summary reference.
ENUMERATIONS
Enumerations are generally shown as data types a square box with an <<enumeration>> stereotype. They are included in diagrams in context if space permits, using a dependency relationship (dotted line) from the class with attributes that are constrained by the enumeration. They are also summarised on separate diagrams at the end. Visibilities are omitted.
GROUPS
As well as the normal use of Classes to indicate the entities of the model, classes are also used for named groups of reusable elements which occur on more than one entity, for example AimedArrivalInfo, or ServiceInfo
see discussion of serialisation and containment below. In this case a steorotype of <<group>> is shown. These can be considered as complex data types.
NOTES
Notes are indicated as boxes with turned up corners, generally connected to the class or relationship they annotate with a dotted dependency line.
RELATIONSHIPS
Normal UML relationships are used:
1. Inheritance: line with white arrow from subtype to supertype. The subtype has all the attributes and operations of the supertype.
2. Association: other unbroken lines.
Cardinalities of associations are marked using UML conventions for multiplicities and optionality, i.e. min:max, for example [ 0:1] indicates there may be a minimum of zero and a maximum of one, [1:*] indicates there must be a minimum of one and there can be many. [1] by itself means [1:1]. [*] by itself means [0:*]. The multiplicities indicate if there are one or many. The optionality indicates whether the end must be populated if the relationship is present.
Aggregation is indicated by a black diamond (this typically corresponds to direct containment in an XML document): indicating the part is created and destroyed with the whole.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 88
A shared composition is indicated by a white diamond, in which case the child element is integral to the parent component, but the child exists independently (and typically will have a unique identifier).
Direction of Navigability is indicated by an arrow head in the direction of navigability.
3. Dependency: Dotted Line. These are also used to show enumerated values
USE OF COLOUR
To facilitate reading, Classes are coloured to indicate their nature. This is purely a local Handbook convention (not part of UML) and is used as follows
Purple: Common Abstract Message Transport Framework elements. Typically these are the request & response wrapper elements. E.g. ServiceDelivery and are the same for all Functional services.
Salmon: Common Abstract Transport Framework elements, Typically these are supertypes. E.g. AbstractItem
Orange: Functional Service Elements. E.g. StopMonitoringDelivery. These are specific and different for each service, but populated to a common pattern, e.g. with xxxTopics. xxxPolicies, xxxDeliveries etc
Yellow: Domain model elements that correspond to the main payload content of deliveries: typically these are views of Transmodel entities. Dark yellow indicates the concrete container class, e.g. MonitoredVehicleJourney. Light Yellow indicates an embedded reusable element that makes up part of a concrete composite (And may correspond to a Transmodel Entity).
White: References to the identifiers domain model entities, corresponding to the Transmodel concepts.
SERIALISATION: CONTAINMENT & REFERENCE
The primary concrete expression of SIRI is as an XML schema, for which object references must be serialised either through containment (i.e. expressing an aggregation by embedding a child entity within a parent element s tags) or reference (i.e. serialising an association by including a reference to the identifier of the associated entity. It is therefore useful to adopt diagramming and naming conventions that indicate whether a particular relationship is expressed in the SIRI XML schema by containment or by reference.
An explicit attribute is shown on the UML diagrams to indicate an aggregation relationship is implemented as physical containment, using the element name indicated by the attribute. The attribute name will be in the plural if the multiplicity is many . The data type of the attribute will be that of the contained element. For example, the DatedCalls attribute in Figure 16-2 below holds multiple instances of DatedCall..
An explicit attribute is shown on the UML diagrams to indicate that an association is serialised as a reference. The attribute name on the referring entity generally ends in Ref to indicate a reference to another entity, and the data type name generally ends in Code or Id . The data type of the attribute will be the unique identifier of the referenced element.
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 89
For example, the StopPointRef attribute in Figure 16-2 below which implements the reference from DatedCall to StopPoint is of type StopPointCode.
In addition, Where attribute values are constrained to particular values a dotted line to a enumeration is shown. E.g. the line to ArrivalActivityEnum in Figure 16-2 below.
Where attributes are grouped as XML groups and used to compose different entities, a class is used to indicate the group. Such classes are usually shown in a lighter shade of colour with a stereotype of <<group>>. For example the AimedArrivalInfoclass in Figure 16-2 below.
ALTERNATIVE REPRESENTATIONS OF XML STRUCTURES IN UML
Note that to depict a pure object model in UML one does not strictly need to show an explicit attribute in the parent for a child component (it could be represented just by an association to the contained element), but doing so helps to make clear the order in which attributes appear in the XML and the name of any wrapper tag used to group multiple child instances. Similarly other associations do not strictly need to show the implementing attribute. In the UML diagrams for SIRI we therefore generally show an attribute with which to implement each association.
UML supports a variety of ways for depicting the reuse of data structures, corresponding to different OO programming mechanisms, for example, by inheritance (single or multiple) using either class inheritance or interface conformance; or by aggregation, embedding complex data types in more than one entity. XML allows only single parent class inheritance, so the SIRI XML schema makes greater use of composition than of inheritance, assembling standard data structures (encoded as Groups in XML) into concrete classes. For clarity, we therefore often show these groups in the diagrams as distinct classes with a <<group>> stereotype, even though in the concrete XML they are repeated inline.
We illustrate these differences in Figure 16-1 and Figure 16-2 below, which show two different representations in UML of the same model of a timetable (this is a simplified version of the SIRI Dated Journey).
In Figure 16-1, no attributes are shown to implement the aggregation, and all the attributes are shown in-line. References to external entities are shown as attributes though these too might be omitted (JourneyPatternRef, BlockRef, CourseOfJourneyRef, StopPointRef).
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 90
Figure 16-1 Simple Object model
In Figure 16-2, an attribute Calls is shown on DatedVehicleJourney to implement the DatedCalls aggregation. Furthermore, certain of the attributes which occur in groups that are reused elsewhere are shown as separate view classes (JourneyPatternInfo, AimedArrivalInfo, AimedDepartureInfo, StopPointInSequence), with a <<group> stereotype. These are inlined in the XML. Points where extensions may be added are indicated by an Extensions attribute. Operations are not shown.
The data structures are functionally equivalent.
Figure 16-2 Explicit representation of references and of groups
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 91
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>
<!-- Inherited properties -->
<JourneyPatternRef>JP56789T</JourneyPatternRef>
<!-- Specific properties -->
<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>
<!-- == CALL 1 == -->
<DatedCall>
<! Stop point in sequence Group -->
<StopPointRef>HLTS00101</StopPointRef>
<StopName>Market Place</StopName >
<DestinationDisplay>Hospital</DestinationDisplay>
<!-- Departure Info Group -->
<AimedDepartureTime>2001-12-17T09:32:47-05:00</AimedDepartureTime >
<DeparturePlatformName>Stance 1</DeparturePlatformName>
</DatedCall>
<!-- == CALLl 2 ==-->
<DatedCall>
<! Stop point in sequence Group -->
<StopPointRef>HLTS00102</StopPointRef>
<StopName>Hospital</StopName>
<DestinationDisplay>Station</DestinationDisplay>
<!--Arrival Info Group -->
<AimedArrivalTime>2001-12-17T09:38:47-05:00</AimedArrivalTime>
<!-- Departure Info Group -->
<AimedDepartureTime>2001-12-17T09:39:47-05:00</AimedDepartureTime>
</DatedCall>
<!-- == CALL 3 == -->
<DatedCall>
<! Stop point in sequence Group -->
<StopPointRef>HLTS00103</StopPointRef>
< StopName>Main Station</ StopName >
<!--Arrival Group -->
<AimedArrivalTime>2001-12-17T09:40:47-05:00</AimedArrivalTime>
<!-- Departure Info Group -->
<AimedDepartureTime>2001-12-17T09:43:47-05:00</AimedDepartureTime>
<DepartureBoardingActivity>NoBoarding</DepartureBoardingActivity>
</DatedCall>
..
</Calls>
</DatedVehicleJourney>
</DatedTimetableVersionFrame>
SIRI Functional Services - UML Diagrams
© Copyright Kizoom 2006-2007 Page 92
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