CEN/TS 15531-4:2011

SLOVENSKI STANDARD
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
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

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.

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
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

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).
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.

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.
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
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.
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;
 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;
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.
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 derive a Facility Condition, or change of status to a previous condition.
5.4.6 CAPT#05 Workflow for verification, validation and editorial correction
A transport operator may want to validate and coordinate the information given out by its dissemination
systems as part of a workflow process. To do this a review process may be used to check all new messages,
especially those arriving automatically from other systems before marking them as ready for wider distribution.
Staff will use a facility management console to review current Facility Conditions. They may make additional
checks to verify the content, add additional structured content, and also make editorial corrections to improve
the human readable content. There may be different staff roles – for example data entry, data review assigned
to different users with different capabilities. In order to support this operation the Facility model must include
various status and quality attributes.
5.4.7 CAPT#06 Providing of collective guidance of passengers
One of the editorial functions for message management may be to add a Remedy – a course of alternative
action − to accompany the Facility Condition. They may also add a Situation that can include advice to
passengers as to the course to take to overcome the disruption caused by the Facility Condition. This may
include alternative routes, alternative travel times, etc.
5.4.8 CAPT#07 Audit trails, retrospectives and process views
The timely and accurate capture and circulation of information can be of great importance in crisis conditions
and it is desirable to keep an exact audit log of all changes made. This can be used both to record the
handling of the Facility Condition and to improve future processes. This can include time of capture, as well as
time of despatch. The Facility Condition structure should record such information.
5.5 Use Cases: Relating Facility Conditions to other SIRI services
5.5.1 General
The following Use Cases describe the correlation and association of Facility Conditions with the data content
of other systems, including the content of other SIRI functional services.
5.5.2 XREF#01 Problem affecting a specific vehicle journey
The Facility Condition may provide information about the available services on a specific dated vehicle
journey. Each of the SIRI services that reference a dated vehicle journey can associate a Facility Condition
reference with the journey element. This association may have been made manually, by choosing the journey
as part of the Facility Condition capture process, or inferred automatically, for example by noting that the
journey uses a network, line or station that is affected by a Facility Condition (see other XREF use cases).
This can be used by any information system with access to the relevant Facility Condition service to obtain the
Facility Condition description.
5.5.3 XREF#02 Problem at a stop place affecting some or all journeys for some or all modes
A Facility Condition at a stop place, such as full or partial closure of a lift, may affect access to transport, or
transfer between particular lines or modes at the stop place. The Facility Condition needs to be tagged with
identifiers that can be used to automatically collate it with the references to stop places used in other
information services. Once the relevance is established, the identifier of the Facility Condition can be
associated with the data of the other service to allow linking of data. It may be relevant to show Facility
Condition data in Stop departures (e.g. as part of the SIRI-SM results), on journey planner results and in
estimated Vehicle Journeys (e.g. in the SIRI-ET and VM results), and in travel news lists, localised by area or
mode or route (e.g. in the SIRI-SX results).
5.5.4 XREF#03 Problems affecting an interchange
Certain types of disruption affect not the whole stop place or interchange, but just the ability to transfer
between particular services. For example, transfer in rush hour between certain metro lines may be restricted
during building works within a tunnel. In this case the Facility Condition can be tagged with the details of the
specific connection links and or journey interchanges that are affected. Subsequently journeys and trips that
use the line section can be associated with the Facility Condition, as in use case XREF#02.
5.5.5 XREF#04 Problems affecting particular classes of users, e.g. impaired mobility
Certain types of disruption affect certain categories of passenger disproportionately. For example, lift failures
affect wheelchair users, and excessive crowding affects most mobility impaired users. A systematic tagging of
Facility Condition with the effect on accessibility is important.
5.6 Use Cases: Onwards Distribution to other systems (e.g. in TPEG & Datex2)
5.6.1 General
The following Use Cases describe the distribution of Facility Conditions to different types of dissemination
system.
5.6.2 DIST#01 Distribution of Facility Condition to displays
A Facility management system may send the Facility Condition it captures or in-station, at stop and onboard
displays of the transport operators own systems. In some cases the Facility Condition will be displayed as
additional notes and warnings accompanying other data, such as stop departures. In other cases relevant
Facility Conditions will be shown as a specific bulletin. Content on displays is typically highly filtered for a
particular context, for example a station or route, so the Facility Conditions will need to be tagged with precise
scope information (or be associated with other entities so tagged) so that they can to be distributed
automatically.
5.6.3 DIST#02 Distribution of Facility Condition to staff
A transport operator may want to inform their staff about Facility Conditions as they occur so that they are in a
position both to conduct operations and to inform passengers. Management may need to be informed of
certain types of Facility Condition as well.
5.6.4 DIST#03 Distribution of Facility Condition to external Systems
To disseminate facility conditions to external systems, such as for radio and TV broadcasting, personal alerts,
web sites, mobile phone service, or any other information system, Situations may be used. The situation can
include the facility condition reference along with structured content to explain the nature and effect of the
condition status.
5.6.5 DIST#04 Distribution of Facility Condition to journey planners
Journey planners can integrate Facility Condition data into their results, showing both planned and unplanned
Facility Condition that may affect a particular journey. In order to do this they need Facility Conditions to me
tagged with identifiers that can be related to specific journeys (or stops used by journeys). Connection Link
information and Interchange information are although useful. This allows users to check the status of facilities
at a station or fro a specific journey.
5.6.6 DIST#04 Distribution of Facility Condition for recording Facility Failures
A Facility Condition management system may send the Facility Conditions it aggregates to other systems that
hold a systematic historic log of the facility status. Such a historic record can be used for quality monitoring
and analysis purposes.
5.6.7 DIST#05 Distribution of Facility Condition to other systems
A Facility Condition management system may send the Facility Conditions it aggregates to systems (that is,
which also capture and originate Facility Conditions), as well as itself receiving them from other systems.
6 Modelling Facilities in SIRI
6.1 General
SIRI's Facility Monitoring Functional Service is designed to provide the specific details about the status of a
facility.
SIRI-FM uses a structured model for describing changes to the availability of facilities, designed to be suited
for any kind of facility. The representation includes structured elements to relate the facility to other transport
elements, such as stop point, network, vehicle journey, etc., following a Transmodel model. The detailed
description of facilities themselves, including all the related specific information (height of a stair, number of
level of a elevator, price of a commercial facility, etc.) is outside the scope of SIRI-FM, but can be referenced
using a Facility Identifier. See for example IFOPT for a model for many types of facility. The name space
scope of Facility Identifiers will normally be that of the Participant System.
The Facility Condition structure includes sufficient information about the facility to be used as a standalone
element in an information services.
6.2 Facility Model Overview
Figure 2 introduces the SIRI-FM facility condition model.
A FACILITY CONDITION describes a changed condition of a FACILITY.
 A FACILITY identifies the affected facility itself and its FACILITY LOCATION in terms of network
identifiers for the STOP, LINE, etc.
 An ACCESSIBILITY ASSESSEMENT describes the normal accessibility of the FACILITY.
 A MONITORING INFO describe show the facility is monitored and how often.
 A FACILITY STATUS to describe the nature of the change to availability of the facility and any effect upon
the ACCESSIBILITY ASSESSEMENT.
 A VALIDITY CONDITION may be used to specify the temporal duration of the condition.
 A REMEDY may be used to suggest alternative facilities.
Figure 2 — UML diagram for facilities − Summary
6.3 Facility Model Details
Figure 3 elaborates the SIRI-FM facility condition model and includes the definitions of the enumerations.
Figure 3 — UML diagram for facilities − Detailed model
6.4 Facility Model Elements
6.4.1 General
The status of a facility is modelled by a number of elements, as follows.
6.4.2 Facility Condition
A FacilityCondition represents the current status of a nominated Facility. It may contain a Situation
reference to link the current status of the facility to an external event ("the escalator is unavailable due to
weather conditions", etc.). A validity period can state the start time and estimated duration of the current
status. The Situation can be accessed through SIRI-SX or other Situation service such as TPEG.
6.4.3 Facility
Each FacilityCondition refers to a Facility, which describes the properties of the facility itself. This is a
generic description suitable for any facility, and not a detailed description of all the properties specific to a
particular type of facility. If such a structured description is needed a Facility Reference can be included to link
this description to an external Facility object.
The SIRI Facility has a description, and a facility type (fixed equipment, service, Personal device, reserved
area or onboard facility). It is further described by one or several features (a Ticket Machine can provide Local
Tickets and National Tickets).
6.4.4 Monitoring Info
The Monitoring Info element describes the method and circumstances of monitoring: manual/automatic,
frequency of measurement, etc. This can be used to indicate that, for example, an escalator status is checked
manually everyday at eight o'clock – with the implication that the status provided may not be the current
status, but the one measured at eight o'clock.
6.4.5 Facility Location
Each Facility can be associated with a Facility Location which can provide a location reference in terms of
both fixed and moving elements of the PT network:
a) Fixed:
1) A Stop Point (or Stop Area) (Transmodel);
2) A Line (Transmodel);
3) A Connection Link (Transmodel);
4) An Interchange (Transmodel);
5) Stop Place (IFOPT);
6) Stop Place Component (IFOPT):
i) Access Space (IFOPT);
ii) Quay (IFOPT);
iii) BoardingPosition (IFOPT);
iv) Path Link (IFOPT);
v) Entrance (IFOPT);
b) Moving:
1) a Vehicle (Transmodel);
2) a Vehicle Journey (Transmodel).
The referenced elements are components of the Transmodel model, including its IFOPT extensions for stop
places. More than one reference may be relevant at the same time.
6.4.6 Facility Status
The Facility Status describes the current status of the facility: This may be:
 Unknown;
 Available;
 Not Available;
 Partially available (for example: "available except for Wheel Chair", etc.);
 Added (it is a new facility, added temporarily or definitely);
 Removed (the facility has been removed, temporarily or definitely).
The effect upon accessibility is described by an AccessibilityAssessment see above.
6.4.7 Accessibility Assessment
Each Facility can have an AccessibilityAssessment, which describes the normal status of accessibility of
the facility for different categories of user need.
Each Facility Condition can state a change to the normal accessibility status, for different categories of user
need.
The AccessibilityAssessment can be stated in terms of either or both a Limitation, or of one or more
Suitability instances.
 A Limitation describes the status of an accessibility property of the infrastructure, e.g. liftFreeAccess.
 Suitability describes the suitability of a facility for use by some one with a specific User Need, e.g.
baggageEncumbrance.
A particular limitation may affect more than one User Need, and a User Need, may be affected by more than
one Limitation.
6.4.8 User Need
A user need can be any specific passenger need for accessibility: it may be a mobility restricted need (wheel
chair, no stairs, etc.), a need due to the use of a stroller or to the fact of being encumbered by luggage, etc.
6.4.9 Remedy
The Remedy describes suggested advice to passengers as to an alterative course of action when a
facility/service is no longer available.
6.4.10 Facility Feature
Facility features are used to classify facilities as having particular properties of interest to the travelling public,
for example, "suitable for Wheelchairs", "Ticket Machines", "Bike Carriage", etc.
This section refines and replaces the table shown in "3.3.13 ― Service Feature", in CEN/TS 15531-1:2007,
with the addition of the SIRI-FM facility types.
6.4.11 UML Diagrams of Facility Types
Table 1 — Some
...