Public transport - Service interface for real-time information relating to public transport operations - Part 4: Functional service interfaces: Facility Monitoring

This Technical Specification specifies an additional SIRI functional service to exchange information about changes to availability of Public Transport facilities between monitoring systems and servers containing realtime 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.

Öffentlicher Verkehr – Servicescnittstelle für Echtzeitinformation bezogen auf Operationen in öffentlichen Verkehr – Teil 4: Funktionale Dienst-Schnittstellen: Anlagenüberwachung

Transport Public - Service d'échanges de données temps réel pour le Transport en Commun - Partie 4: interfaces de service fonctionnel: Supervision des services et des équipements

Javni prevoz - Vmesnik za storitev informiranja v realnem času za potrebe delovanja javnega prevoza - 4. del: Vmesniki funkcijske storitve - Nadzorovanje storitev in opreme

Ta tehnična specifikacija določa dodatno funkcionalno storitev SIRI za izmenjavo informacij o spremembi razpoložljivosti storitev in opreme javnega prevoza med nadzornimi sistemi in strežniki, ki vsebujejo realnočasovne podatke o vozilu javnega prevoza ali času potovanja. Te vključujejo nadzorne centre prevoznikov in informacijske sisteme, ki zagotavljajo informacijske storitve za potniški promet.

General Information

Status
Withdrawn
Publication Date
15-Jun-2011
Withdrawal Date
04-Jan-2022
Technical Committee
Current Stage
9900 - Withdrawal (Adopted Project)
Start Date
04-Jan-2022
Due Date
27-Jan-2022
Completion Date
05-Jan-2022

Relations

Buy Standard

Technical specification
TS CEN/TS 15531-4:2011
English language
47 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)

SLOVENSKI STANDARD
SIST-TS CEN/TS 15531-4:2011
01-julij-2011
-DYQLSUHYR]9PHVQLN]DVWRULWHYLQIRUPLUDQMDYUHDOQHPþDVX]DSRWUHEH
GHORYDQMDMDYQHJDSUHYR]DGHO9PHVQLNLIXQNFLMVNHVWRULWYH1DG]RURYDQMH
VWRULWHYLQRSUHPH
Public transport - Service interface for real-time information relating to public transport
operations - Part 4: Functional service interfaces: Facility Monitoring
Transport Public - Service d'échanges de données temps réel pour le Transport en
Commun - Partie 4: interfaces de service fonctionnel: Supervision des services et des
équipements
Ta slovenski standard je istoveten z: CEN/TS 15531-4:2011
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
SIST-TS CEN/TS 15531-4:2011 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST-TS CEN/TS 15531-4:2011

---------------------- Page: 2 ----------------------

SIST-TS CEN/TS 15531-4:2011


TECHNICAL SPECIFICATION
CEN/TS 15531-4

SPÉCIFICATION TECHNIQUE

TECHNISCHE SPEZIFIKATION
May 2011
ICS 35.240.60
English Version
Public transport - Service interface for real-time information
relating to public transport operations - Part 4: Functional
service interfaces: Facility Monitoring
Transport Public - Service d'échanges de données temps
réel pour le Transport en Commun - Partie 4: interfaces de
service fonctionnel: Supervision des services et des
équipements
This Technical Specification (CEN/TS) was approved by CEN on 17 January 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-4:2011: E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------

SIST-TS CEN/TS 15531-4:2011
CEN/TS 15531-4:2011 (E)
Contents Page
Foreword .4
Introduction .6
1 Scope .7
2 Normative references .7
3 Terms and definitions .7
4 Symbols and abbreviations .8
5 Business Context.8
5.1 Overview of service function .8
5.2 Examples of Service Function . 10
5.3 Use Cases . 11
5.4 Use Cases: Capture & Origination of Facility Condition . 11
5.4.1 General . 11
5.4.2 CAPT#01 Facility Condition entered manually by operator staff . 11
5.4.3 CAPT#02 Facility Condition updated manually by operator staff . 11
5.4.4 CAPT#03 Facility Condition arising from automatic Facility Monitoring device (e.g. lift
failure) . 11
5.4.5 CAPT#04 Facility Condition being generated automatically from a situation . 12
5.4.6 CAPT#05 Workflow for verification, validation and editorial correction. 12
5.4.7 CAPT#06 Providing of collective guidance of passengers . 12
5.4.8 CAPT#07 Audit trails, retrospectives and process views . 12
5.5 Use Cases: Relating Facility Conditions to other SIRI services . 12
5.5.1 General . 12
5.5.2 XREF#01 Problem affecting a specific vehicle journey . 12
5.5.3 XREF#02 Problem at a stop place affecting some or all journeys for some or all modes . 12
5.5.4 XREF#03 Problems affecting an interchange . 13
5.5.5 XREF#04 Problems affecting particular classes of users, e.g. impaired mobility . 13
5.6 Use Cases: Onwards Distribution to other systems (e.g. in TPEG & Datex2) . 13
5.6.1 General . 13
5.6.2 DIST#01 Distribution of Facility Condition to displays . 13
5.6.3 DIST#02 Distribution of Facility Condition to staff . 13
5.6.4 DIST#03 Distribution of Facility Condition to external Systems . 13
5.6.5 DIST#04 Distribution of Facility Condition to journey planners . 13
5.6.6 DIST#04 Distribution of Facility Condition for recording Facility Failures . 14
5.6.7 DIST#05 Distribution of Facility Condition to other systems . 14
6 Modelling Facilities in SIRI . 14
6.1 General . 14
6.2 Facility Model Overview . 14
6.3 Facility Model Details . 15
6.4 Facility Model Elements . 16
6.4.1 General . 16
6.4.2 Facility Condition . 16
6.4.3 Facility . 17
6.4.4 Monitoring Info . 17
6.4.5 Facility Location. 17
6.4.6 Facility Status . 18
6.4.7 Accessibility Assessment . 18
6.4.8 User Need . 18
6.4.9 Remedy . 18
2

---------------------- Page: 4 ----------------------

SIST-TS CEN/TS 15531-4:2011
CEN/TS 15531-4:2011 (E)
6.4.10 Facility Feature . 18
6.4.11 UML Diagrams of Facility Types . 19
7 Communication Infrastructure . 27
7.1 General . 27
7.2 SIRI Service Request table . 27
7.3 Communications Bandwidth . 28
8 Facilities Monitoring Service [FM] . 28
8.1 Purpose . 28
8.2 UML Diagrams of Request & Response . 29
8.2.1 SIRI-FM Request − Summary . 29
8.2.2 SIRI-FM Request − Detail . 30
8.2.3 SIRI-FM Delivery − Summary . 30
8.2.4 SIRI-FM Delivery − Detail . 31
8.3 Reference Data . 32
8.4 Capability and Permission Matrices . 33
8.4.1 Capability Matrix . 33
8.4.2 Permission Matrix . 35
8.5 FacilityMonitoringRequest . 35
8.5.1 FacilityMonitoringRequest Definition . 35
8.5.2 FacilityMonitoringRequest Example . 37
8.6 FacilityMonitoringSubscriptionRequest . 37
8.6.1 FacilityMonitoringSubscriptionRequest Definition . 37
8.6.2 FacilityMonitoringSubscriptionRequest Example . 37
8.7 FacilityMonitoringDelivery. 38
8.7.1 General . 38
8.7.2 ServiceDelivery with a FacilityMonitoringDelivery . 38
8.7.3 FacilityMonitoringDelivery Element . 39
8.7.4 FacilityCondition Element . 39
8.7.5 FacilityMonitoringDelivery Example . 45
Bibliography . 47

3

---------------------- Page: 5 ----------------------

SIST-TS CEN/TS 15531-4:2011
CEN/TS 15531-4:2011 (E)
Foreword
This document (CEN/TS 15531-4: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 Facility Monitoring service, one of a modular set of services for the
exchange of Real-time information. The Facility Monitoring service (SIRI-FM) is concerned with the exchange
of information about alterations to the availability of facilities for passengers among systems, including
equipment monitoring, real-time management and dissemination systems.
The SIRI Facility Monitoring service (SIRI-FM) is an additional 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.
SIRI 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 (CEN/TS 15531-1);
b) the mechanisms to be adopted for data exchange communications links (CEN/TS 15531-2);
c) data structures for a series of individual application interface modules (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:
d) Facilities Management (SIRI-FM) (this document, CEN/TS 15531-4);
e) Situation Exchange (SIRI-SX): 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. Messages are assigned
validity periods in addition to the actual content (CEN/TS 15531-5).
4

---------------------- Page: 6 ----------------------

SIST-TS CEN/TS 15531-4:2011
CEN/TS 15531-4:2011 (E)
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-FM service is included in
version 1.3 of the schema onwards.
It is recognised that SIRI is not complete as it stands, and it is designed such that it can be extended over the
coming years. Further work is directed by a SIRI Management Group which exists at European level, based
on the composition of SG7.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this 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.

5

---------------------- Page: 7 ----------------------

SIST-TS CEN/TS 15531-4:2011
CEN/TS 15531-4:2011 (E)
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, 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.
The SIRI: Facility Monitoring (SIRI-FM) service defined in this document enables the exchange of
information on the current status of facilities. It provides a short description of the facility itself, the availability
status and specifically the impact of the availability status for various categories of disabled or incapacitated
people. The service provides all the current relevant information relating to all facilities fulfilling a set of
selection criteria. Both query and publish subscribe interactions are supported.
6

---------------------- Page: 8 ----------------------

SIST-TS CEN/TS 15531-4:2011
CEN/TS 15531-4:2011 (E)
1 Scope
This Technical Specification specifies an additional SIRI functional service to exchange information about
changes to availability of Public Transport facilities 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.
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.
For each term, it is indicated whether the term derives from TransModel (ENV 12896 version 5.0) and its
extension IFOPT (CEN/TS 28701:2010), or whether the term is specific to SIRI (CEN/TS 15531 (all parts)).
3.1
facility [SIRI]
equipment or service that provides a specific convenience or service to passengers
EXAMPLES Ticket machines, elevators, mechanical stairs, toilets, porterage, left luggage, etc.
NOTE A facility may be an equipment, a service, a personal device or a reserved area.
3.2
facility condition [SIRI]
particular mode of being of a facility; describing its state and availability
3.3
facility class [SIRI]
categorisation of the type of a facility
EXAMPLE Equipment, service, personal device or reserved area.
3.4
passenger accessibility assessment [IFOPT]
categorisation of the ACCESSIBILITY characteristics of a PASSENGER to indicate their requirements for
ACCESSIBILITY
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.5
user need [IFOPT]
ACCESSIBILITY requirement of a PASSENGER
7

---------------------- Page: 9 ----------------------

SIST-TS CEN/TS 15531-4:2011
CEN/TS 15531-4:2011 (E)
EXAMPLE That they are unable to navigate stairs, or lifts, or have visual or auditory impairments.
3.6
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.7
monitoring information [SIRI]
information describing the conditions and circumstances of monitoring: manual/automatic, frequency of
measurement, etc.
3.8
remedy [SIRI]
suggested alternative solution for passengers when a facility/service is no longer available.
4 Symbols and abbreviations
For the purposes of this document, the symbols and abbreviations given in CEN/TS 15531-1:2007 apply.
5 Business Context
NOTE This section is a complement to the Annex B "Business Context", in Part 1 of the SIRI document set,
prCEN/TS 00278181-1).
5.1 Overview of service function
The facility monitoring service allows the rapid real-time exchange of equipment status data.
Figure 1 provides an overview of the main use cases and data exchanges involved in using the SIRI Facility
Monitoring service.
8

---------------------- Page: 10 ----------------------

SIST-TS CEN/TS 15531-4:2011
CEN/TS 15531-4:2011 (E)

Figure 1 — Main use cases for facility monitoring
The status data needed for Facility Monitoring is provided by collecting the status of the facilities on the
network (top of the figure). This can be achieved either through manual data capture (an individual checks the
status of the facilities in situ, and reports them using a customised software interface), or using an automated
monitoring system with sensors to detect the equipment status. In both cases, the monitored data is sent to
the real-time data server through a SIRI service link. Monitored facilities can be any facility on the network
(mainly stop points, stop places, etc.), on connection links or on vehicles, for example:
 lifts;
 escalators;
 wheel chair access;
 passenger information devices;
9

---------------------- Page: 11 ----------------------

SIST-TS CEN/TS 15531-4:2011
CEN/TS 15531-4:2011 (E)
 ticket machine;
 boarding human assistance;
 etc. (see the Facility Feature table for a more detailed list).
When several providers are available, all the data flows are merged into a single real-time service. The
resulting real-time data set is then available to all downstream systems through a single SIRI-FM access
point. A large set of potential user systems can be considered:
a) passenger information displays;
b) system providing information for the staff (on board, on stations, on call centres, etc.);
c) passenger information system, possibly including a journey planner, and providing information through:
1) web access;
2) mobile phone access;
3) specific devices for mobility restricted people;
4) etc.
5.2 Examples of Service Function
Data from the Facility Monitoring service is useful for many different passenger information services. For
example:
a) the use of facility disruption information (for instance "lift broken affecting wheel chair access on a
connection link") in a journey planner. This has to be related to the time of the intended journey vis a vis
the start and stop time (or expected stop time) of the disruption. Some disruptions may be planned, other
may be unexpected and may occur and be monitored during the current operational day;
b) when facilities like Ticket offices are closed, online systems can provide information about the facilities
status on a map, on textual information, through RSS feeds, through web site access/ mobile phone
access, etc.;
c) facility conditions can be converted into a situation message and disseminated using a wide variety of
formats, for example, TPEG, and broadcast to any compliant device (i.e. informing on both road and
public transport situations);
d) provide information to the staff informing people of the availability of facilities:
1) inside a station, and on the related CONNECTION LINKs;
2) for a LINE;
3) for a whole network;
e) passengers with specific accessibility needs, because of disability, luggage, etc can check the availability
of facility:
1) at a STOP POINT;
2) on a VEHICLE;
3) on a VEHICLE JOURNEY;
10

---------------------- Page: 12 ----------------------

SIST-TS CEN/TS 15531-4:2011
CEN/TS 15531-4:2011 (E)
4) on a CONNECTION LINK;
f) real-time information about the status of facilities is also useful for operational purposes, for example:
1) to ask for repair when manual monitoring is performed;
2) to report the state of facilities when manual monitoring is performed;
3) to ask for the time when the facility will be available (repaired);
4) etc.
5.3 Use Cases
The following Use Cases illustrate functional cases for using the Facility Conditions service in PT information
systems and provide specific scenarios that the SIRI-FM service is intended to support. The purpose of the
Use Cases is to identify specific behaviour which requires corresponding support in the SIRI-FM Facility
Conditions model and protocol.
The Use Cases are organised under the following headings:
 Capture/Origination of Facility Conditions;
 Relating Facility Conditions to other SIRI services;
 Onwards distribution to other systems.
5.4 Use Cases: Capture & Origination of Facility Condition
5.4.1 General
The following Use Cases describe the capture and origination of Facility Condition data.
5.4.2 CAPT#01 Facility Condition entered manually by operator staff
Transport Operator staff may see or receive news of a change in the availability of a phone call, fax, email,
direct observation or from other systems. In some cases this may be known long in advance as part of a
planned schedule of engineering works, major event or other bulletin. Staff in a control room may enter the
description of the status into a facility management system using a capture terminal. Staff in the field may use
a mobile device. Data will be captured in a structured format including a status, time of origin, source, etc. The
operator may also direct the requirements for distribution of the data to other systems and to specific staff,
either directly by selecting their email phone or pager ids, or by the use of business rules that despatch to
particular channels according to the message content.
5.4.3 CAPT#02 Facility Condition updated manually by operator staff
Once in the system, the status of live facilities that are unavailable will continue to be monitored by control
staff. The staff will select the current Facility Condition and update its status.
5.4.4 CAPT#03 Facility Condition arising from automatic Facility Monitoring device (e.g. lift failure)
Other automated sources of Facility Conditions are equipment monitoring systems, which may give rise to
data about the availability of specific items of equipment such as lifts and escalators, or services, such as a
ticket office or accessibility assistance. The information may be tagged with location and equipment identifiers
allowing it to be associated with specific routes and journeys.
11

---------------------- Page: 13 ----------------------

SIST-TS CEN/TS 15531-4:2011
CEN/TS 15531-4:2011 (E)
5.4.5 CAPT#04 Facility Condition being generated automatically from a situation
In some cases a Condition data may be created automatically from a Situation message. A Situation can be
fed from an incident management system through a structured interface. Certain Situations may include
structured data that can be used to deriv
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.