CEN/TS 15531-5:2016

SLOVENSKI STANDARD
01-september-2016
1DGRPHãþD
SIST-TS CEN/TS 15531-5:2011
-DYQLSUHYR]9PHVQLN]DVWRULWHYLQIRUPLUDQMDYUHDOQHPþDVX]DSRWUHEH
GHORYDQMDMDYQHJDSUHYR]DGHO9PHVQLNLIXQNFLMVNHVWRULWYHL]PHQMDYH
SRGDWNRY,]PHQMDYDSRGDWNRYRVLWXDFLML
3XEOLFWUDQVSRUW"6HUYLFHLQWHUIDFHIRUUHDO"WLPHLQIRUPDWLRQUHODWLQJWRSXEOLFWUDQVSRUW
RSHUDWLRQV"3DUW)XQFWLRQDOVHUYLFHLQWHUIDFHVVLWXDWLRQH[FKDQJH6LWXDWLRQ
([FKDQJH
Öffentlicher Verkehr - Diensteschnittstelle für den Echtzeitaustausch von
Betriebsinformationen des ÖPNV (SIRI) - Teil 5: Funktionelle Serviceschnittstelle:
Situativer Austausch
Transport public - Interface de service pour les informations en temps réel relatives aux
opérations de transport public - Partie 5 : Service d'interface fonctionnelle - Échange de
l'état de l'exploitation et de son contexte
Ta slovenski standard je istoveten z: CEN/TS 15531-5:2016
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.

CEN/TS 15531-5
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
May 2016
TECHNISCHE SPEZIFIKATION
ICS 35.240.60 Supersedes CEN/TS 15531-5:2011
English Version
Public transport - Service interface for real-time
information relating to public transport operations - Part
5: Functional service interfaces situation exchange:
Situation Exchange
Transport public - Interface de service pour les Öffentlicher Verkehr - Diensteschnittstelle für den
informations en temps réel relatives aux opérations de Echtzeitaustausch von Betriebsinformationen des
transport public - Partie 5: Service d'interface ÖPNV (SIRI) - Teil 5: Funktionelle Serviceschnittstelle:
fonctionnelle - Échange de l'état de l'exploitation et de Situativer Austausch
son contexte
This Technical Specification (CEN/TS) was approved by CEN on 25 February 2016 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, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, 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: Avenue Marnix 17, B-1000 Brussels
© 2016 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15531-5:2016 E
worldwide for CEN national Members.

Contents Page
European foreword . 6
Introduction . 8
1 Scope . 10
2 Normative references . 11
3 Terms and definitions . 11
4 Symbols and abbreviations . 16
5 Situations as Software Entities . 16
5.1 General . 16
5.2 Structured Situations . 17
5.3 Distributed Situation processing . 18
5.3.1 Identity and Write-Only Updates. 18
5.3.2 Currency and the Situation Life Cycle . 19
5.3.3 Representational model for Situation Elements . 20
5.3.4 Update chains − Causal chains . 21
5.3.5 Cross-referencing Situations − Causal chains . 22
5.3.6 Branching and distributed updates . 22
5.3.7 Archiving . 24
5.4 Summary of Situation Management . 24
5.4.1 General . 24
5.4.2 Situation Identity. 24
5.4.3 Situation Life Cycle . 25
5.4.4 Situation Update Content . 25
5.4.5 Example of identifier allocation . 26
5.4.6 Date time stamps as identifiers. 26
5.5 Interoperability of Situation management systems . 26
5.5.1 General . 26
5.5.2 Datex2 Interoperability . 27
5.5.3 TPEG Interoperability . 28
5.5.4 Communications Bandwidth . 28
6 The Situation Model . 28
6.1 General . 28
6.2 Representing a PT Situation in SIRI-SX . 29
6.2.1 Summary of PT Situation model . 29
6.2.2 PT Situation Element Body . 30
6.2.3 PT Situation Body Details . 31
6.2.4 PT Situation Reason . 33
6.2.5 Situation Consequence . 36
6.2.6 The PT AffectsScope . 37
6.3 Representing a Road Situation in SIRI-SX . 43
6.3.1 Summary of Road Situation model . 43
6.3.2 Road Situation Element Body . 45
6.3.3 Common Accessibility . 45
6.3.4 Publishing Actions . 46
6.3.5 Common Types . 47
7 Situation Exchange Service [SX] . 54
7.1 Purpose. 54
7.2 Description . 54
7.3 Reference Data . 54
7.4 Capability and Permission Matrices . 54
7.4.1 Capability Matrix . 54
7.4.2 Permission Matrix . 56
7.5 UML Diagrammatic Representation . 56
7.5.1 General . 56
7.5.2 UML Detailed Diagram of SituationExchangeRequest . 57
7.5.3 UML Diagram of SituationExchangeDelivery - Summary . 59
7.5.4 UML Diagram of SituationExchangeDelivery - Detail . 60
7.5.5 UML Diagram of SituationContext . 60
7.6 SituationExchangeRequest . 61
7.6.1 SituationExchangeRequest Definition . 61
7.6.2 SituationStatusFilter Definition . 63
7.6.3 SituationNetworkFilter Definition . 64
7.6.4 SituationStopPlaceFilter Definition . 64
7.6.5 SituationJourneyFilter Definition . 65
7.6.6 SituationPlaceFilter Definition . 65
7.6.7 SituationRoadFilter Definition . 65
7.6.8 AccessibilityNeedFilter Definition. 66
7.6.9 SituationExchangeRequest Example . 66
7.7 SituationExchangeSubscriptionRequest . 66
7.7.1 SituationExchangeSubscriptionRequest Definition . 66
7.7.2 SituationExchangeSubscriptionRequest Example . 67
7.8 SituationExchangeDelivery . 67
7.8.1 ServiceDelivery with a SituationExchangeDelivery . 68
7.8.2 SituationExchangeDelivery Element . 68
7.8.3 SituationContext Element . 68
7.8.4 SituationNetworkContext Element. 69
7.8.5 PtSituationElement . 69
7.8.6 RoadSituationElement . 128
8 SituationExchangeDelivery Examples - SituationExchangeDelivery PT Examples . 130
A.1 General . 133
A.2 Classes . 133
A.3 Enumerations . 133
A.4 Groups . 133
A.5 Notes . 133
A.6 Relationships . 133
A.7 Use of Colour . 134
A.8 Serialisation: Containment and Reference . 134
A.9 Alternative Representations of XML Structures in UML . 135
A.10 XML Fragment for Example . 137
A.11 Order of Attributes . 138
A.12 Direction of Reading . 138
A.13 Simple Data Types . 138
A.14 Reusable Complex Data Types . 138
B.1 SIRI-SX and Datex2 . 139
C.1 General . 142
C.2 Use Cases: Capture and Origination of Situations . 142
C.3 CAPT#01 Situations entered manually by operator staff . 142
C.4 CAPT#02 Situations updated manually by operator staff . 142
C.5 CAPT#03 Situations being generated automatically from a situation analyser . 143
C.6 CAPT#04 Situations arising from Facility Monitoring (e.g. lift failure). 143
C.7 CAPT#05 Situations arising from Control Actions (e.g. short running, platform
change) . 143
C.8 CAPT#06 Situations supplied automatically from a related PT network (e.g. rail
incidents being fed to bus system) in both SIRI and TPEG formats . 143
C.9 CAPT#07 Situations supplied automatically from a related Road network (e.g. road
situations being fed to bus system) Datex2 formats . 143
C.10 CAPT#08 Road work affecting bus lanes . 143
C.11 CAPT#09 Parking not available at an interchange to PT . 143
C.12 CAPT#10 Weather or non-network specific Situation or event . 144
C.13 CAPT#11 Cross referencing Situations with previous Situations . 144
C.14 CAPT#12 Workflow for verification, validation and editorial correction . 144
C.15 CAPT#13 Providing of collective guidance of passengers . 144
C.16 CAPT#14 Audit trails, retrospectives and process views . 144
C.17 Use Cases: Relating Situations to other SIRI services . 144
C.18 XREF#01 Problem affecting a specific vehicle journey . 145
C.19 XREF#02 Problem at a stop place affecting some or all journeys for some or all
modes . 145
C.20 XREF#03 Problem affecting a whole line or a section of a line between two stop
places . 145
C.21 XREF#04 Problems affecting an interchange . 145
C.22 XREF#05 Problem affecting a whole network . 145
C.23 XREF#06 Disruption (e.g. partial blockage) or degradation (e.g. crowding) of normal
travel . 146
C.24 XREF#07 Problems affecting particular classes of users e.g. impaired mobility . 146
C.25 Use Cases: Onwards Distribution to other systems (e.g. in TPEG and Datex2) . 146
C.26 DIST#01 Distribution of Situations to displays . 146
C.27 DIST#02 Distribution of Situations to external information services, e.g.
broadcasters . 146
C.28 DIST#03 Distribution of Situations to staff . 146
C.29 DIST#04 Distribution of Situations to alerts and travel angels . 147
C.30 DIST#05 Projection of Situations on maps . 147
C.31 DIST#06 Distribution of Situations to journey planners . 147
C.32 DIST#07 Distribution of Situations to personal navigators and smart devices . 147
C.33 DIST#08 Distribution of Situations to other incident management systems . 147
C.34 DIST#09 Distribution of updates to existing Situations . 147
C.35 DIST#10 Aging of Situations and updates . 148
D.1 Mapping of SIRI-SX elements to GTFS-realtime . 149
D.2 Mapping of SIRI-SX Journey Condition to GTFS-realtime ScheduleRelationship . 150
D.3 Mapping of SIRI-SX Situation Categories to GTFS-realtime Cause . 150
D.4 Mapping of SIRI-SX Service Conditions to GTFS Real-time Effect . 151
Bibliography . 152

European foreword
This document (CEN/TS 15531-5:2016) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent
rights.
This document supersedes CEN/TS 15531-5:2011.
The 15531 series consists of the following parts, under the general title Public transport - Service
interface for real-time information relating to public transport operations
— Part 1: Context and framework
— Part 2: Communications
— Part 3: Functional service interfaces
— Part 4: Functional service interfaces: Facility Monitoring
— Part 5: Functional service interfaces - Situation exchange
The following corrections and modifications have been in this new version of CEN/TS 15531-5:
— Correct spec to include projection attributes for affectedStopPlaceComponent
— Document FacilityRef as part of request
— Document Access Mode as part of request
— Document Scope as part of request
— Document RoadFilter and Accessibility need filter as part of request
— Correct Documentation of AffectedRoads as part of Delivery
— Correct Documentation of capability Matrix
— Correct Documentation of Reason codes
— Added Annex D to Doc on GTFS real-time mapping
— StopMonitoringDelivery upgrade to DatexII
All changes are available in the file ReadMe.txt which is accompanying the XSD-schema, available from
http://www.siri.org.uk.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, 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.
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, connecting diverse systems; 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, with a well-
defined, version interface, individual functional modules can be replaced or evolved, without
unexpected breakages of obscurely dependent function.
The SIRI framework is a European Technical Specification that provides a specification for a number of
functional interfaces that allow public transport data of specific types to be exchanged readily using
structured interfaces.
This further Technical Specification specifies an additional SIRI functional service to exchange incident
and event information about disruptions to public transport between servers containing real-time
public transport vehicle or journey time data. These include the control centres of transport operators
as well as information systems that deliver passenger travel information services.
This document describes the SIRI Situation Exchange service, one of a modular set of services for the
exchange of Real-time information. The Situation Exchange service (SIRI-SX) is concerned with the
exchange of planned events and unplanned incident data among systems, including incident capture,
real-time management and dissemination systems. It is an additional functional service based on the
European Technical Specification known as “SIRI” − Service Interface for Real-time Information. 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 specification for the base SIRI framework on which SIRI-SX is built is presented in three parts:
a) context and framework, including background, scope and role, normative references, terms and
definitions, symbols and abbreviations, business context and use cases (SIRI Part 1: EN 15531-1);
b) the mechanisms to be adopted for data exchange communications links (SIRI Part 2: EN 15531-2);
c) data structures for a series of individual application interface modules (SIRI Part 3: EN 15531-3):
1) Production Timetable (SIRI-PT);
2) Estimated Timetable (SIRI-ET);
3) Stop Timetable (SIRI-ST);
4) Stop Monitoring (SIRI-SM);
5) Vehicle Monitoring (SIRI-VM);
6) Connection Timetable (SIRI-CT);
7) Connection Monitoring (SIRI-CM);
8) General Message (SIRI-GM).
Additional documents are used for additional functional services, to date these are:
— Facilities Management (SIRI-FM) service is used to exchange information on the current status of
facilities such as lifts, escalators or ticketing machines. It provides a short description of the facility
itself, expresses any change to its operational status and specifically the accessibility status for the
disabled or those with special needs people. It provides all the current relevant information relating
to all facilities fulfilling a set of selection criteria (Part 4: CEN/TS 15531-4).
— Situation Exchange (SIRI-SX): this document. The SIRI Situation and Incident Exchange service is
used to exchange information messages between identified participants in a standardised
structured format suitable for travel information services. It enables messages to be sent and to be
revoked (Part 5: CEN/TS 15531-5, this document).
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. The SIRI-SX service is
included in version 1.3 of the schema onwards.
1 Scope
The SIRI Situation Exchange service (SIRI-SX) allows the efficient exchange of data about Situations
caused by planned and unplanned incidents and events and is intended to support the use cases
identified in Annex C. Situations are actual or potential perturbations to normal operation of a transport
network. The SIRI-SX service uses the common SIRI communication framework and services which are
described in EN 15531-1 and EN 15531-2 and not repeated in this document.
The Situation Exchange service has a rich Situation model, allowing a structured description of all
aspects of multimodal travel Situations, including cause, scope, effect and rules for distribution to an
audience. The structured values enabling computer based distribution through a wide variety of
channels, and the presentation of data in different formats for different device and different audiences.
The Situation Exchange Service allows the exchange of incident and event information between,
amongst others:
— Control centres;
— Operations Staff;
— Public Information systems;
— Alert systems and personalised alert systems;
— UTMC systems;
— Journey planners;
— AVMS (Automatic Vehicle Management Systems).
SIRI-SX uses a network model based on the CEN Transmodel conceptual model for Public Transport
networks, schedules and operations, along with the CEN Identification of Fixed Objects in Public
Transport (IFOPT) model for describing physical transport interchanges.
The Situation Exchange service is envisaged as a 'back office' capture and exchange service that will
feed other public facing travel information dissemination systems in particular those using the TPEG
format. Transport Protocol Expert Group (TPEG) is a European Broadcasting Union fostered standard
for broadcasting travel data over Digital Assisted Broadcasting (DAB) radio and other channels. TPEG is
maintained by the Traveller Information Services Association (TISA). To this end, the SIRI-SX situation
classification model has been harmonized as far as possible with that of TPEG and DATEX2 so that full
interoperability can be achieved. Uses of structured elements from TPEG, for which translations already
exist in most European languages, also facilitates human readability in different national languages.
Maintaining and improving a harmonization with TPEG will be a continuing objective. In addition to the
TPEG exchangeable content, SIRI-SX messages contain additional structured information which allows
them to be processed in additional ways.
Situation and computer systems and applications are typically distributed, that is information will be
captured on one system and exchanged with others for dissemination and further processing. This
means that a message design is needed that allows the management of the identity of distributed
messages over time and across different systems, so that subsequent updates to a Situation can be
reconciled by different systems over a network, and obsolete messages can be retired automatically.
The SIRI-SX SITUATION model is designed to support the distributed management of Situations.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
EN 15531-1:2015, Public transport — Service interface for real-time information relating to public
transport operations — Part 1: Context and framework
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 15531-1:2015 and the
following apply.
NOTE In accordance with Transmodel conventions, capital letters are used to indicate conceptual model
entities from Transmodel, for example VEHICLE JOURNEY, STOP PLACE, etc., and also those from IFOPT and SIRI.
Later in this document, the names of classes and attributes expressing these entities in the UML diagrams and the
XML schema are shown in Upper Camel Case, e.g. VehicleJourney. Not all conceptual entities are expressed as
classes and not all concrete classes and attributes relate directly to a conceptual entity.
3.1
Access Space – IFOPT & NeTEx
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.2
Accessibility – IFOPT
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.3
Accessibility Assessment – IFOPT & NeTEx
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.4
Accessibility Limitation – IFOPT & NeTEx
categorisation 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.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.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.7
Boarding Position – IFOPT & NeTEx
location within a QUAY from which passengers may directly board, or onto which passengers may
directly alight from, a PT vehicle
3.8
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.9
Consequence – Trident
outcome of a SITUATION
3.10
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.11
Direction – Transmodel & NeTEx
classification for the general orientation of ROUTEs
Note 1 to entry: In IFOPT the DIRECTION may be an important aspect of a PATH LINK that may only be
traversed one way.
3.12
Easement – SIRI-SX
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
EXAMPLE To use a bus instead of the metro.
3.13
Interchange – Transmodel & NeTEx
scheduled possibility for transfer of passengers between two SERVICE JOURNEYs at the same or
different STOP POINTs
3.14
Level – IFOPT & NeTEx
identified storey (ground, first, basement, mezzanine, etc.) within an interchange building on which
STOP PLACE COMPONENTs reside
Note 1 to entry: A STOP PATH LINK may connect components on different levels.
3.15
Local Service – IFOPT & NeTEx
named service relating to the use of the STOP PLACE or transport services at a particular location, for
example porterage, assistance for disabled users, booking offices, etc
Note 1 to entry: The service may have a VALIDITY CONDITION associated with it. A LOCAL SERVICE is treated
as a form of non-material EQUIPMENT.
3.16
Location – Transmodel
position of a POINT with reference to a given LOCATING SYSTEM (e.g. coordinates)
3.17
Operator – Transmodel & NeTEx
organisation in charge of the operation of some or all transport services within a particular area
3.18
Passenger Accessibility Assessment – IFOPT
categorisation of the ACCESSIBILITY characteristics of a PASSENGER to indicate their requirements for
ACCESSIBILITY
Note 1 to entry: For example that are unable to navigate stairs, or lifts, or have visual or Auditory impairments.
PASSENGER ACCESSIBILITY TYPE corresponds to one or more ACCESSIBILITY LIMITATIONs, allowing the
computation of paths for passengers with constrained mobility. For example, Wheelchair, No Lifts, No Stairs.
3.19
Place – Transmodel & NeTEx
geographic location of any type which may be specified as the origin or destination of a trip
Note 1 to entry: A PLACE may be of dimension 0 (a POINT), 1 (a road section) or 2 (a ZONE).
Note 2 to entry: In IFOPT a PLACE may be of dimension 3 and be further associated with a LEVEL.
3.20
Planned event – SIRI-SX
cause of a SITUATION that is known about in advance
Note 1 to entry: It will have a known start and likely end time.
Note 2 to entry: In SIRI-SX this is recorded as an attribute of a general purpose incident description.
3.21
Projection – Transmodel & NeTEx
An oriented correspondence - of the shape of an ENTITY on a source layer, - onto an entity in a target
layer: e.g. POINT, LINK, LINK SEQUENCE, COMPLEX FEATURE, - within a defined TYPE OF PROJECTION
Note 1 to entry: A general purpose mechanism used in SIRI-SX to indicate the geographical scope of a
SITUATION.
3.22
Publishing Action – SIRI-SX
part of SITUATION ELEMENT content that contains guidance as to how the SITUATION should be
disseminated
3.23
Quay – IFOPT & NeTEx
place where passengers have access to PT vehicles, such as a platform, stance, or quayside
Note 1 to entry: A QUAY may serve one or more VEHICLE STOPPING PLACEs and be associated with one or
more STOP POINTs.
Note 2 to entry: A QUAY is a recursive structure that may contain other sub QUAYs. A child QUAY must be
physically contained within its parent QUAY.
3.24
Reason – TPEG
classification of a SITUATION ELEMENT as being of a particular type
Note 1 to entry: The nature of the REASON is likely to have implications for the duration and consequence of the
SITUATION.
3.25
Route – Transmodel & NeTEx
ordered list of located POINTs defining one single path through the road (or rail) NETWORK
Note 1 to entry: A ROUTE may pass through the same POINT more than once.
Note 1 to entry: Each JOURNEY PATTERN may be associated with a particular ROUTE.
3.26
Situation – Trident
disruption to the planned operation of services
3.27
Situation Element – Trident
record of SITUATION STATE at particular time or over a particular period
Note 1 to entry: A SITUATION is represented by one or more SITUATION ELEMENTs.
Note 2 to entry: A SIRI SITUATION ELEMENT corresponds to a DATEX2 'Situation Record'.
3.28
Situation Identifier – SIRI-SX
unique identifier of a SITUATION ELEMENT made up of several parts, the Country code, Participant
Code, Situation Number and Version number
3.29
Scheduled Stop Point – IFOPT & NeTEx
POINT in a VEHICLE JOURNEY where passengers can board or alight from vehicles
Note 1 to entry: SCHEDULED STOP POINT refines the primary Transmodel sense of a STOP POINT, which is that
of the logical stop point within a scheduled VEHICLE JOURNEY, rather than a physical point in the infrastructure
where boarding and alighting, may take place, for which the terms for specific STOP PLACE COMPONENTS such as
QUAY or BOARDING POSITION are used. Although the same identifiers are often used for both SCHEDULED STOP
POINT and STOP PLACE COMPONENT, a practice which provides significant benefits for data management, they
nonetheless represent distinct concepts. A STOP POINT ASSIGNMENT is used to associate a SCHEDULED STOP
POINT with a STOP PLACE COMPONENT.
3.30
Stop Place – IFOPT & NeTEx
place comprising one or more locations where vehicles may stop and where passengers may board or
leave vehicles or prepare their trip
Note 1 to entry: A STOP PLACE will usually have one or more well-known names.
3.31
Stop Point – Transmodel
POINT where passengers can board or alight from vehicles
3.32
Suitability – IFOPT & NeTEx
whether a particular facility such as a STOP PLACE COMPONENT or VEHICLE can be used by a
passenger with a particular USER NEED
3.33
Transport Mode – Transmodel & NeTEx
characterisation of the operation according to the means of transport (e.g. bus, tram, metro, train, ferry,
ship)
3.34
Traffic Element – Datex2
type of Datex2 Situation Record (i.e. Situation Element) used to describe a road SITUATION
3.35
Update Situation Element– SIRI-SX
record of a change to a particular SITUATION, originally established by a BASE SITUATION ELEMENT
3.36
Unplanned Incident – SIRI-SX
cause of a SITUATION that is not known about in advance
3.37
User Nee
...