CEN/TS 15531-5:2011

SLOVENSKI STANDARD
01-september-2011
-DYQLSUHYR]9PHVQLN]DVWRULWHYLQIRUPLUDQMDYUHDOQHPþDVX]DSRWUHEH
GHORYDQMDMDYQHJDSUHYR]DGHO9PHVQLNLIXQNFLMVNHVWRULWYH,]PHQMDYD
SRGDWNRYRVLWXDFLML
Public transport - Service interface for real-time information relating to public transport
operations - Part 5: Functional service interfaces - Situation Exchange
gIIHQWOLFKHU9HUNHKU'LHQVWHVFKQLWWVWHOOHIUGHQ(FKW]HLWDXVWDXVFKYRQ
%HWULHEVLQIRUPDWLRQHQGHVg3196,5,7HLO)XQNWLRQHOOH6HUYLFHVFKQLWWVWHOOH
6LWXDWLYHU
$XVWDXVFK
Service d'échanges de données temps réel pour le Transport en Commun - Partie 5:
interfaces de service fonctionnel - Echanges de perturbation structurés (causes et
conséquences détaillées)
Ta slovenski standard je istoveten z: CEN/TS 15531-5:2011
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-5
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
July 2011
ICS
English Version
Public transport - Service interface for real-time information
relating to public transport operations - Part 5: Functional
service interfaces - Situation Exchange
Service d'échanges de données temps réel pour le Öffentlicher Verkehr - Diensteschnittstelle für den
Transport en Commun - Partie 5: interfaces de service Echtzeitaustausch von Betriebsinformationen des ÖPNV
fonctionnel - Echanges de perturbation structurés (causes (SIRI) - Teil 5: Funktionelle Serviceschnittstelle: Situativer
et conséquences détaillées) Austausch
This Technical Specification (CEN/TS) was approved by CEN on 19 March 2011 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, 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: Avenue Marnix 17, B-1000 Brussels
© 2011 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15531-5:2011: E
worldwide for CEN national Members.

Contents Page
Foreword . 4
Introduction . 6
1 Scope . 7
2 Normative references . 7
3 Terms and definitions. 8
4 Symbols and abbreviations . 12
5 Situations as Software Entities . 12
5.1 General . 12
5.2 Structured Situations . 13
5.3 Distributed Situation processing . 14
5.3.1 Identity and Write-Only Updates . 14
5.3.2 Currency and the Situation Life Cycle . 15
5.3.3 Representational model for Situation Elements . 16
5.3.4 Update chains − Causal chains . 17
5.3.5 Cross-referencing Situations − Causal chains . 18
5.3.6 Branching and distributed updates . 18
5.3.7 Archiving . 20
5.4 Summary of Situation Management . 20
5.4.1 General . 20
5.4.2 Situation Identity . 20
5.4.3 Situation Life Cycle . 21
5.4.4 Situation Update Content . 21
5.4.5 Example of identifier allocation . 21
5.4.6 Date time stamps as identifiers . 22
5.5 Interoperability of Situation management systems . 22
5.5.1 General . 22
5.5.2 Datex2 Interoperability . 23
5.5.3 TPEG Interoperability . 23
5.5.4 Communications Bandwidth . 24
6 The Situation Model . 24
6.1 General . 24
6.2 Representing a PT Situation in SIRI-SX. 25
6.2.1 Summary of PT Situation model . 25
6.2.2 PT Situation Element Body . 26
6.2.3 PT Situation Body Details . 27
6.2.4 PT Situation Reason . 29
6.2.5 Situation Consequence . 31
6.2.6 The PT AffectsScope . 33
6.3 Representing a Road Situation in SIRI-SX . 39
6.3.1 Summary of Road Situation model . 39
6.3.2 Road Situation Element Body . 40
6.3.3 Common Accessibility . 41
6.3.4 Publishing Actions . 42
6.3.5 Common Types . 44
7 Situation Exchange Service [SX] . 50
7.1 Purpose . 50
7.2 Description . 50
7.3 Reference Data . 50
7.4 Capability and Permission Matrices . 50
7.4.1 Capability Matrix . 50
7.4.2 Permission Matrix . 52
7.5 UML Diagrammatic Representation . 53
7.5.1 General . 53
7.5.2 UML Detailed Diagram of SituationExchangeRequest . 54
7.5.3 UML Diagram of SituationExchangeDelivery - Summary . 55
7.5.4 UML Diagram of SituationExchangeDelivery - Detail . 56
7.5.5 UML Diagram of SituationContext . 57
7.6 SituationExchangeRequest . 58
7.6.1 SituationExchangeRequest Definition . 58
7.6.2 SituationStatusFilter Definition . 60
7.6.3 SituationNetworkFilter Definition. 60
7.6.4 SituationStopPlaceFilter Definition . 61
7.6.5 SituationJourneyFilter Definition . 61
7.6.6 SituationPlaceFilter Definition . 61
7.6.7 SituationExchangeRequest Example . 62
7.7 SituationExchangeSubscriptionRequest . 62
7.7.1 SituationExchangeSubscriptionRequest Definition . 62
7.7.2 SituationExchangeSubscriptionRequest Example . 63
7.8 SituationExchangeDelivery . 63
7.8.1 ServiceDelivery with a SituationExchangeDelivery . 63
7.8.2 SituationExchangeDelivery Element . 64
7.8.3 SituationContext Element . 64
7.8.4 SituationNetworkContext Element. 65
7.8.5 PtSituationElement . 65
7.8.6 RoadSituationElement . 104
8 SituationExchangeDelivery Examples - SituationExchangeDelivery PT Examples . 107
Annex A (normative) Notation . 109
Annex B (normative) Comparison of Terms . 114
Annex C (informative) Use Cases for Situation Exchange . 117
Bibliography . 123
Foreword
This document (CEN/TS 15531-5:2011) has been prepared by Technical Committee CEN/TC 278 ―Road
transport and traffic telematics‖, 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 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.
The SIRI Situation Exchange service (SIRI-SX) 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: CEN/TS 15531-1);
b) the mechanisms to be adopted for data exchange communications links (SIRI Part 2: CEN/TS 15531-2);
c) data structures for a series of individual application interface modules (SIRI Part 3: CEN/TS 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 needspeople. It provides all the current relevant information relating to all facilities
fulfilling a set of selection criteria (Part 4: prCEN/TS 15531-4).
Situation Exchange (SIRI-SX): this document. The SIRI Situation & 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:
FprCEN/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.
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, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia,
Spain, Sweden, Switzerland and the United Kingdom.
Introduction
Public transport services increasingly rely 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.
Furthermore, this European 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.

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
CEN/TS 15531-1 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).
SIR-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. To this end, the
SIRI-SX situation classification model has been harmonised 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 harmonisation 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 referenced documents are indispensable for the application 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.
CEN/TS 15531-1:2007, 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 CEN/TS 15531-1:2007 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. Note 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
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 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
ACCESSIBILITY characteristics of an entity used by PASSENGERS such as a STOP PLACE, or a STOP
PLACE COMPONENT
NOTE Described by ACCESSIBILITY LIMITATIONs, and/or a set of SUITABILITIES.
3.4
Accessibility Limitation – IFOPT
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 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 This may subsequently be followed by UPDATE SITUATION ELEMENTS that record further changes.
3.7
Boarding Position – IFOPT
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 Different transfer times may be necessary to cover interchange over a given connection link, depending on the
kind of passenger.
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 For SIRI-SX, CONTROL ACTIONs may often give rise to a SITUATION, but are entirely distinct concepts.
3.11
Direction – Transmodel
classification for the general orientation of ROUTES
NOTE 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
Level – IFOPT
identified storey (ground, first, basement, mezzanine, etc.) within an interchange building on which STOP
PLACE COMPONENTS reside
NOTE A STOP PATH LINK may connect components on different levels.
3.14
Local Service – IFOPT
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 The service may have a VALIDITY CONDITION associated with it. A LOCAL SERVICE is treated as a form of
non-material EQUIPMENT.
3.15
Location – Transmodel
position of a POINT with reference to a given LOCATING SYSTEM (e.g. coordinates)
3.16
Operator – Transmodel
organisation in charge of the operation of some or all transport services within a particular area
3.17
Passenger Accessibility Assessment – IFOPT
categorisation of the ACCESSIBILITY characteristics of a PASSENGER to indicate their requirements for
ACCESSIBILITY
NOTE 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.18
Place – Transmodel
geographic location of any type which may be specified as the origin or destination of a trip
NOTE 1 A PLACE may be of dimension 0 (a POINT), 1 (a road section) or 2 (a ZONE).
NOTE 2 In IFOPT a PLACE may be of dimension 3 and be further associated with a LEVEL.
3.19
Plannedevent – SIRI-SX
cause of a SITUATION that is known about in advance
NOTE 1 It will have a known start and likely end time.
NOTE 2 In SIRI-SX this is recorded as an attribute of a general purpose incident description.
3.20
Publishing Action – SIRI-SX
part of SITUATION ELEMENT content that contains guidance as to how the SITUATION should be
disseminated
3.21
Quay – IFOPT
place where passengers have access to PT vehicles, such as a platform, stance, or quayside
NOTE 1 A QUAY may serve one or more VEHICLE STOPPING PLACEs and be associated with one or more STOP
POINTS.
NOTE 2 A QUAY is a recursive structure that may contain other sub QUAYs. A child QUAY must be physically
contained within its parent QUAY.
3.22
Reason – TPEG
classification of a SITUATION ELEMENT as being of a particular type
NOTE The nature of the REASON is likely to have implications for the duration and consequence of the SITUATION.
3.23
Route – Transmodel
ordered list of located POINTs defining one single path through the road (or rail) network
NOTE 1 A ROUTE may pass through the same POINT more than once.
NOTE 2 Each JOURNEY PATTERN may be associated with a particular ROUTE.
3.24
Situation – Trident
disruption to the planned operation of services
3.25
Situation Element – Trident
record of SITUATION STATE at particular time or over a particular period
NOTE 1 A SITUATION is represented by one or more SITUATION ELEMENTS.
NOTE 2 A SIRI SITUATION ELEMENT corresponds to a DATEX2 'Situation Record'.
3.26
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.27
Scheduled Stop Point – IFOPT
POINT in a journey where passengers can board or alight from vehicles
NOTE SCHEDULED STOP POINT refines the primary Transmodel sense of a STOP POINT, which is that of the
logical stop point within a scheduled 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.28
Stop Place – IFOPT
place comprising one or more locations where vehicles may stop and where passengers may board or leave
vehicles or prepare their trip
NOTE A STOP PLACE will usually have one or more well known names.
3.29
Stop Point – Transmodel
POINT where passengers can board or alight from vehicles
3.30
Suitability – IFOPT
whether a particular facility such as a STOP PLACE COMPONENT or VEHICLE can be used by a passenger
with a particular USER NEED
3.31
Transport Mode – Transmodel
characterisation of the operation according to the means of transport (e.g. bus, tram, metro, train, ferry, ship)
3.32
Traffic Element – Datex2
type of Datex2 Situation Record (i.e. Situation Element) used to describe a road situation
3.33
Update Situation Element– SIRI-SX
record of a change to a particular SITUATION, originally established by a BASE SITUATION ELEMENT
3.34
Unplanned Incident – SIRI-SX
cause of a SITUATION that is not known about in advance
3.35
User Need – IFOPT
ACCESSIBILITY requirement of a PASSENGER
EXAPMLE if the passenger is unable to navigate stairs, or lifts, or has visual or auditory impairments.
3.36
Validity Condition – Transmodel
condition used in order to characterise a given VERSION of a VERSION FRAME
NOTE A VALIDITY CONDITION consists of a parameter (e.g. date, triggering event, etc.) and its type of application
(e.g. for, from, until, etc.).
3.37
Vehicle Journey – Transmodel
planned movement of a public transport vehicle on a DAY TYPE from the start point to the end point of a
JOURNEY PATTERN on a specified ROUTE
4 Symbols and abbreviations
The common symbols and abbreviations used in the SIRI document set are presented in CEN/TS 15531-1. In
addition the following terms are used:
DATEX2 Data Exchange Version 2
EBU European Broadcasting Union
ICS  Incident Capture System
QoS Quality of Service
TPEG-PTI Transport Protocol Experts Group Public Transport Information
SIRI-SX SIRI Situation Exchange
SIRI-FM SIRI Facilities Management
5 Situations as Software Entities
5.1 General
In a travel information system, 'Situations' are data objects describing an incident, typically an unplanned
event such as a disruption, but also planned events that affect public transport or its use, such as engineering
works, or major public events that will affect use of transport. They will be captured and recorded on one
system and then be transmitted to other systems to convey information about the current status to travellers
and to transport operator staff. Those other systems will need to transform the data to suit different delivery
channel requirements. At any time, further developments may occur that need to be represented by updates
to the original Situation (or as further related Situations), and a distributed situation model must allow for the
propagation and reconciliation of these changes across systems.
To support distributed processing of Situations a number of basic principles need to be followed:
use of a rich structured Situation representation that can be emitted in standards compliant renderings
such as the European Broadcasting Union (EBU) Transport Protocol Experts Group (TPEG) specification;
assignment of a persistent Identity to Situations within a global namespace; so they may pass into and
out of different systems and still be matched with previous instantiations;
use of write-only updates suitable for store and forward processing in a distributed environment;
use of a lifecycle model with well defined edit-version-release states;
use of well defined data reference systems. SIRI-SX uses a conceptual model for the scope of the
application domain − Public Transport Situations − based on open standards (CEN Transmodel), allowing
the sharing of references with other Transmodel based systems and services.
We elaborate on these below.
5.2 Structured Situations
A Situation object needs to be both machine readable and human readable (see Figure 1). To be machine
readable requires a set of structured elements with precise meaning as to the nature and scope of the
Situation, in particular as to its temporal and network scope (indicated by a location model) and its
categorisation that can be interpreted by agents such as station displays, journey planners and alert engines.
To be human readable, the Situation must be renderable on different devices in different formats as a textual
and graphic representation that a human can understand. The text may be generated automatically from the
structured elements, be explicitly encoded, or both.
The Situation must also include identity and cross- referencing information that can be used to track its
progress across different systems.

Figure 1 — Situation Structure elements
The actual structured Situation model needs to have components to describe its import, including:

Identity: elements to identify and manage the situation and its components;
Cross-reference: elements to relate the situation to other situations to which it is related;
Audit: elements to identify the source of the situation;
Situation body: elements – a set of structured details characterising the nature and processing of the
situation, including its current status, scope of effect, classification, human readable description,
consequence and suggested distribution.
5.3 Distributed Situation processing
5.3.1 Identity and Write-Only Updates
A distributed situation data model represents situations as information objects that may be distributed over
many different systems, typically being created on one system and then displayed and sometimes augmented
by others. Distributed systems raise considerations of identity and concurrency of data objects.
A particular case in point arises when the same Situation may reach a particular dissemination system via
different routes; in which case the consumer needs to be able to establish that the data refers to the same
event and not two different instances of a similar event. The same Situation may also return to the originating
system and need to be recognized as a known Situation and not a new instance.
In order for updates to be propagated and reconciled in a distributed processing environment, a unique
persistent identity must be maintained across these systems for the Situation and its updates, and there must
be a means of identifying the most recent content. This makes it possible for different systems to recognize
repeated references to the same Situation.
A unique identifier allows the tracking and reconciliation of updates to a given situation that has been
recognised as a specific single event and is being managed as such. A more complicated question of
recognition of similarity and identity reconciliation arises from the fact that a real world disruption may give rise
to a number of separate Situation Objects on different systems, with different unique identifiers. These may be
subsequently recognized as related and consolidated Cross-referencing mechanisms are needed to allow this
to be represented in the data. Both human and computer aided processes may be used to undertake the
recognition and consolidation.
A distributed processing model also raises questions of currency – how does a consumer system determine
which is the latest information about a situation? What should a dissemination system do if the communication
link is lost? How can one distinguish between absence of information and absence of information service?
Typically both metadata and built-in mechanisms such as heartbeats are needed to address this need.
Synchronisation to a universal clock is also necessary.
Figure 2 illustrates the store and forward processing typical of Situation handling whereby Situations and
updates reach downstream systems via number of different routes with different intermediate steps. Each
system holds its own representation of a situation model and it is only the situation element (i.e. an account of
changes to the situation), and not the situation itself which is exchanged.
Figure 2 — Distributed Message Management
5.3.2 Currency and the Situation Life Cycle
Situations typically undergo a life cycle that will take them from initial capture as a new live situation, through
additional verification and dissemination stages, followed possibly by one or more updates, and finally closure.
However, as soon as a representation of a situation exists in more the one incident management system
(perhaps even on the same computer), each of which might wish to make further updates to the Situation
content, issues of coordination arise. How do changes get propagated and reconciled?
Furthermore, there is often also a need to maintain an exact audit trail of the information flow in incident
management systems, recording when each update was entered into the system, along with data about where
it came from. This can be used both to improve operational processes, and to monitor adherence to operating
procedures and performance targets.
Another consideration is that the communication links are potential points of failure, so the system must allow
for efficient resynchronisation after loss of connection, as well as allowing consumer systems to make suitable
judgements as to the continued currency of Situations during a prolonged interruption.
Together, these considerations lead to the need for a "write-only" content model which uses a formal edit-
version-release process to progress an initial situation and its updates through a managed lifecycle.
This lifecycle occurs at two levels: a "macro" level progression of the overall situation, and a "micro" level of
the individual updates to the situation.
5.3.3 Representational model for Situation Elements
Figure 3 shows a fundamental UML class model for representing distributed situation elements as a
conceptual model. A Situation comprises one or more Situation Element instances. In effect there are two
types of Situation Element object; the original base Situation Element, then one or more update Situation
Element updates.
Both types of element undergo an edit-version-release process to control their use; this is marked by a
versioning time: for an element in draft the time is empty. Once populated, the Situation element is considered
fixed.
In SIRI-SX, as in TPEG and other incident management systems, we model the relationship between base
and updates by allocating a unique situation number that is common to both base and update entities, and
use a version number to distinguish each further update. Numbers are unique within participant – each of
whom has a unique identifier within country. This means that we can group a base situation element and its
updates simply by their common identifier parts, and can exchange an update independently of the base
situation and without explicitly referencing all previously known updates.
To indicate a relationship with a completely separate situation element of a different Situation, an element may
also contain one or more RelatedSituation references that link the Situation element with other Situation
elements; in this case the association is explicit.
Note that the model in principle allows updates for the same situation to be created on more than one system
if desired. This can give rise to branches in the update chain. It is up to a given consumer system to serialise
and reconcile all the updates it has available in order to arrive at a consolidated view of a given Situation (see
discussion of branching below).
The model allows for different types of situation body to be used to for public transport and for road related
situations (which typically have different properties). SIRI-SX is primarily
...