CEN/TS 15531-3:2007

SLOVENSKI STANDARD
01-februar-2009
-DYQLSUHYR]9PHVQLN]DLQIRUPLUDQMHYUHDOQHPþDVX]DSRWUHEHGHORYDQMD
MDYQHJDSUHYR]DGHO)XQNFLRQDOQLYPHVQLNLVWRULWYH
Public transport - Service interface for real-time information relating to public transport
operations - Part 3: Functional service interfaces
Öffentlicher Verkehr - Dienstleistungsschnittstelle für zeitnahe Informationen zum Betrieb
des öffentlichen Verkehrs - Teil 3: Funktionale Dienstleistungsschnittstellen
Ta slovenski standard je istoveten z: CEN/TS 15531-3:2007
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 15531-3
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
July 2007
ICS 35.240.60
English Version
Public transport - Service interface for real-time information
relating to public transport operations - Part 3: Functional
service interfaces
Öffentlicher Verkehr - Dienstleistungsschnittstelle für
zeitnahe Informationen zum Betrieb des öffentlichen
Verkehrs - Teil 3: Funktionale Dienstleistungsschnittstellen
This Technical Specification (CEN/TS) was approved by CEN on 23 October 2006 for provisional application.
The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.
CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Cyprus, Czech Republic, Denmark, Estonia, Finland,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,
Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre: rue de Stassart, 36  B-1050 Brussels
© 2007 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15531-3:2007: E
worldwide for CEN national Members.

Contents Page
Foreword.6
Introduction .7
1 Scope .8
2 Normative references .8
3 Terms and definitions .8
4 Symbols and abbreviations .9
5 Production Timetable Service [PT] .9
5.1 Purpose.9
5.2 Capability and Permission Matrices .9
5.2.1 Capability Matrix .9
5.2.2 Permission Matrix.10
5.3 ProductionTimetableRequest.10
5.3.1 ProductionTimetableRequest Definition .10
5.3.2 ProductionTimetableRequest Example.11
5.4 ProductionTimetableSubscriptionRequest.12
5.4.1 ProductionTimetableSubscriptionRequest Definition.12
5.4.2 ProductionTimetableSubscriptionRequest Example.12
5.5 ProductionTimetableDelivery.13
5.5.1 General.13
5.5.2 ServiceDelivery with a ProductionTimetableDelivery.13
5.5.3 ProductionTimetableDelivery Element.13
5.5.4 DatedTimetableVersionFrame Element.13
5.5.5 ProductionTimetableDelivery Example .17
5.5.6 Efficient Delivery of Large Timetables .20
6 Estimated Timetable Service [ET].20
6.1 Purpose.20
6.2 Capability and Permission Matrices .20
6.2.1 Capability Matrix .20
6.2.2 Permission Matrix.21
6.3 EstimatedTimetableRequest.22
6.3.1 EstimatedTimetableRequest Definition.22
6.3.2 EstimatedTimetableRequest Example.23
6.4 EstimatedTimetableSubscriptionRequest .24
6.4.1 EstimatedTimetableSubscriptionRequest Definition.24
6.4.2 EstimatedTimetableSubscriptionRequest Example.24
6.5 The EstimatedTimetableDelivery .25
6.5.1 General.25
6.5.2 ServiceDelivery with a EstimatedTimetableDelivery.25
6.5.3 EstimatedTimetableDelivery Element.25
6.5.4 EstimatedTimetableVersionFrame Element.25
6.5.5 EstimatedVehicleJourney Element.26
6.5.6 EstimatedTimetableDelivery Example.29
6.6 Handling of Predictions in the Estimated Timetable Service.31
6.6.1 Supplementary Rule for the Delay Profile.31
6.6.2 Other Supplementary Rules .32
6.6.3 Quality of Prognoses and Prediction Windows.32
6.6.4 Reporting Rules and Monitored Journeys .33
6.6.5 Temporal Reporting Behaviour – Sensitivity Threshold .34
6.6.6 Prediction Inaccurate – In Congestion.35
6.6.7 Unexpected Termination of Monitoring .35
6.7 General Rules and Definitions for Timetable Data.36
6.7.1 General .36
6.7.2 Cancelled Vehicle Journeys.36
6.7.3 Additional Vehicle Journeys .36
6.7.4 Changes to Journeys & Routings.37
6.7.5 Changes to Call Attributes .37
6.7.6 Planned Connections and “Stay Seated” Connections .37
6.7.7 Handling Train Data.37
7 Stop Timetable Service [ST].38
7.1 Purpose .38
7.2 Reference Data .38
7.3 Capability and Permission Matrices.38
7.3.1 Capability Matrix.38
7.3.2 Permission Matrix.39
7.4 StopTimetableRequest.40
7.4.1 StopTimetableRequest Definition.40
7.4.2 StopTimetableRequest Example.40
7.5 StopTimetableSubscriptionRequest .41
7.5.1 StopTimetableSubscriptionRequest Definition.41
7.5.2 StopTimetableSubscriptionRequest Example .41
7.6 StopTimetableDelivery.41
7.6.1 General .41
7.6.2 ServiceDelivery with a StopTimetableDelivery .42
7.6.3 StopTimetableDelivery Element.42
7.6.4 TimetabledStopVisit Element.42
7.6.5 TargetedVehicleJourney Element.43
7.6.6 TargetedCall Element.43
7.6.7 TimetabledStopVisitCancellation Element .44
7.6.8 StopTimetableDelivery Example.44
7.6.9 TargetedVehicleJourneyAsFlatGroup Element.45
8 Stop Monitoring Service [SM] .46
8.1 Purpose .46
8.2 Reference Data .46
8.2.1 General .46
8.2.2 Content Referencing .46
8.2.3 Direct Cleardown.46
8.3 Capability and Permission Matrices.47
8.3.1 Capability Matrix.47
8.3.2 Permission Matrix.48
8.4 StopMonitoringRequest.49
8.4.1 StopMonitoringRequest Definition .49
8.4.2 Use of PreviewInterval .50
8.4.3 StopMonitoringRequest Detail Levels.50
8.4.4 Use of Maximum and Minimum Number of Trips.50
8.4.5 StopMonitoringRequest Example.51
8.5 StopMonitoringSubscriptionRequest.52
8.5.1 StopMonitoringSubscriptionRequest Definition.52
8.5.2 Sensitivity Threshold .52
8.5.3 StopMonitoringSubscriptionRequest Example.53
8.6 StopMonitoringDelivery.54
8.6.1 General .54
8.6.2 ServiceDelivery with a StopMonitoringDelivery.54
8.6.3 StopMonitoringDelivery Element.54
8.6.4 MonitoredStopVisit Element.55
8.6.5 MonitoredStopVisitCancellation Element.61
8.6.6 StopLineNotice Element .62
8.6.7 StopLineNoticeCancellation Element.63
8.6.8 MonitoredStopVisit with MonitoredVehicleJourneyAsGroup Element.63
8.6.9 StopMonitoringDelivery Examples .64
8.7 Using the Stop Timetable & Stop Monitoring services together .72
9 Vehicle Monitoring Service [VM].72
9.1 Purpose.72
9.2 Reference Data.72
9.3 Capability and Permission Matrices .72
9.3.1 Capability Matrix .72
9.3.2 Permission Matrix.74
9.4 VehicleMonitoringRequest .74
9.4.1 VehicleMonitoringRequest Definition.74
9.4.2 VehicleMonitoringDetailLevel.75
9.4.3 VehicleMonitoringRequest Example.75
9.5 VehicleMonitoringSubscriptionRequest .76
9.5.1 VehicleMonitoringSubscriptionRequest Definition.76
9.5.2 Sensitivity Threshold .77
9.5.3 VehicleMonitoringSubscriptionRequest Example .77
9.6 VehicleMonitoringDelivery.78
9.6.1 General.78
9.6.2 ServiceDelivery with a VehicleMonitoringDelivery .78
9.6.3 VehicleMonitoringDelivery Element.78
9.6.4 VehicleActivity Element .79
9.6.5 VehicleActivityCancellation Element.83
9.6.6 VehicleActivity with MonitoredVehicleJourneyAsGroup Element .84
9.6.7 VehicleMonitoringDelivery Examples.84
10 Connection Timetable Data Service [CT] .89
10.1 Purpose.89
10.2 Reference Data.90
10.2.1 Content referencing.90
10.2.2 Availability of Data.91
10.2.3 Updating During the Course of a Journey .92
10.3 Capability and Permission Matrices .92
10.3.1 Capability Matrix .92
10.3.2 Permission Matrix.93
10.4 ConnectionTimetableRequest.94
10.4.1 ConnectionTimetableRequest Definition .94
10.4.2 ConnectionTimetableRequest Example .95
10.5 ConnectionTimetableSubscriptionRequest.95
10.5.1 ConnectionTimetableSubscriptionRequest Definition .95
10.5.2 ConnectionTimetableSubscriptionRequest Example.95
10.6 ConnectionTimetableDelivery .96
10.6.1 General.96
10.6.2 ServiceDelivery with a ConnectionTimetableDelivery.96
10.6.3 ConnectionTimetableDelivery Element .96
10.6.4 TimetabledFeederArrival with InterchangeJourneyAsFlatGroup Element.99
10.6.5 ConnectionTimetableDelivery Example .100
11 Connection Monitoring Service [CM].102
11.1 Purpose.102
11.1.1 General.102
11.1.2 Dated Vehicle-Journey-Based Connection Protection .102
11.1.3 Time-Based Connection Protection.103
11.2 Capability and Permission Matrices .103
11.2.1 Capability Matrix .103
11.2.2 Permission Matrix.104
11.3 The ConnectionMonitoringRequest.104
11.3.1 ConnectionMonitoringRequest Definition .104
11.3.2 Use of PreviewInterval .105
11.3.3 ConnectingTimeFilter.105
11.3.4 ConnectingJourneyFilter.106
11.3.5 ConnectionMonitoringRequest Example .106
11.4 The ConnectionMonitoringSubscriptionRequest .107
11.4.1 ConnectionMonitoringSubscriptionRequest Definition .107
11.4.2 Sensitivity Threshold .107
11.4.3 ConnectionMonitoringSubscriptionRequest Example.108
11.5 ServiceDelivery with a Connection Monitoring Deliveries.108
11.5.1 General .108
11.5.2 The ConnectionMonitoringFeederDelivery.109
11.5.3 The ConnectionMonitoringDistributorDelivery .112
12 General Message Service [GM].116
12.1 Purpose .116
12.2 Reference Data .117
12.2.1 Use of Reference Data .117
12.2.2 Message Formats .117
12.3 Capability and Permission Matrices.117
12.3.1 Capability Matrix.117
12.3.2 Permission Matrix.118
12.4 The GeneralMessageRequest .118
12.4.1 GeneralMessageRequest Definition .118
12.4.2 GeneralMessageRequest Example.119
12.5 The GeneralMessageSubscriptionRequest .119
12.5.1 GeneralMessageSubscriptionRequest Definition.119
12.5.2 GeneralMessageSubscriptionRequest Example.120
12.6 The GeneralMessageDelivery .120
12.6.1 General .120
12.6.2 ServiceDelivery with a GeneralMessageDelivery.120
12.6.3 GeneralMessageDelivery Element.120
12.6.4 InfoMessage Element.121
12.6.5 InfoMessageCancellation Element .121
12.6.6 GeneralMessageDelivery Example.122

Foreword
This document (CEN/TS 15531-3:2007) has been prepared by Technical Committee CEN/TC 278 “Road
transport and traffic telematics”, the secretariat of which is held by NEN.
This presents Part 3 of the European Technical Specification known as “SIRI”. SIRI provides a framework for
specifying communications and data exchange protocols for organisations wishing to exchange Real-time
Information (RTI) relating to public transport operations.
SIRI is presented in three parts:
• Context and framework, including background, scope and role, normative references, terms and
definitions, symbols and abbreviations, business context and use cases (Part 1).
• The mechanisms to be adopted for data exchange communications links (Part 2).
• Data structures for a series of individual application interface modules (Part 3).
The XML schema can be downloaded from http://www.siri.org.uk/, along with available guidance on its use,
example XML files, and case studies of national and local deployments.
It is recognised that SIRI is not complete as it stands, and there will be a substantial amount of work required
to continue to develop SIRI over the coming years. It is therefore intended that a SIRI Management Group
should continue to exist, at European level, based on the composition of SG7.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this CEN Technical Specification: Austria, Belgium, Bulgaria, Cyprus, Czech
Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain,
Sweden, Switzerland and United Kingdom.
Introduction
Public transport services rely increasingly on information systems to ensure reliable, efficient operation and
widely accessible, accurate passenger information. These systems are used for a range of specific purposes:
setting schedules and timetables; managing vehicle fleets; issuing tickets and receipts; providing real-time
information on service running, and so on.
This Technical Specification specifies a Service Interface for Real-time Information (SIRI) about Public
Transport. It is intended to be used to exchange information between servers containing real-time public
transport vehicle or journey time data. These include the control centres of transport operators and information
systems that utilise real-time vehicle information, for example, to deliver services such as travel information.
Well-defined, open interfaces have a crucial role in improving the economic and technical viability of Public
Transport Information Systems of all kinds. Using standardised interfaces, systems can be implemented as
discrete pluggable modules that can be chosen from a wide variety of suppliers in a competitive market, rather
than as monolithic proprietary systems from a single supplier. Interfaces also allow the systematic automated
testing of each functional module, vital for managing the complexity of increasing large and dynamic systems.
Furthermore, individual functional modules can be replaced or evolved, without unexpected breakages of
obscurely dependent function.
This Technical Specification will improve a number of features of public transport information and service
management:
• Interoperability – the Technical Specification will facilitate interoperability between information processing
systems of the transport operators by: (i) introducing common architectures for message exchange; (ii)
introducing a modular set of compatible information services for real-time vehicle information; (ii) using
common data models and schemas for the messages exchanged for each service; and (iv) introducing a
consistent approach to data management.
• Improved operations management – the Technical Specification will assist in better vehicle management
by (i) allowing the precise tracking of both local and roaming vehicles; (ii) providing data that can be used
to improve performance, such as the measurement of schedule adherence; and (iii) allowing the
distribution of schedule updates and other messages in real-time.
• Delivery of real-time information to end-users – the Technical Specification will assist the economic
provision of improved data by; (i) enabling the gathering and exchange of real-time data between VAMS
systems; (ii) providing standardised, well defined interfaces that can be used to deliver data to a wide
variety of distribution channels.
Technical advantages include the following:
• Reusing a common communication layer for all the various technical services enables cost-effective
implementations, and makes the Technical Specification readily extensible in future.

1 Scope
There are many potential ways for passenger transport operations centres to interact. The approach taken by
SIRI is for an open-ended set of standard data structures, carried over a communications channel constructed
using one of a small number of specific options.
Part 2 of this Technical Specification specifies the communications channel. This section specifies a number
of functional modules, based on the ‘use cases’ identified in Annex B to Part 1:
• Production Timetable (PT): this service enables the provision of information on the planned progress of
vehicles operating a specific service, identified by the vehicle time of arrival and departure at specific
stops on a planned route for a particular Operational Day.
• Estimated Timetable (ET): this service enables the provision of information on the actual progress of
Vehicle Journeys operating specific service Lines, detailing expected arrival and departure times at
specific stops on a planned route. There will be recorded data for stops which have been passed, and
predicted data for stops not yet passed. In addition the Estimated Timetable service allows Vehicle
Journeys to be cancelled, added or changed.
• Stop Timetable (ST): this service provides a stop-centric view of timetabled 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.
• Stop Monitoring (SM): this service provides a stop-centric view of vehicle arrivals and departures at a
designated stop. It can be used by displays and other presentation services to provide departure board
and other presentations of timetable and real-time journey information both at stops and at a distance.
• Vehicle Monitoring (VM): this service enables the provision of information on the current location and
status of a set of vehicles. It does not relate to specific stops. It provides all the current relevant
information from one AVMS relating to all vehicles fulfilling a set of selection criteria.
• Connection Timetable (CT): this service may be used to provide information about the scheduled arrivals
of a feeder vehicle to the operator of a connecting distributor service. The distributor operator can then
plan how to guarantee the connection, either with the expected vehicle or a different vehicle.
• Connection Monitoring (CM): this service is used to provide information about the expected arrival of a
feeder vehicle to the operator of a connecting distributor service. The distributor operator can then
manage the service to guarantee the connection, based on actual vehicle running.
• General Message (GM): the SIRI "General Message” service is used to exchange informative messages
between identified individuals in free or an arbitrary structured format. It enables messages to be sent and
to be revoked. Messages are assigned validity periods in addition to the actual content.
2 Normative references
Not applicable.
3 Terms and definitions
For the purposes of this document, the terms and definitions given in CEN/TS 15531-1:2007 apply.
4 Symbols and abbreviations
For the purposes of this document, the symbols and abbreviations given in CEN/TS 15531-1:2007 apply.
5 Production Timetable Service [PT]
5.1 Purpose
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.
The timetables exchanged should cover all lines covered by the AVMS system.
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 provision of known updates gives a more accurate data set of journeys for the SIRI Estimated Timetable
Service to reference, allowing a more efficient real-time exchange of content. However, the provision of a
Production Timetable Service is not absolutely essential for the functioning of the Estimated Timetable service.
Because of the enhanced quality of data given by an increased integration with operational and back-office
scheduling systems, SIRI implementations that are able to obtain production timetables should always provide
and make use of a SIRI Production Timetable Service.
Note that an AVMS system may be aware of additional operational journeys and calls such as dead runs, and
layovers. As the schedule information system usually only knows about vehicle journeys that are relevant to
the passenger, the AVMS should only transmit passenger carrying vehicle journeys to the schedule
information system.
5.2 Capability and Permission Matrices
5.2.1 Capability Matrix
Table 1 shows the set of required and optional capabilities is defined for the Production Timetable service.
If the service supports Capability Discovery the ProductionTimetableCapabilitiesRequest / Production-
TimetableCapabilitiesResponse message pair can be used to determine the implementation’s capabilities.
Table 1 — ProductionTimetableCapabilities Matrix
ProductionTimetableCapabilities +Structure Capabilities describing implementation of
Production Timetable service
inherit ::: 1:1 See xxx- See SIRI Part 2-12.4 for Common Capability
Capability- attributes.
Response
Topic TopicFiltering 0:1 +Structure Which optional filtering features are supported.
FilterByValidityPeriod 1:1 xsd:boolean Whether results can be filtered by Validity Period.
Required Facility: Fixed is true.
FilterByOperatorRef 1:1 xsd:boolean Whether results can be filtered by Operator.
Default is true.
FilterByLineRef 1:1 xsd:boolean Whether results can be filtered by Line. Default is
true.
FilterByVersionRef 1:1 xsd:boolean Whether results can be filtered by Timetable
Version. Default is true.
Request RequestPolicy 0:1 +Structure Which features of Request Policy are supported by
Policy the service?
Language 1:* xsd:language National languages used by service.
choice Location reference system for coordinates.
a GmlCoordinateFormat SrsNameType Default coordinate format is given by a GML value.
0:1
b WgsDecimalDegrees EmptyType Default coordinate data system is WGS 84 latitude
and longitude.
Sub- SubscriptionPolicy 0:1 +Structure Which features of Subscription Policy are
scription supported by the service?
Policy
HasIncremental- 0:1 xsd:boolean Whether incremental updates can be specified for
Updates updates. Default is true.
Access AccessControl 0:1 +Structure Which optional Access Control features are
Control supported by service?
RequestChecking 0:1 xsd:boolean Whether access control of requests is supported.
Default is false.
CheckOperatorRef 0:1 xsd:boolean If access control is supported, whether access
control by Operator is supported. Default is true.
CheckLineRef 0:1 xsd:boolean If access control is supported, whether access
control by Line is supported. Default is true.
CheckConnection- 0:1 xsd:boolean If access control is supported, whether access
Link_Ref control by ConnectionLink is supported. Default is
true.
any Extensions 0:1 any Placeholder for user extensions.

5.2.2 Permission Matrix
If the implementation supports both Capability Discovery and Access Controls, then the
ProductionTimetableCapabilitiesResponse response can include the access permissions for the requestor
participant to access data. Table 2 shows this.
Table 2 — Production Timetable Service Permissions
ProductionTimetablePermission +Structure Permissions to use implementation of Production
Timetable service.
In- ::: 1:1 xxxService- See SIRI Part 2-12.5 for Common Permission
herit Permissions elements.
Topic OperatorPermissions 0:1 +Structure Operator permissions for participant. See Part 2.
Line
...