CEN/TS 15531-6:2024
(Main)Public transport - Service interface for real-time information relating to public transport operations - Part 6: Functional service interfaces: Control Actions
Public transport - Service interface for real-time information relating to public transport operations - Part 6: Functional service interfaces: Control Actions
This document specifies an additional SIRI functional service to exchange information about Control Actions, between monitoring systems and 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. As for Transmodel, public transport modes include new modes of transport (vehicle sharing, vehicle pooling, etc.).
This document describes the SIRI Control Action service, one of a modular set of services for the exchange of Real-time information. The Control Action service (SIRI-CA) is concerned with the exchange of information about decision made concerning the real-time management of the operation of a transport system as performed by operators while operating the services.
Öffentlicher Verkehr - Dienstschnittstelle für Echtzeitinformationen bezogen auf Operationen im Öffentlichen Verkehr - Teil 6: Funktionale Dienstschnittstelle - Steuerungsaktion
No scope available
Transport public - Interface de service pour les informations en temps réel relatives aux opérations de transport public - Partie 6 : Interfaces des services fonctionnels - Actions de régulation
No scope available
Javni prevoz - Vmesnik za informiranje v realnem času za potrebe delovanja javnega prevoza - 6. del: Vmesniki funkcionalnih storitev: Nadzorni ukrepi
Ta dokument določa dodatno funkcionalno storitev vmesnika za informiranje v realnem času (SIRI) za izmenjavo informacij o nadzornih ukrepih med nadzornimi sistemi in strežniki, ki vsebujejo podatke o vozilu javnega prevoza ali času potovanja v realnem času. To vključuje nadzorne centre izvajalcev prevoza in informacijske sisteme, ki zagotavljajo potovalne informacije za potnike. V okviru podatkovnega modela Transmodel načini javnega prevoza
vključujejo nove načine prevoza (souporaba vozil, sopotništvo itd.).
Ta dokument opisuje storitev nadzornih ukrepov vmesnika za informiranje v realnem času (SIRI-CA), ki je del modularnega nabora storitev za izmenjavo informacij v realnem času. Storitev nadzornih ukrepov vmesnika za informiranje v realnem času zajema izmenjavo informacij o sprejemu odločitve v zvezi z upravljanjem delovanja sistema prevoza v realnem času s strani upravljavcev med izvajanjem storitev.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-oktober-2024
Javni prevoz - Vmesnik za informiranje v realnem času za potrebe delovanja
javnega prevoza - 6. del: Vmesniki funkcionalnih storitev: Nadzorni ukrepi
Public transport - Service interface for real-time information relating to public transport
operations - Part 6: Functional service interfaces: Control Actions
Öffentlicher Verkehr - Dienstschnittstelle für Echtzeitinformationen bezogen auf
Operationen im Öffentlichen Verkehr - Teil 6: Funktionale Dienstschnittstelle -
Steuerungsaktion
Transport public - Interface de service pour les informations en temps réel relatives aux
opérations de transport public - Partie 6 : Interfaces des services fonctionnels - Actions
de régulation
Ta slovenski standard je istoveten z: CEN/TS 15531-6:2024
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-6
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
June 2024
TECHNISCHE SPEZIFIKATION
ICS 35.240.60
English Version
Public transport - Service interface for real-time
information relating to public transport operations -
Part 6: Functional service interfaces: Control Actions
Transport public - Interface de service pour les Öffentlicher Verkehr - Dienstschnittstelle für
informations en temps réel relatives aux opérations de Echtzeitinformationen bezogen auf Operationen im
transport public - Partie 6 : Interfaces des services öffentlichen Verkehr - Teil 6: Funktionale
fonctionnels - Actions de régulation Dienstschnittstelle - Steuerungsaktion
This Technical Specification (CEN/TS) was approved by CEN on 15 April 2024 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, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATIO N
EUROPÄISCHES KOMITEE FÜR NORMUN G
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2024 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15531-6:2024 E
worldwide for CEN national Members.
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 8
2 Normative references . 8
3 Terms and definitions . 8
4 Symbols and abbreviations . 8
5 Business Context . 8
5.1 General. 8
5.2 Main use cases and needs . 9
5.3 System overview and dataflow . 9
6 Relation with Transmodel Concepts . 12
6.1 General. 12
6.2 Vehicle Control Actions . 13
6.3 Elementary Journey Control Actions . 14
6.4 Composite Control Actions . 15
6.5 Interchange Control Actions . 16
6.6 Vehicle Detection . 17
7 Communication Infrastructure . 17
7.1 General. 17
7.2 SIRI Service Request table . 17
7.3 Communications Bandwidth . 19
8 Control Action Service [CA] . 19
8.1 Description . 19
8.2 Reference Data . 20
8.3 Capability and Permission Matrices . 20
8.3.1 Capability Matrix . 20
8.3.2 Permission Matrix . 22
8.4 ControlActionRequest . 22
8.4.1 ControlActionRequest Definition . 22
8.4.2 ControlActionRequest Example . 23
8.5 ControlActionSubscriptionRequest . 24
8.5.1 ControlActionSubscriptionRequest Definition . 24
8.6 ControlActionDelivery . 24
8.6.1 General. 24
8.6.2 ControlActionHeaderStructure. 24
8.6.3 Header and management of CONTROL ACTIONS. 25
8.6.4 VehicleControlAction. 30
8.6.5 JourneyControlAction . 31
8.6.6 NetworkControlAction . 39
8.6.7 Interchange Control Action . 40
8.6.8 DriverMessage . 41
8.6.9 VehicleDetecting . 43
8.7 Example of Control Action Delivery . 44
9 Integration with other SIRI services . 45
9.1 Integration with SIRI Situation Exchange . 45
9.2 Integration with SIRI Estimated Timetable . 46
9.3 Examples of possible relations between SIRI services related to Control Actions . 46
10 Further improvements to Transmodel . 48
10.1 General . 48
10.2 Concept of CHANGE OF STOP POINT STATUS . 48
10.3 Concept of GROUP OF CONTROL ACTIONS . 49
Bibliography . 51
European foreword
This document (CEN/TS 15531-6:2024) 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 shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a standardization request addressed to CEN by the European
Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
Member States.
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 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, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye 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 service running, and so on.
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 describes the SIRI Control Action (SIRI-CA) is an additional service, part 6, based on the
European normative standard 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 SIRI European Standard is presented in three normative standard parts:
— context and framework, including background, scope and role, normative references, terms and
definitions, symbols and abbreviations, business context and use cases (EN 15531-1);
— the mechanisms to be adopted for data exchange communications links (EN 15531-2);
— data structures for a series of individual application interface modules PT, ET, ST, SM, VM, CT, CM,
GM (EN 15531-3).
Three additional parts define additional functional services as CEN Technical Specifications:
— additional data structures for additional application interface module FM (CEN/TS 15531-4);
— additional data structures for additional application interface module SX (CEN/TS 15531-5);
— additional data structures for additional application interface module CA (CEN/TS 15531-6).
It is recognized 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.
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 utilize 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 standardized 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 standardized, 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.
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/.
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.
The SIRI Control Action (SIRI-CA) service defined in this document enables the exchange of information
on Control Actions as managed by operators while operating the mobility services.
A Control Action is a decision made about the management of the operation of a transport system, for
example to cancel or alter a planned journey. Such decisions are typically made by controllers in the
control rooms of AVMS (Automated Vehicle Monitoring Management Systems) but may also be made
automatically by the monitoring processes of the AVMS itself. In a computer system, a Control Action can
be explicitly represented by data objects with standardized data structures.
The existing SIRI Situation Exchange Service provides a comprehensive description of events,
disruptions, as well as general-purpose information, but is specifically dedicated to exchanging messages
for passenger information, and does not provide any structured description of Control Actions
themselves, even in situations where the Control Action is the main cause of the Situation . Furthermore,
some Control Actions are purely internal and don’t have an external cause or a consequent Situation of
interest to passengers.
Both query and publish subscribe interactions are supported.
1 Scope
This document specifies an additional SIRI functional service to exchange information about Control
Actions, between monitoring systems and 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. As for Transmodel, public transport modes
include new modes of transport (vehicle sharing, vehicle pooling, etc.).
This document describes the SIRI Control Action service, one of a modular set of services for the exchange
of Real-time information. The Control Action service (SIRI-CA) is concerned with the exchange of
information about decision made concerning the real-time management of the operation of a transport
system as performed by operators while operating the services.
2 Normative 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.
EN 15531-1:2022, 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:2022 apply.
4 Symbols and abbreviations
For the purposes of this document, the symbols and abbreviations given in EN 15531-1:2022 apply.
5 Business Context
5.1 General
In the context of the Delegated Act for Multimodal Information Services from the European Commission
the number of SIRI implementations is increasing every day. A common feedback comment from such
implementations is the need to be able to exchange information to describe CONTROL ACTIONs. The
controllers of AVMS (Automated Vehicle Management Systems), who are the main source of real-time
information for public transport, typically manage the system using CONTROL ACTIONs prior to deriving
passenger information from them.
As is the case for SITUATIONs in the SIRI-SX Service Control Actions are often exchanged in real time but
may also be planned in a long time in advance of the start of vehicle journeys. Both use cases are to be
managed through this SIRI-CA service. Also note that certain SIRI functional services (such as SIRI
Estimated Timetable) can already be used in effect to communicate some type of journey updates such
as creation/ cancellation – however the expected time window for Control Action is usually longer than
the one expected for Passing Times and can include additional operation information.
5.2 Main use cases and needs
The main use cases handled by a SIRI Control Action service are the following:
— The primary Control Actions to be exchanged are as follows (but this list can, of course, be extended):
— Vehicle replacement / change / cancellation;
— Spacing and passing time updates;
— Journey creation, cancellation and change;
— Route changes;
— The blocking of use of stops;
— In most cases, it is the AVMS that must provide this data for aggregation and distribution:
— To a situation management system => complementing SIRI-SX;
— To an aggregator that will use it and interpret it to generate passenger information (when
necessary);
— To a Passenger Information System that may use them (but not directly since Control Actions
may be hardly understandable for the passengers);
— To an operational/control centre (for information), usually also managing other modes (road…);
— To online/digital services;
— The Control Action’s structured description will, for example, be used to:
— Provide information to the operating subsystem;
— Create corresponding disruption and associated information;
— Disseminate the consequences to Passenger Information System via SIRI services but also
possibly directly to displays, websites, etc. (but probably not the Control Actions themselves
since they may be hardly understandable for the passengers);
— Provide the Control Action information to a concentrator/aggregator which redistributes it to
the other systems;
— Provide the Control Action information to a journey planner.
5.3 System overview and dataflow
Transmodel defines the CONTROL ACTION as being “An action resulting from a decision taken by the
controller causing an amendment of the operation planned in the PRODUCTION PLAN.”
Therefore, the SIRI Control Action Service is mainly designed for B2B exchanges and does not have any
planned usage for B2C communication.
However, as shown in the figures below, CONTROL ACTIONs can be provided to Data Harmonisers, using
them as a base to create passenger information disseminated using typically SIRI SX (Situation Exchange)
and SIRI ET (Estimated Timetable): CONTROL ACTIONs are most often the operational actions that result
in delays (respacing, etc.) cancellations, rerouting, etc. they do have consequences on the passenger
information, but are also often hardly understandable by passenger. This is the reason why the Data
Harmoniser needs to process the CONTROL ACTIONs description in order to create an easily
understandable information for passengers. For example, in a situation following an unplanned driver
replacement resulting in several CONTROL ACTIONs (a journey cancellation, driver de-assignment and
new driver assignment, a journey creation including the definition of new passing times), the Data
Harmoniser will probably generate a single SIRI SX SITUATION saying something like “due to a driver’s
illness, the bus is delayed by 10 minutes”, making this set of CONTROL ACTIONs much easier to
understand for the passenger. It also has to be noted that not all CONTROL ACTIONs are resulting in some
passenger information: for example, the replacement of a VEHICLE before the start of a JOURNEY, or the
replacement of a DRIVER will not result in any passenger information since they have no consequences
on the offered services.
The figures below describe two possible system designs and data flows. These figures propose the
following roles:
— Realtime Data Hub (Aggregator): aggregates the data from multiple sources, just checking for
consistency and data quality, but without changing them or inferring new data. The resulting
aggregated data set is provided as output allowing to have one single access for multiple data
sources;
— Data Harmoniser: analyse the data, merge them when necessary (for example to provide data from
multiple providers at a single stop), relates the known scheduled timetables to the received real-time
information, process and enrich the received data (connect situation from ICS and EMS to journey
information provide bay AVMS, transform CONTROL ACTION in passenger information available via
SIRI SX, add translations when necessary, etc.). Note that it often happens that the Data Hub and Data
Harmoniser roles are managed by a single system;
— Automated Vehicle Monitoring System (AVMS): operational control of the service, creates and
manages CONTROL ACTIONs;
— Event Management System (EMS): creates and manages event information independently from the
AVMS;
— Incident Capturing System (ICS): captures and follows events independently from the AVMS.
The first figures describe a system with Data Hub feeding a Data Harmoniser. This is the type a system
where merging the Hub and the Harmoniser is quite natural. Also note that a system with just a Hub and
no Harmoniser is also possible (this is the situation of quite a lot of National Access Points).
Figure 1 — System with a Data Hub feeding a Data Harmoniser (and using control actions)
The first figures describe a system with multiple Data Harmoniser feeding a Data Hub. This design also
shows the possibility of having totally independent EMS and ICS, and an AVMS providing data not
harmonized with the other (this is not a recommendation but a situation that may occur in real life, and
that can be managed using SIRI).
Figure 2 — System with Data Harmonisers feeding a Data Hub (and using control actions)
6 Relation with Transmodel Concepts
6.1 General
The CONTROL ACTIONs in SIRI are, of course, expected to be fully based on Transmodel (note that the
use of uppercase for CONTROL ACTION makes here an explicit reference to its Transmodel definition, as
this is the case for all specification in the Transmodel’s ecosystem).
NOTE The following lines are providing a brief overview of Transmodel’s CONTROL ACTION; refer to
EN 12896-4, Public transport - Reference data model - Part 4: Operations monitoring and control for a
comprehensive description.
Transmodel describes all the necessary scheduled information (exchanged using NeTEx) that may be
variously referenced by CONTROL ACTIONs, such as VEHICLE JOURNEYs, VEHICLE ASSIGNMENTs,
TIMING POINTs, RUN TIMEs, BLOCKs and VEHICLE SERVICEs, DUTies and DUTY STRETCHs, etc. and
more generally the detailed production plan.
The SIRI CONTROL ACTION Service will complement this with real-time information, mainly based on
the concepts described by Transmodel.
Transmodel identifies four main groups of CONTROL ACTIONs, as summarized in the following figure.
Figure 3 — Transmodel CONTROL ACTION overview
6.2 Vehicle Control Actions
Vehicle Control Actions specify modifications to resources used to provide a journey, such as the VEHICLE
or crewing or BLOCK allocation. The following figure describes the VEHICLE CONTROL ACTIONS (refer
to Transmodel for a full description). Such changes may not necessarily be of interest for passenger
information.
Figure 4 — Transmodel: VEHICLE CONTROL ACTION
The following figure describes the JOURNEY CONTROL ACTIONS (refer to Transmodel for a
comprehensive description of these CONTROL ACTIONs).
6.3 Elementary Journey Control Actions
Elementary Vehicle control Actions specify modifications to a specific journey such as cancellation, short-
running, delays, as shown in the following figure (See Transmodel 6.0 for details).
Figure 5 — Transmodel: JOURNEY CONTROL ACTION
6.4 Composite Control Actions
Composite Control Actions specify modifications affecting groups of journeys such as a respacing to keep
a balanced interval period. The following figure describes the COMPOSITE JOURNEY CONTROL ACTIONS
(refer to Transmodel for a full description).
Figure 6 — Transmodel: COMPOSITE JOURNEY CONTROL ACTION
6.5 Interchange Control Actions
Interchange Control Actions specify modifications affecting planned interchange between journeys The
following figure describes the INTERCHANGE CONTROL ACTIONS (refer to Transmodel for a full
description).
Figure 7 — Transmodel: INTERCHANGE CONTROL ACTION
6.6 Vehicle Detection
CONTROL ACTIONs are closely related to the processes of VEHICLE DETECTING which are often used by
AVMS to detect the need for a CONTROL ACTION.
The following figure describes the VEHICLE DETECTION (refer to Transmodel for a comprehensive
description). The VEHICLE DETECTION is not by itself a CONTROL ACTION but is also part of the request
received from SIRI users (CONTROL ACTIONs are often strongly connected, or triggered by VEHICLE
DETECTIONs).
Figure 8 — Transmodel: VEHICLE DETECTION
7 Communication Infrastructure
7.1 General
The Control Action Service makes changes to the standard SIRI communication infrastructure.
7.2 SIRI Service Request table
The Control Action Service adds elements as follows to SIRI as per “SIRI Request and Delivery Types”, in
Part 2 of the SIRI document set, EN 15531-2:2022:
Table 1 — Service request table
SIRI Functional Request Subscription Request Delivery Capability Request
Service
Container ServiceRequest SubscriptionRequest ServiceDelivery
Timetable Production ProductionTimetableRequest ProductionTimetableSubscriptionRe ProductionTimetableDelivery ProductionTimetableCapabilityRequest
quest
Real-time EstimatedTimetableRequest EstimatedTimetableSubscriptionReq EstimatedTimetableDelivery EstimatedTimetableCapabilityRequest
uest
Progress Stop Timetable StopTimetableRequest StopTimetableSubscriptionRequest StopTimetableDelivery StopTimetableCapabilityRequest
Stop Monitoring StopMonitoringRequest StopMonitoringSubscriptionRequest StopMonitoringDelivery StopMonitoringCapabilityRequest
Vehicle Monitoring VehicleMonitoringRequest VehicleMonitoringSubscriptionReque VehicleMonitoringDelivery VehicleMonitoringCapabilityRequest
st
Interchange Connection ConnectionTimetableRequest ConnectionTimetableSubscriptionRe ConnectionTimetableDelivery ConnectionTimetableCapabilityRequest
Timetable quest
Connection ConnectionMonitoringRequest ConnectionMonitoringSubscriptionRe ConnectionMonitoringFeederDelive ConnectionMonitoringFeederCapabilityR
Monitoring quest ry equest
ConnectionMonitoringDistributorDe ConnectionMonitoringDistributorCapabil
livery ityRequest
Info General Message GeneralMessageRequest GeneralMessageSubscriptionReques GeneralMessageDelivery GeneralMessageCapabilityRequest
t
Facilities Facility Monitoring FacilityMonitoringRequest FacilityMonitoringSubscriptionReque FacilityMonitoringDelivery FacilityMonitoringCapabilityRequest
st
Situations Situation Exchange SituationExchangeRequest SituationExchangeSubscriptionReque SituationExchangeDelivery SituationExchangeCapabilityRequest
st
Control Control Action ControlActionRequest ControlActionSubscriptionRequest ControlActionDelivery ControlActionCapabilityRequest
Action
7.3 Communications Bandwidth
As with other SIRI functional services, the SIRI-CA service is intended primarily for server to server
communication over broadband IP between back end control systems and distribution hubs. It uses an
XML structure that is relatively verbose and includes both a rich structured content and textual
descriptions. It is not optimized for over the air real-time communication with vehicles or fixed
equipment using communication over a constrained bandwidth. It should however be straightforward to
make a one-way transform of SIRI-CA messages (or a subset of their content) into a more concise format
suitable for such transmission if required.
8 Control Action Service [CA]
8.1 Description
The Control Action Service provides real time information about control actions performed by operators.
In most case this information is directly coming from the AVMS. It provides a purely operational view
where the Situation Exchange service provides a passenger information view, but both services are of
course related.
The Control Action Service comprises the ControlActionRequest message used to specify the contents of
request or subscription messages, and the ControlActionDelivery message used to deliver the response.
The ControlActionSubscription message allows a subscriber to request asynchronous updates for the
service: it contains an embedded ControlActionRequest, along with further parameters controlling the
asynchronous delivery.
ControlActionRequest offer simple parameters to filter the information by mode, operator, or network. A
line base filter is also available but is not expected to be widely used.
The ControlActionDelivery returns information about one or more CONTROL ACTIONs and their
associated status. CONTROL ACTIONs control actions are (subset of Transmodel CONTROL ACTIONs
selected to fulfil the identified use cases):
— JourneyCreation;
— JourneyCancellation;
— PartialJourneyCancellation;
— FlexibleJourneyActivation;
— ChangeOfJourneyPattern;
— ChangeOfJourneyTiming;
— ChangeOfStopPointStatus (dedicated to stop closing/opening, not (yet) directly available in
Transmodel) but will result in CHANGE OF JOURNEY PATTERN or PARTIAL JOURNEY
CANCELLATION);
— InterchangeCreation;
— InterchangeCancellation;
— InterchangeModification;
— VehicleWorkAssignment (or deassignment).
In addition, the ControlActionDelivery can provide the following additional information:
— GroupOfControlActions (convenient way to functionally group CONTROL ACTIONs);
— RevokedControlAction (to delete a previously notified CONTROL ACTIONs);
— DriverMessage (specialization of Transmodel OPERATIONAL MESSAGE limited to exchanges with
the driver);
— VehicleDetecting (detection of a vehicle by a specific device).
8.2 Reference Data
The ControlActionRequest requires the participants to have agreed data reference models for any
references that are used: LINEs, VEHICLE JOURNEYs, INTERCHANGEs and VEHICLEs, STOP PLACEs, etc.
Not all elements need to be used.
8.3 Capability and Permission Matrices
8.3.1 Capability Matrix
The following set of required and optional capabilities is defined for the Control Action service. If the
service supports Capability Discovery the ControlActionCapabilitiesRequest /
ControlActionCapabilitiesResponse message pair can be used to determine the implementation’s
capabilities.
Table 2 — ControlActionServiceCapabilities Matrix
ControlActionServiceCapabilities +Structure Capabilities describing implementation of
Situation Exchange service. (see this table)
inherit ::: 0:1 See See SIRI Part 2 for Common Capability
xxxCapability attributes.
Response
Topic TopicFiltering 0:1 +Structure Which optional filtering features are
supported? See next rows.
DefaultPreviewInterval 0:1 Positivedurat Default preview interval. Default is 60 min.
ionType
FilterByStartTime xsd:boolean Whether a start time other than now can be
specified for preview interval. Default is
'true'.
FilterByMode 0:1 xsd:boolean Whether results can be filtered by MODE.
Default is true. (+SIRI v2.0)
FilterByNetworkRef 0:1 xsd:boolean Whether results can be filtered by
NETWORK. Default is true
FilterByLineRef 0:1 xsd:boolean Whether results can be filtered by LINE and
or DIRECTION. Default is true
Request Policy RequestPolicy 0:1 +Structure Which features of RequestPolicy are
supported by service?
NationalLanguage 1:* xsd:language National languages used by service.
Translations 0:1 xsd:boolean Whether the producer supports
translations. SIRI 2.0
Default is false.
Coordinates choice Location coordinate system for results.
GmlCoordinateFormat 0:1 SrSNameTyp Use GML format
e
WgsDecimalDegrees 0:1 EmptyType Default coordinate data system is WGS 84
latitude and longitude.
HasDriverMessages 0:1 xsd:boolean Whether Maximum number of SITUATIONs
to returned can be specified,
HasVehicleDetectings 0:1 xsd:boolean Whether results can return Vehicle
Detectings. Default is 'false'.
HasMaximumControlActions 0:1 xsd:boolean Whether results can be limited to a
maximum number. Default is 'true'.
SubscriptionPol SubscriptionPolicy 0:1 +Structure Which features of SubscriptionPolicy are
icy supported by service? See next rows.
HasIncrementalUpdates 0:1 xsd:boolean Whether incremental updates can be
specified for updates Default is true.
HasChangeSensitivity 0:1 xsd:boolean Whether change threshold can be specified
for updates. Default is true.
Access Control AccessControl 0:1 +Structure Which optional Access Control features are
supported by service? See next rows.
RequestChecking 1:1 xsd:boolean Whether access control of requests is
supported. Default is false.
CheckOperatorRef 0:1 xsd:boolean If access control is supported, whether
access control by OPERATOR is supported.
Default is true.
CheckLineRef 0:1 xsd:boolean If access control is supported, whether
access control by LINE is supported. Default
is true.
CheckMonitoringRef 0:1 xsd:boolean If access control is supported, whether
access control by monitoring point
(LOGICAL DISPLAY) is supported. Default is
'true'.
Response ResponseFeatures 0:1 sequence Which features of Response data are
supported by service?
HasSituations 0:1 xsd:boolean Whether result supports SITUATION
REFERENCESs. Default is 'false'.
any Extensions 0:1 any Placeholder for user extensions.
8.3.2 Permission Matrix
If the implementation supports both Capability Discovery and Access Controls, then the
ControlActionCapabilitiesResponse response can include the access permissions for the requestor
participant to access data.
Table 3 — ControlAction Service Permissions
ControlActionPermission +Structure Permissions to use implementation of Situation
Exchange service.
Inherit ::: 1:1 xxxServicePer See SIRI Part 2 – 12.5 for Common Permission
missions elements.
Topic OperatorPermissions 0:1 +Structure Operator permissions for participant. See Part
2.
LinePermissions 0:1 +Structure LINE permissions for participant. See Part 2.
8.4 ControlActionRequest
8.4.1 ControlActionRequest Definition
The ControlActionRequest can be used in both a direct request, and for a subscription. If used for a
subscription, additional Subscription Policy parameters apply.
CONTROL ACTIONs can be filtered by OPERATOR (or OPERATIONAL UNIT), NETWORK an LINEs scope
or a combination of all.
Table 4 — ControlActionRequest Element
ControlActionRequest +Structure Request for information about facilities status
Attributes version 0:1 VersionString Version Identifier of Stop Monitoring Service, e.g. ‘1.0c’.
Timestamp RequestTim 1:1 xsd:dateTime See SIRI Part 2 Common properties of SIRI Functional
estamp Service Requests.
Contextualise MessageIde 0:1 MessageQualifier
dRequestEnd ntifier
pointGroup
TemporalSub PreviewInte 0:1 PositiveDurationTy Forward duration for which SITUATIONs should be
scriptionGrou rval pe included, that is, only SITUATIONs that start before the
p end of this window time will be included. Normally
used for subscriptions to keep a sliding window of
interest.
StartTime 0:1 xsd:dateTime Initial start time for PreviewInterval. If absent, then
current time is assumed. Shall be within data Horizon.
of system Only SITUATIONs or updates created after
this time will be sent. This enables a restart without
resending everything.
Topics OperatorRef 0:*
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...