SIST EN 15531-1:2022

SLOVENSKI STANDARD
01-november-2022
Nadomešča:
SIST EN 15531-1:2015
Javni prevoz - Vmesnik za informiranje v realnem času za potrebe delovanja
javnega prevoza - 1. del: Skladnost in okvir
Public transport - Service interface for real-time information relating to public transport
operations - Part 1: Context and framework
Öffentlicher Verkehr - Serviceschnittstelle für Echtzeitinformationen bezogen auf
Operationen im öffentlichen Verkehr - Teil 1: Kontext und Grundstruktur
Transport public - Interface de service pour les informations en temps réel relatives aux
opérations de transport public - Partie 1 : Cadre et contexte
Ta slovenski standard je istoveten z: EN 15531-1:2022
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 15531-1
EUROPEAN STANDARD
NORME EUROPÉENNE
August 2022
EUROPÄISCHE NORM
ICS 35.240.60 Supersedes EN 15531-1:2015
English Version
Public transport - Service interface for real-time
information relating to public transport operations - Part
1: Context and framework
Transport public - Interface de service pour les Öffentlicher Verkehr - Serviceschnittstelle für
informations en temps réel relatives aux opérations de Echtzeitinformationen bezogen auf Operationen im
transport public - Partie 1 : Cadre et contexte öffentlichen Verkehr - Teil 1: Kontext und
Grundstruktur
This European Standard was approved by CEN on 13 June 2022.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2022 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 15531-1:2022 E
worldwide for CEN national Members.

Contents Page
European Foreword…………………………………………………………………………………………………………………….4
Introduction……………………………………………………………………………………………………………………………….5
1 80BScope . 8
1.1 Interfaces specified by this document . 8
1.2 Use of the SIRI standard . 10
1.3 Limitations on SIRI and Possible Future Developments . 11
2 81BNormative references . 12
3 82BTerms and definitions . 12
3.1 Transport Related Terms . 12
3.2 Communications and Software Concepts . 34
4 83BSymbols and abbreviations . 46
5 84BTypes of Reference Data Used in SIRI . 47
5.1 General . 47
5.2 Date and time format . 49
5.3 Location coordinate system . 49
5.4 National language of text elements . 50
5.5 Participant (information provider) identification. 50
5.6 Participant pair identification (service participant pair code) . 51
5.7 Point and place references . 51
5.8 Vehicle journey references . 53
5.9 Line, and direction references . 54
5.10 Stop sequence references and circular journeys . 55
5.11 Schedule version references . 57
5.12 Product category references . 57
5.13 Vehicle feature references . 58
5.14 Service features . 58
5.15 Situation references . 60
5.16 Summary of Data Reference Scopes . 61
5.17 Transmodel Compliant Models . 62
5.18 Modelling Vehicle Journeys in SIRI . 62
6 85BNotation . 70
6.1 Representation of XML model elements in Text . 70
6.2 Representing Relationships in SIRI . 70
6.3 Notation for XML model structures of SIRI messages . 71
6.4 Notation for Diagrams . 73
Annex A 77B(informative) Checklist for Implementing SIRI . 74
A.1 Usage of the DSRC application layer . 74
A.2 Legal and Commercial Issues . 74
A.3 Functional Aspects . 74
A.4 Operational Aspects . 77
Annex B 78B(informative) Business Context . 78
B.1 Purpose of This Section . 78
B.2 Business Model . 79
B.3 Use of information in Public Transport . 82
B.4 Use Cases for this Standard . 87
B.5 SIRI System Model . 92
Annex C 79B(informative) Background and Mapping of Some Current Implementations to SIRI . 96
C.1 Introduction . 96
C.2 SIRI origins . 96
C.3 Deployment Example – Berlin . 99
C.4 Deployment Example – Hamburg. 99
C.5 Deployment Example – West Yorkshire . 100
C.6 Deployment Example – Czech Republic . 101
C.7 Deployment Example – Copenhagen . 102
C.8 Deployment example – Île-de-France . 103
C.9 SIRI Equivalences . 105

European foreword
This document (EN 15531-1:2022) has been prepared by Technical Committee CEN/TC 278 “Intelligent
transport systems”, the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an identical
text or by endorsement, at the latest by February 2023, and conflicting national standards shall be withdrawn
at the latest by February 2023.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 15531-1:2015.
SIRI (CEN/TS 15531-1:2006) has been a CEN Technical Specification since 2007 and a European normative
standard since 2013 and has been widely used in Europe and elsewhere and proven its usefulness. This
document proposes a revised version of SIRI as a European Standard, and is currently submitted to the
Formal Vote. The proposed revisions are minor enhancements arising from experience of the deployment of
SIRI in many live systems. This document also clarifies the relationship of SIRI to NeTEx, the CEN Technical
Standard for the XML exchange of Public Transport Reference data based on the Transmodel CEN European
Standard.
This document presents Part 1 of the European Standard 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.
The SIRI European Standard 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 PT, ET, ST, SM, VM, CT, CM, GM
(Part 3).
Two additional parts define additional functional services as CEN Technical Specifications:
• additional data structures for additional application interface module FM (Part 4),
• additional data structures for additional application interface module SX (Part 5).
The XML schema can be downloaded from https://github.com/SIRI-CEN/SIRI, guidance on its use, example
XML files, and case studies of national and local deployments is located at http://siri-cen.eu/.
It is recognised that SIRI is not complete as it stands, and from time to time will need to continue to be
enhanced to add additional capabilities. It is therefore intended that a SIRI Management Group should
continue to exist, at European level, based on the composition of SG7.
Any feedback and questions on this document should be directed to the users’ national standards body. A
complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the following
countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech
Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia,
Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia,
Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the 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 services running, and so on.
This document 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 document will improve a number of features of public transport information and service management:
• Interoperability – the European Standard 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; (iii) 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 European Standard 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 European Standard will assist the economic provision
of improved data by; (i) enabling the gathering and exchange of real-time data between AVMS systems;
(ii) providing standardised, well defined interfaces that can be used to deliver data to a wide variety of
distribution channels. Version 2.0 of SIRI includes a new Simple Web Service designed to support the
widespread, massively scalable use of mobile devices and web browsers and other applications to display
public transport data directly to users.
Technical advantages include the following:
• Reusing a common communication layer for all the various technical services enables cost-effective
implementations and makes the European Standard readily extensible in future.
History
Version 1.0 of SIRI was developed in 2004-2005 and submitted to vote, eventually passing through the CEN
process to become an approved CEN Technical Specification in 2007. As well as the normative Version 1.0
XSD schema, successive informal working versions of the schema (v 1.1 – 1.4) were released to allow for fixes
and to implement some very minor enhancements agreed by the working group. A WSDL version was also
developed.
Version 2.0 of SIRI was developed in 2012 to coincide with making the SIRI standard a full CEN norm.
SIRI includes a Simple Web Services “SIRI-LITE” as an additional transport method and a WSDL document
literal version and a WSDL2 version;
Version 2.1 of SIRI was developed in 2020/21 to address lessons from the now widespread implementation of
SIRI.
The changes in SIRI version 2.1 include:
• remove the direct relationship with TPEG and other standards to enable support as the other standards
change;
• support for new modes in line with TRANSMODEL and NeTEx;
• support for the Reason / Effect / Advice structure for disruptions in SIRI SX;
• increased granularity for occupancy data and Vehicle structures;
• improved subscription renewal options and filtering options;
• additional options and flexibility for STOP POINTS and relationships between journeys;
• migration of XSD to Github to improve access and change control processes.
Compatibility with previous versions
All changes in version 2.1 are intended to be fully backwards compatible, that is to say, existing documents
that validate against earlier versions of the schema will also validate against the 2.1 schema without
alteration (other than to schema version numbers), and version 2.1 documents that do not use new features
will validate against earlier versions. Version 2.1 documents that use new features will not be backwards
compatible.
Elements new to SIRI are annotated thus on first citation: (+2.1).
1 80BScope
1.1 Interfaces specified by this document
1.1.1 Business Context
Real-time information may be exchanged between a number of different organisations, or between different
systems belonging to the same organisation. Key interfaces include the following:
• Between public transport vehicle control centres – generally, for fleet and network management.
• Between a control centre and an information provision system – generally, to provide operational
information for presentation to the public.
• Between information provision systems – generally, sharing information to ensure that publicly available
information is complete and comprehensive.
• Between information provision systems – and data aggregation systems that collect and integrate data
from many different sources and different types of data supplier and then distribute it onwards.
• Between information provision systems and passenger information devices such as mobile phones, web
browsers, etc.
Annex B describes the business context for SIRI in more detail.
SIRI is intended for wide scale, distributed deployment by a wide variety of installations. In such
circumstances it is often not practical to upgrade all the systems at the same time. SIRI therefore includes a
formal versioning system that allows for the concurrent operation of different levels at the same time and a
disciplined upgrade process.
In this general framework, SIRI defines a specific set of concrete functional services. The services separate the
communication protocols from the message content (‘functional services’). This allows the same functional
content to be exchanged using different transport mechanisms, and different patterns of exchange. Figure 1
below shows this diagrammatically.
1.1.2 SIRI Communications
SIRI provides a coherent set of functional services for exchanging data for different aspects of PT operation. A
common data model, based on Transmodel 6.0, is used across all services.
Figure 1 — Structure of SIRI: a set of optional service interface specifications using a common
communication layer
A communication layer defines common procedures for the requesting and exchanging of data. Within SIRI,
the same general communication protocols are used for all the different concrete functional interfaces, and
specify a common infrastructure for message referencing, error handling, reset behaviour and so forth. The
communications layer is defined in Part 2 of the SIRI document set.
To allow the most efficient use to be made of bandwidth and processing capacity, the SIRI communications
architecture supports several different patterns of interaction. SIRI supports both request/response and
publish/subscribe protocols between servers, allowing applications both to pull or to push data.
The SIRI publish/subscribe pattern of interaction follows the paradigm described in the W3C candidate
standard ‘Publish-Subscribe Notification for Web Services (WS-PubSub)’. SIRI uses the same separation of
concerns, and a similar terminology for Publish/Subscribe concepts as is used in WS-PubSub.
For the delivery of data in response to both requests and subscriptions, SIRI supports two common patterns
of message exchange as realised in existent national systems:
• one-step ‘direct’ delivery: allowing the simple rapid delivery of data;
• two-step ‘fetched’ delivery: allowing a more optimised use of limited resources.
1.1.3 SIRI Functional Services
SIRI provides specific protocols for the following functional services, defined in Part 3 of the SIRI document
set:
• Production Timetable (PT) Service: to send daily information on the operational timetable and
associated vehicle running information.
• Estimated Timetable (ET) Service: to send real-time information on timetable, including changes based
on the production service and on actual running conditions.
• Stop Timetable (ST) Service: to provide a stop-centric view of timetabled vehicle arrivals and departures
at a designated stop.
• Stop Monitoring (SM) Service: to send real-time arrival & departure information relating to a specific
stop.
• Vehicle Monitoring (VM) Service: to send real-time information on the movement and predicted
movement of vehicles.
• Connection Timetable (CT) Service: to send an operational timetable for a service feeding an
interchange, in order to inform departing services of the possible need to wait for connecting passengers.
• Connection Monitoring (CM) Service: to send real-time information on the running of a service inbound
to an interchange, in order to advise departing services of the need to wait for connecting passengers.
This can also be used to send real-time information to assist passengers in planning their onward journey
following a connection.
• General Message (GM) Service: to exchange informative messages between participants.
Two additional functional services, are provided as additional parts:
• Facilities Management (FM) Service: to exchange information on the current status of facilities such as
lifts, escalators or ticketing machines (Part 4).
• Situation Exchange (SX) Service: to exchange information messages between identified participants in a
standardised structured format suitable for travel information services (Part 5).
1.2 Use of the SIRI standard
As a framework standard, it is not necessary for individual systems or specifications to implement the whole
of the SIRI standard. Specifically, it is intended that individual national bodies may adopt consistent subsets of
the standard. However, it should be possible to describe (for those elements of systems, interfaces and
specifications which fall within the scope of SIRI):
• the aspects of SIRI that they have adopted;
• the aspects of SIRI that they have chosen not to adopt.
In other words, there is no global statement of which elements are mandatory and which optional (except for
key fields which are clearly always mandatory).
SIRI is a modular and expandable standard, and the modules included in this version are only a subset of what
might potentially be included. Specifically, the current issue of the SIRI specification excludes the following:
• interfaces with traffic management systems for traffic light priority;
• control action functions, e.g. instructions to a vehicle to change its running;
• functionality of actual systems – SIRI only specifies the interfaces between servers, not how they choose
to implement it.
Since its inception SIRI has been enhanced and extended to meet additional requirements. The potential for
SIRI to be expanded to encompass additional services will continue to be reviewed in future.
Guidance on the implementation and use of SIRI is not part of the specification. It is a matter for individual
users and national groupings to provide advice and guidance on how SIRI may be used in support of local
practices.
Note also that the SIRI communications layer does not specify the communication bearer technologies to be
used. SIRI has been specifically developed to be ‘technology independent’ in this regard, so that local
implementations can select the most cost-effective services for their projects.
Of course different technologies have different characteristics, and this may have an impact on the way that
SIRI is used in practice. For example, the latency (time delay imposed by the communications network) of a
service such as public GPRS is much higher than that on a dedicated, broadband fixed link using DSL.
Therefore, systems based on GPRS will need to use a much higher value for some or all of the hysteresis
parameters.
1.3 Limitations on SIRI and Possible Future Developments
The developers of this standard recognise that there is continual development in the business practice of the
public transport industry, and that SIRI must continue to evolve to fulfil its needs. Specifically, there is scope
for additional elements to be included in two places:
• Communications (SIRI Part 2). New mechanisms of data communication are constantly becoming
available, in particular for areas such as information security and data discovery. SIRI is intended to be in
line with prevailing information systems industry practice and Part 2 aims to retain flexibility in use of
communications technologies. SIRI 2.0 introduces addition transports in form of the Document Literal
WSDL and a RESTful presentation of services.
• Applications (SIRI Part 3, Part 4, Part 5, etc). This standard is based on a specific set of interfaces,
representing a subset of practical needs among participant countries. However, new models of business
cooperation may arise which necessitate additional application interface specifications. The current
functional services are not intended to be a complete set of interfaces and additional modules might be
required in future.
• Architectural detail. This standard is based on a very high-level decomposition of public transport
operations, and implements only the most common interfaces. This may not fulfil all the needs of an
implementer; for example, Scandinavia and the UK both have a relatively high degree of organisational
disaggregation, and as a result may need standardisation on what would be ‘internal’ interfaces elsewhere
in Europe.
CEN welcomes input from users of this Standard as to where SIRI needs extension or refinement.
2 81BNormative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 8601, Data elements and interchange formats – Information interchange – Representation of dates and
times
ISO 639-1, Codes for the representation of names of languages - Part 1: Alpha-2 code
3 82BTerms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1 Transport Related Terms
NOTE 1 This section includes terms for both PT entities and properties of PT entities used in SIRI. For each term, it is
indicated whether the term derives from Transmodel (EN 12896 version 6.0) or whether the term is specific to SIRI.
NOTE 2 Data elements taken from Transmodel are written in capital letters in the text parts of this document (as it is in
EN 12896 ex PARKING POINT) to distinguish between terms and Transmodel data elements. Data elements defined in
SIRI are written with capital first letters of the nouns (ex: Subscription Identifier).
3.1.1
access space (Transmodel)
passenger area within a STOP PLACE such as a concourse or booking hall, immigration hall or security area
that is accessible by pedestrians, but without a direct access to vehicles
Note 1 to entry: Direct access to a VEHICLE is always from a QUAY and/or BOARDING POSITION. An ACCESS SPACE
may be a Room, Hall, Concourse, Corridor, or bounded open space within a STOP PLACE.
3.1.2
accessibility (SIRI)
possibility of a user with a specific USER NEED, such as a disability or encumbrance, to access either fixed or
moving Public Transport facilities
3.1.3
accessibility assessment (Transmodel)
Accessibility characteristics of an entity used by PASSENGERs such as a STOP PLACE, or a STOP PLACE
COMPONENT
Note 1 to entry: Described by ACCESSIBILITY LIMITATIONs, and/or a set of SUITABILITies.
3.1.4
accessibility limitation (Transmodel)
categories of the mobility characteristics of a STOP PLACE COMPONENT such as a STOP PATH LINK or
ACCESS SPACE to indicate its ACCESSIBILITY by mobility constrained users, for example those needing
wheelchair access, step-free access or wanting to avoid confined spaces such as lifts
Note 1 to entry: A small number of well-defined categories are used that are chosen to allow the consistent capture of
data and the efficient computation of ROUTEs for different classes of user.
3.1.5
affects scope (SIRI-SX)
scope of a SITUATION ELEMENT or consequence of a SITUATION ELEMENT in terms of the specific entities
such as OPERATORs, NETWORKs, LINEs, SCHEDULED STOP POINTs, STOP PLACEs, PLACEs, etc that are
affected
3.1.6
base Situation Element (SIRI-SX)
original record of a particular SITUATION
Note 1 to entry: This may subsequently be followed by UPDATE SITUATION ELEMENTs that record further changes.
3.1.7
bearing
heading of the vehicle in degrees expressed as a floating point number
Note 1 to entry: SIRI diverges from the Transmodel definition which specified BEARING as an integer. The SIRI
definition predates the Transmodel definition.
3.1.8
block (Transmodel)
work of a vehicle from the time it leaves a PARKING POINT after parking until its next return to park at a
PARKING POINT
Note 1 to entry: Any subsequent departure from a PARKING POINT after parking marks the start of a new BLOCK. The
period of a BLOCK has to be covered by DUTIES.
3.1.9
boarding Position (Transmodel)
location within a QUAY from which passengers may directly board, or onto which passengers may directly
alight from a PT vehicle
3.1.10
branding (SIRI (+2.1))
arbitrary marketing classification
3.1.11
call (Transmodel)
visit by a Vehicle to a specific Scheduled Stop Point as it follows the Journey Pattern of its Vehicle Journey to
achieve a set of planned and estimated Passing Times
Note 1 to entry: A Vehicle may make more than one Call to the same stop in the course of a Journey: different Calls
may typically be distinguished by a Visit Number count. The Call may have real time data associated with it.
Note 2 to entry: A SIRI Call may be regarded as a useful optimisation of a more normalised set of structures that are
articulated separately in Transmodel. Call combines the Transmodel elements of Point In Journey Pattern in with
Estimated Passing Time, Observed Passing Time, & Target Passing Time, along with real time elements and other stop
properties pertaining to the visit. Note that SIRI segregates all elements pertaining to arrival from those pertaining to
departure, again facilitating the validation and implementation of actual systems.
3.1.12
call activity (SIRI)
activity a passenger may undertake when a VEHICLE calls at a stop; Boarding, Alighting, or Pass Through
3.1.13
change of journey pattern (Transmodel)
CONTROL ACTION consisting in assigning a new JOURNEY PATTERN (and the ROUTE supporting it) to a
DATED VEHICLE JOURNEY.
3.1.14
cleardown (SIRI)
act of removing a Stop Visit from a LOGICAL DISPLAY once a vehicle has left a stop.
Note 1 to entry: For improved latency, ‘Direct Cleardown’ may often be done by direct wireless communication
between the approaching vehicle and the stop display equipment, as well as by the regular back-end communication
between the Stop Monitoring producer server and the Stop Monitoring Consumer entity of the client system driving the
stop display.
Note 2 to entry: A separate Cleardown identifier may be associated with each Stop Visit for this purpose, which can be
used to reconcile the previous Stop Visit with the arriving vehicle; typically this will be a short numeric code designed to
be efficient for communication over a radio channel of restricted capacity.
3.1.15
compound Train (Transmodel (+2.1))
VEHICLE TYPE composed of a sequence of more than one vehicles of the type TRAIN
3.1.16
connection (Transmodel / NeTEx)
physical (spatial) possibility for a passenger to change from one public transport vehicle to another to
continue a trip
Note 1 to entry: Different transfer times may be necessary to cover interchange over a given CONNECTION link,
depending on the kind of passenger. In SIRI, a Feeder service may arrive at one SCHEDULED STOP POINT in the
CONNECTION link, and the Distributor may leave from the same or a different stop in the CONNECTION link. The
interchange duration, i.e. transfer time is the time needed to go from SCHEDULED STOP POINT to SCHEDULED STOP
POINT across a CONNECTION link. In SIRI, it does not include time needed to board or alight. Several different types of
interchange duration may be specified.
Note 2 to entry: CONNECTION link has been renamed CONNECTION in NeTEx.
3.1.17
connection activity (SIRI)
change to the planned arrival to, or departure from, a CONNECTION link for a VEHICLE JOURNEY that is
material to passengers intending to make a planned interchange
Note 1 to entry Events may include a delayed arrival of the FEEDER, a decision to prolong the wait by the
DISTRIBUTOR vehicle, a change of the distributor departure point, or cancellation of either of the feeder or distributor
journeys.
3.1.18
Connection Link (Transmodel)
physical (spatial) possibility for a passenger to change from one public transport vehicle to another to
continue a trip
Note 1 to entry: Different transfer times may be necessary to cover interchange over a given connection link,
depending on the kind of passenger.
Note 2 to entry: In NeTEx the name is revised to be CONNECTION.
3.1.19
connection monitoring service (SIRI)
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.
3.1.20
connection protection (SIRI)
coordination of inbound FEEDER and outbound DISTRIBUTOR journeys at an interchange so as to maximise
the chances of passengers achieving their journeys.
Note 1 to entry: Involves the exchange of information between feeder and distributor to inform dispatchers and
passengers of the current situation, and the delaying of distributor vehicles so as to honour guaranteed connections.
3.1.21
connection timetable data service (SIRI)
used for the exchange of schedule data for potential FEEDER VEHICLE JOURNEYs to a connection zone. It is
used in conjunction with the SIRI Connection Monitoring Service.
3.1.22
consequence (SIRI (originally Trident))
outcome of a SITUATION
3.1.23
control action (Transmodel)
action resulting from a decision taken by the controller causing an amendment of the operation planned in
the PRODUCTION PLAN
Note 1 to entry: For SIRI-SX, CONTROL ACTIONs may often give rise to a SITUATION, but are entirely distinct
concepts.
3.1.24
control centre (SIRI / NeTEx)
CONTROL CENTRE is an ORGANISATIONAL UNIT that manages a network or networks of vehicles and their
attendant real-time systems
Note 1 to entry: In practice there is often a one-to-one correspondence between a control centre and a SIRI Service
Participant. Each CONTROL CENTRE has a unique identifier, (the Control Centre Code), which provides a scope (i.e.
unique namespace) for all non-global data references, such as stop identifiers, vehicle identifiers, etc. Within a Control
centre, references must be unique. VEHICLES and JOURNEYS within the span of control of a given Control Centre are
Local; VEHICLES and JOURNEYS within the span of control of an external Control Centre are Foreign.
3.1.25
coupled journey (Transmodel)
complete journey operated by a coupled train, composed of two or more VEHICLE JOURNEYs remaining
coupled together all along a JOURNEY PATTERN. A COUPLED JOURNEY may be viewed as a single VEHICLE
JOURNEY
3.1.26
course of journey(Transmodel)
part of a BLOCK, composed of consecutive VEHICLE JOURNEYs defined for the same DAY TYPE, all operated
on the same LINE
Note 1 to entry: Also sometimes termed a run.
3.1.27
data source (Transmodel)
origin of operational data referring to one single responsibility.
Note 1 to entry: References to a DATA SOURCE are useful in an interoperated computer system.
Note 2 to entry: For SIRI, this entails in particular a specific systems for assigning unique identifiers to relevant
entities such as SCHEDULED STOP POINTS or JOURNEYS, about which messages are to be exchanged, and which can be
matched to the locally known entities identified by the respective internal operating data. The DATA SOURCE must be
mutually agreed between Client and Server. A DATA SOURCE has both a data model to describe the entities and their
relationships, and a Namespace to describe the unambiguous set of identifier values.
3.1.28
dated vehicle journey (Transmodel)
particular journey of a vehicle on a particular OPERATING DAY, including all modifications decided by the
control staff.
3.1.29
delayed (SIRI)
categorisation of a VEHICLE JOURNEY for presentation as being late and subject to significant uncertainty
caused either by a Disturbance to the transport network or a problem with the VEHICLE itself
3.1.30
delivery variant (NeTEx)
variant text of a NOTICE for use in a specific media or delivery channel (voice, printed material, etc).
3.1.31
destination display (Transmodel (with clarification))
advertised destination of a specific JOURNEY PATTERN, usually displayed on a headsign or at other on-board
locations
Note 1 to entry: In SIRI, different values for DESTINATION DISPLAY may be used in the dated timetable, the real-time
timetable, or on individual calls to support stop centric and vehicle centric presentations of information to the customer.
If not specified on an individual CALL element, the DESTINATION DISPLAY will be inherited from the most recent
previous CALL element. If there are no values on previous calls, it will be inherited from the DATED VEHICLE JOURNEY
destination displays.
3.1.32
direction (Transmodel)
classification for the general orientation of ROUTEs
Note 1 to entry: In TRANSMODEL the DIRECTION may be an important aspect of a PATH LINK that may only be
traversed one way.
3.1.33
display assignment (NeTEx)
assignment of one SCHEDULED STOP POINT and one JOURNEY PATTERN to a PASSENGER INFORMATION
FACILITY, specifying that information on this SCHEDULED STOP POINT and this JOURNEY PATTERN will be
provided (e.g. displayed, printed)
Note 1 to entry: Equivalent to a SIRI MONITORING POINT
3.1.34
distributor (SIRI / NeTEx)
role of the outgoing VEHICLE from a SERVICE JOURNEY INTERCHANGE, which picks up passengers from a
CONNECTION link who have transferred from a Feeder Service
Note 1 to entry: Sometimes also called a “Fetcher”.
3.1.35
distributor departure (SIRI)
departure of an outgoing distributor VEHICLE JOURNEY from a CONNECTION link.
3.1.36
early (SIRI / NeTEx)
categorisation used in data presentations to indicate that the vehicle has been classified as early against some
criteria
Note 1 to entry: The status of “Early” will be derived from the real-time progress data. This term should be contrasted
with Schedule Deviation which specifies the deviation from schedule in seconds.
3.1.37
easement (SIRI)
temporary permission to use a ticket purchased for use of a transport service on a different travel product
because the original service has been disrupted.
Note 1 to entry: For example: To use a bus instead of the metro.
3.1.38
estimated passing time (Transmodel)
time data, calculated from the latest available input, about when a public transport vehicle will pass a
particular POINT IN JOURNEY
...