CEN/TC 278/WG 3 - Public transport (PT)

This document is a profile of the CEN/TS 16614 series. It focuses on information relevant to feed the necessary accessibility passenger information services and excludes operational and fares information. It is based directly on EPIP (CEN/TS 16614-4).
This European Passenger Information Accessibility Profile (EPIAP) for NeTEx is for exchanging passenger information; it describes how to extend EPIP (the European Passenger Information Profile) with additional information (including a minimal set) to feed the necessary accessibility passenger information services in a European wide and multimodal context. EPIAP especially formulates a mandatory minimal implementation that needs to be filled in by everybody to deliver the necessary information for an assessment of the accessibility of site(s), vehicles and on vehicle-site interaction for impaired persons. The minimal level allows an assessment and contains the information to produce PRM TSI if necessary. It will also cover what the current legislation usually warrants. It then describes how additional information must be provided if an organisation decides to provide it (e.g. the information of the full DELFI+ standard in Germany).
EPIP does not reflect part 5 (New Modes) yet. However, EPIAP takes it into account. EPIP will have to be adapted accordingly.
For EPIAP to be of use, the EC needs to declare the minimal level of EPIAP as mandatory.

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.

Existing public and private distribution API specifications will be identified, where practicable, and summarised in a number of ways, including: ownership of specification, scope of API functionality, basis of data model and data categorisation used, management of reference data, commercial access rules to the specification, governance of the specification, existing examples of use for MaaS booking, coherence with existing CEN standards, potential for becoming a new CEN standard.

This part of the EN12896-X series (Transmodel-Part 10) takes into account the conceptual data model for the 'new modes' (vehicle pooling, vehicle sharing, taxis, vehicle rental) elaborated within CEN TS 17413 (Models and Definitions for New Modes) and is dedicated to be amended and re- published as a reference data model for the alternative modes of transport (Part 10 of the Public Transport Reference Data Model).
This new publication takes into account the revision of the conceptual model (published as CEN TS 17413) by the project team TC278 PT0303 working on the implementation of the 'new modes' model (NeTEx-Part5).
EN12896-10, supplementing the series of EN12896-X, establishes the semantic reference for the alternative modes data domain and thus facilitates the integration of these modes into the overall mobility environment, in particular into multimodal travel services (e.g. trip planning systems).

Service Interface for Real Time Information (SIRI) is a specification for an interface that allows systems running computer applications to exchange information about the planned, current or projected performance of the public transport operations.
The scope of this WI is to update CEN/EN 15531-2:2015 which allows pairs of server computers to exchange structured real-time information about schedules, vehicles, and connections, together with general informational messages related to the operation of the services. The information can be used for many different purposes, for example:
• To provide real time-departure from stop information for display on stops, internet and mobile delivery systems;
• To provide real-time progress information about individual vehicles;
• To manage the movement of buses roaming between areas covered by different servers;
• To manage the synchronisation of guaranteed connections between fetcher and feeder services;
• To exchange planned and real-time timetable updates;
• To distribute status messages about the operation of the services;
• To provide performance information to operational history and other management systems.
Implementations SIRI have revealed a number of improvements and some minor enhancements necessary for a successful and uniform usage of the specification in the future.
The main elements out of this work item will be:
o Prepare an updated edition of the TS as a document
o Update the common XSD of SIRI parts 1-5
The new work item will consider the projects of
o PT companies and IT-suppliers especially in Switzerland, Germany, France, Netherlands and Sweden
o Railway traffic
o accessibility in public transport

The SIRI Situation Exchange service (SIRI-SX) allows the efficient exchange of data about Situations caused by planned and unplanned incidents and events and is intended to support the use cases identified in Annex C. Situations are actual or potential perturbations to normal operation of a transport network. The SIRI-SX service uses the common SIRI communication framework and services which are described in EN 15531-1 and not repeated in this document.
The Situation Exchange service has a rich Situation model, allowing a structured description of all aspects of multimodal travel Situations, including cause, scope, effect and rules for distribution to an audience. The structured values enabling computer based distribution through a wide variety of channels, and the presentation of data in different formats for different device and different audiences. The Situation Exchange Service allows the exchange of incident and event information between, amongst others:
-   Control centres;
-   Operations Staff;
-   Public Information systems;
-   Alert systems and personalised alert systems;
-   UTMC systems;
-   Journey planners;
-   AVMS (Automatic Vehicle Management Systems).
SIRI-SX uses a network model based on the CEN Transmodel conceptual model for Public Transport networks, schedules and operations, along with the CEN Identification of Fixed Objects in Public Transport (IFOPT) model for describing physical transport interchanges that is an integrated part of CEN Transmodel conceptual model for Public Transport networks.
The Situation Exchange service is envisaged as a 'back office' capture and exchange service that will feed other public facing travel information dissemination systems in particular those using the TPEG format. Transport Protocol Expert Group (TPEG) is a European Broadcasting Union fostered standard for broadcasting travel data over Digital Assisted Broadcasting (DAB) radio and other channels. TPEG is maintained by the Traveller Information Services Association (TISA). To this end, the SIRI-SX situation classification model has been harmonized as far as possible with that of TPEG and DATEX2 so that full interoperability can be achieved. Uses of structured elements from TPEG, for which translations already exist in most European languages, also facilitates human readability in different national languages. Maintaining and improving a harmonization with TPEG will be a continuing objective. In addition to the TPEG exchangeable content, SIRI-SX messages contain additional structured information which allows them to be processed in additional ways.
Situation and computer systems and applications are typically distributed, that is information will be captured on one system and exchanged with others for dissemination and further processing. This means that a message design is needed that allows the management of the identity of distributed messages over time and across different systems, so that subsequent updates to a Situation can be reconciled by different systems over a network, and obsolete messages can be retired automatically. The SIRI-SX SITUATION model is designed to support the distributed management of Situations.

1.1   Interfaces specified by this document
1.1.1   Business Context
Real-time information may be exchanged between a number of different organisations, or between different systems belonging to the same organisation. Key interfaces include the following:
-   Between public transport vehicle control centres - generally, for fleet and network management.
-   Between a control centre and an information provision system - generally, to provide operational information for presentation to the public.
-   Between information provision systems - generally, sharing information to ensure that publicly available information is complete and comprehensive.
-   Between information provision systems - and data aggregation systems that collect and integrate data from many different sources and different types of data supplier and then distribute it onwards.
-   Between information provision systems and passenger information devices such as mobile phones, web browsers, etc.
Annex B describes the business context for SIRI in more detail.
SIRI is intended for wide scale, distributed deployment by a wide variety of installations. In such circumstances it is often not practical to upgrade all the systems at the same time. SIRI therefore includes a formal versioning system that allows for the concurrent operation of different levels at the same time and a disciplined upgrade process.
In this general framework, SIRI defines a specific set of concrete functional services. The services separate the communication protocols from the message content (‘functional services’). This allows the same functional content to be exchanged using different transport mechanisms, and different patterns of exchange. Figure 1 below shows this diagrammatically.
1.1.2   SIRI Communications
SIRI provides a coherent set of functional services for exchanging data for different aspects of PT operation. A common data model, based on Transmodel 6.0, is used across all services.
...

There are many potential ways for passenger transport operations centres to interact. The approach taken by SIRI is for an open-ended set of standard data structures, carried over a communications channel constructed using one of a small number of specific options.
Part 2 of this document specifies the communications channel. This Part 3 section specifies a number of functional modules, based on the ‘use cases’ identified in Annex B to Part 1:
-   Production Timetable (PT): this service enables the provision of information on the planned progress of vehicles operating a specific service, identified by the vehicle time of arrival and departure at specific stops on a planned route for a particular Operational Day.
-   Estimated Timetable (ET): this service enables the provision of information on the actual progress of Vehicle Journeys operating specific service lines, detailing expected arrival and departure times at specific stops on a planned route. There will be recorded data for stops which have been passed, and predicted data for stops not yet passed. In addition the Estimated Timetable service allows Vehicle Journeys to be cancelled, added or changed.
-   Stop Timetable (ST): this service provides a stop-centric view of timetabled vehicle arrivals and departures at a designated stop. It can be used to reduce the amount of information that needs to be transmitted in real-time to stops and displays, as reference data for a Stop Monitoring Service; and provides a data feed of the static timetables.
-   Stop Monitoring (SM): this service provides a stop-centric view of vehicle arrivals and departures at a designated stop. It can be used by displays and other presentation services to provide departure board and other presentations of timetable and real-time journey information both at stops and at a distance.
-   Vehicle Monitoring (VM): this service enables the provision of information on the current location and status of a set of vehicles. It provides all the current relevant information from one AVMS relating to all vehicles fulfilling a set of selection criteria.
-   Connection Timetable (CT): this service may be used to provide information about the scheduled arrivals of a feeder vehicle to the operator of a connecting distributor service. The distributor operator can then plan how to guarantee the connection, either with the expected vehicle or a different vehicle.
-   Connection Monitoring (CM): this service is used to provide information about the expected arrival of a feeder vehicle to the operator of a connecting distributor service. The distributor operator can then manage the service to guarantee the connection, based on actual vehicle running.
-   General Message (GM): the SIRI "General Message" service is used to exchange informative messages between identified individuals in free or an arbitrary structured format. It enables messages to be sent and to be revoked. Messages are assigned validity periods in addition to the actual content.

1.1   General
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information). It is based on Transmodel European reference model for PT data. The most recent version of NeTEx v1.1 is based on the most recent version of Transmodel, V6.0 (EN 12986 1/2/3/4/5/6), which now incorporates the prior IFOPT (EN 28701). NeTEx also relates to SIRI (CEN 15531-1/2/3/4) and supports the exchange of information of relevance for passenger information about public transport services and also for running Automated Vehicle Monitoring Systems (AVMS).
NOTE   NeTEx is an implementation of a subset of Transmodel (including IFOPT); the definitions and explanations of its concepts are extracted directly from Transmodel and reused in NeTEx, sometimes with adaptations in order to fit the NeTEx context. Although the data exchanges targeted by NeTEx Parts 1 to 5 are predominantly oriented towards provisioning passenger information systems, AVMS and fare systems with data from transit scheduling systems, it is not restricted to this purpose and NeTEx can also provide an effective solution to many other use cases for transport data exchange.
1.2    Alternative Modes Scope
This Part 5 of NeTEx is specifically concerned with the exchange of reference data to support “new” alternative modes for mobility services, adding certain new concepts to the NeTEx schema (indicated as NeTEx v1.2.2), but also to a high degree making use of existing schema elements defined in NeTEx Parts 1, 2 and 3.
The high-level design for alternative modes support is derived from a conceptual model for alternative modes CEN PT1711 (CEN/TS 17413:2020) prepared by CEN working group TC278 WG17. This CEN Technical Specification describes a conceptual model for alternative modes as an extension to Transmodel V6.0 and based on a detailed set of use cases taken from CEN PT1711 and given in Appendix A.
The NeTEx format is concerned with a subset of the use cases for reference data (real-time use cases are covered by dynamic protocols such as SIRI and DATEX II). Overall, it is concerned with data for the following purposes:
-   to be able to integrate legs made on alternative modes with conventional mode legs in seamless trip plans;
-   to describe the coverage areas of alternative mode mobility services so that trip planning engines and others can make passengers aware of the possibility of using them, and provide appropriate links to invoke the dynamic services;
-   to be able to find the locations of access points for alternative mode services, such as parking points, pooling stations, etc. including their relation to access points for conventional modes;
-   to be able to indicate the costs of the mobility services for specific trip legs. Where operators offer a bundle of modes services (for example free cycle use with metro use) to be able to include the “fare product” for alternative mode legs in the sales offer;
-   to be able to indicate how to book, purchase and pay for mobility services, and how to access them.
NeTEx is primarily concerned with the exchange of reference data to allow the integration of new modes with other data; it does not describe dynamic services. The PT1711 specification indicates the nature of some of these services such as trip planning.
1.3   Transport modes
All mass public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tramway, ferry, air, and their submodes. Such modes are provided by transport operators, who may operate one or more modes.
NeTEx part 5 widens the concept of an operator to include providers of other forms of transport, and introduces the separate concept of a “mode of operation” to classify the way services are provided: conventional, flexible, pooling, sharing, etc.
...

This document specifies an additional SIRI functional service to exchange information about changes to availability of 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. As for Transmodel, public transport modes include new modes of transport (vehicle sharing, vehicle pooling, etc.).
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.

This document gives guidelines for the development of multi-operator/multi-service interoperable public surface (including subways) transport fare management systems (IFMSs) on a national and international level.
This document is applicable to bodies in public transport and related services which agree that their systems need to interoperate.
This document defines a conceptual framework which is independent of organizational and physical implementation. Any reference within this document to organizational or physical implementation is purely informative.
This document defines a reference functional architecture for IFMSs and establishes the requirements that are relevant for ensuring interoperability between several actors in the context of the use of electronic tickets.
The IFMS includes all the functions involved in the fare management process, such as:
—     management of media,
—     management of applications,
—     management of products,
—     security management, and
—     certification, registration, and identification.
This document defines the following main elements:
—     identification of the different sets of functions in relation to the overall IFMS and services and media from non-transport systems which interact with fare management systems;
—     a generic model of an IFMS describing the logical and functional architecture and the interfaces within the system, with other IFMSs and with services and media from non-transport systems;
—     use cases describing the interactions and data flows between the different sets of functions;
—     security requirements.
In its annexes, this document provides a framework for mobility platforms that integrate fare management and travel information for inter- and multimodal travel (see Annex A). It also elaborates on specific subjects covered in document and offers some national examples with regard to IFMS implementations (see Annex B, Annex C, Annex D and Annex E).
This document does not define:
—     the technical aspects of the interface between the medium and the medium access device;
—     the data exchanges between the medium and the medium access device;
NOTE     The data exchanges between the medium and the medium access device are proposed by other standardization committees.
—     the financial aspects of fare management systems (e.g. customer payments, method of payment, settlement, apportionment, reconciliation).

1.1   General
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information) based on Transmodel V5.1 (EN 12986), IFOPT (CEN/TS 28701) and SIRI (CEN/TS 15531-4/5 and EN 15531-1/2/3 ) and supports information exchange of relevance to public transport services for passenger information and AVMS systems.
NOTE   Many NeTEx concepts are taken directly from Transmodel and IFOPT; the definitions and explanation of these concepts are extracted directly from the respective standards and reused in NeTEx, sometimes with further adaptions in order to fit the NETEx context.
The data exchanges targeted by NeTEx are predominantly oriented towards passenger information and also for data exchange between transit scheduling systems and AVMS (Automated Vehicle Monitoring Systems). However it is not restricted to these purposes, and NeTEx can provide an effective solution to many other use cases for transport exchange.
1.2   Transport modes
Most public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tram-way, ferry, and their submodes. It is possible to describe airports and air journeys, but there has not been any specific consideration of any additional provisions that apply especially to air transport.
1.3   Compatibility with existing standards and recommendations
The concepts covered in NeTEx that relate in particular to long-distance train travel include; rail operators and related organizations; stations and related equipment; journey coupling and journey parts; train com-position and facilities; planned passing times; timetable versions and validity conditions.
In the case of long distance train the NeTEx takes into account the requirements formulated by the ERA (European Rail Agency) – TAP/TSI (Telematics Applications for Passenger/ Technical Specification for Interoperability, entered into force on 13 May 2011 as the Commission Regulation (EU) No 454/2011), based on UIC directives.
As regards the other exchange protocols, a formal compatibility is ensured with TransXChange (UK), VDV 452 (Germany), NEPTUNE (France), UIC Leaflet, BISON (Netherland) and NOPTIS (Nordic Public Transport Interface Standard).
The data exchange is possible either through dedicated web services, through data file exchanges, or using the SIRI exchange protocol as described in part 2 of the SIRI documentation.

The CEN 13149 series of products concerns on-board data communication systems on public transport vehicles. This series provides for data services that enable open and managed sharing of relevant information.
This document, being Part 10 of the series, specifies a location publication, enabling all on-vehicle services to share a common understanding of the location and orientation of the vehicle, based on inputs taken from global navigational satellite systems (GNSS) such as GPS and Galileo. It covers:
-   the functional scope, i.e. which data the service provides, why, when and how often;
-   the transport protocol, i.e. how the data are transmitted;
-   the service publication, i.e. how the service can be found by other modules or applications;
-   the structure of the data, i.e. how the data are structured and how the data elements are named.
This document implements the service framework described in CEN/TS 13149 7.

The CEN 13149 series of products concerns on-board data communication systems on public transport vehicles. This series provides for data services that enable open and managed sharing of relevant information.
This document, being Part 9 of the series, specifies a time publication, enabling all on-vehicle services to share a common understanding of current time, based on a suitable agreed master network clock. It covers:
-   the functional scope, i.e. which data the service provides, why, when and how often.
-   the transport protocol, i.e. how the data are transmitted.
-   the service publication, i.e. how the service can be found by other modules or applications
-   the structure of the data, i.e. how the data are structured and how the data elements are named.
This document implements the service framework described in CEN/TS 13149-7.

The CEN 13149 series of products concerns on-board data communication systems on public transport vehicles. This series provides for data services that enable open and managed sharing of relevant information.
This document, being Part 11 of the series, specifies a publication service for data provided by the vehicle platform, enabling all on-vehicle services to share a common understanding of the operational activity of the vehicle, based on inputs taken from chassis systems such as the J1939 CAN bus. It covers:
-   the functional scope, i.e. which data the service provides, why, when and how often.
-   the transport protocol, i.e. how the data are transmitted.
-   the service publication, i.e. how the service can be found by other modules or applications
-   the structure of the data, i.e. how the data are structured and how the data elements are named.
This document implements the service framework described in CEN/TS 13149-7.

1.1   General
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information). It is based on Transmodel V6 (EN 12896 series) and SIRI (CEN/TS 15531-4/-5 and EN 15531-1/-2/-3) and supports the exchange of information of relevance for passenger information about public transport services and also for running Automated Vehicle Monitoring Systems (AVMS).
NOTE   Many NeTEx concepts are taken directly from Transmodel; the definitions and explanation of these concepts are extracted directly from the respective standard and reused in NeTEx, sometimes with adaptions in order to fit the NeTEx context.
Although the data exchanges targeted by NeTEx are predominantly oriented towards provisioning passenger information systems and AVMS with data from transit scheduling systems, it is not restricted to this purpose and NeTEx can also provide an effective solution to many other use cases for transport data exchange.
1.2   Transport modes
All mass public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tramway, ferry, and their submodes. It is possible to describe airports and air journeys, but there has not been any specific consideration of any additional requirements that apply specifically to air transport.
1.3   Compatibility with existing standards and recommendations
Concepts covered in NeTEx that relate in particular to long-distance train travel include; rail operators and related organizations; stations and related equipment; journey coupling and journey parts; train composition and facilities; planned passing times; timetable versions and validity conditions.
In the case of long distance train the NeTEx takes into account the requirements formulated by the ERA (European Rail Agency) - TAP/TSI (Telematics Applications for Passenger/ Technical Specification for Interoperability, entered into force on 13 May 2011 as the Commission Regulation (EU) No 454/2011), based on UIC directives.
As regards the other exchange protocols, a formal compatibility is ensured with TransXChange (UK), VDV 452 (Germany), NEPTUNE (France), UIC Leaflet, BISON (The Netherlands) and NOPTIS (Nordic Public Transport Interface Standard).
The data exchange is possible either through dedicated web services, through data file exchanges, or using the SIRI exchange protocol as described in part 2 of the SIRI documentation.

1.1   General
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information). It is based on Transmodel V5.1 (EN 12986), IFOPT (EN 28701) and SIRI (CEN/TS 15531-4/5 and EN 15531-1/2/3 ) and supports the exchange of information of relevance for passenger information about public transport services and also for running Automated Vehicle Monitoring Systems (AVMS).
NOTE   NeTEx is a refinement and an implementation of Transmodel and IFOPT; the definitions and explanations of these concepts are extracted directly from the respective standard and reused in NeTEx, sometimes with adaptations in order to fit the NeTEx context. Although the data exchanges targeted by NeTEx are predominantly oriented towards provisioning passenger information systems and AVMS with data from transit scheduling systems, it is not restricted to this purpose and NeTEx can also provide an effective solution to many other use cases for transport data exchange.
1.2   Fares scope
This Part3 of NeTEx, is specifically concerned with the exchange of fare structures and fare data, using data models that relate to the underlying network and timetable models defined in Part1 and Part2 and the Fare Collection data model defined in Transmodel V51. See the use cases below for the overall scope of Part3. In summary, it is concerned with data for the following purposes:
(i)   To describe the many various possible fare structures that arise in public transport (for example, flat fares, zonal fares, time dependent fares, distance-based fares, stage fares, pay as you go fares, season passes, etc., etc.).
(ii)   To describe the fare products that may be purchased having these fare structures and to describe the conditions that may attach to particular fares, for example if restricted to specific groups of users, or subject to temporal restrictions. These conditions may be complex.
(i)   To allow actual price data to be exchanged. Note however that NeTEx does not itself specify pricing algorithms or how fares should be calculated. This is the concern of Fare Management Systems. It may be used may be used to exchange various parameters required for pricing calculations that are needed to explain or justify a fare.
(iii)   To include the attributes and the text descriptions necessary to present fares and their conditions of sale and use to the public.
NeTEx should be regarded as being ‘upstream’ of retail systems and allows fare data to be managed and integrated with journey planning and network data in public facing information systems. It is complementary to and distinct from the ‘downstream’ ticketing and retail systems that sell fares and of the control systems that validate their use. See ‘Excluded Use Cases’ below for further information on the boundaries of NeTEx with Fare Management Systems.
1.3   Transport modes
All mass public transport modes are taken into account by NeTEx, including train, bus, coach, metro, tramway, ferry, and their submodes. It is possible to describe airports, air journeys, and air fares, but there has not been any specific consideration of any additional requirements that apply specifically to air transport.

This technical specification is a profile of CEN/TS 16614 series. It focuses on information relevant to feed passenger information services and excludes operational and fares information.
NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information) based on Transmodel V6 (EN 12986) and SIRI (CEN/TS 15531-4/5 and EN 15531-1/2/3) and supports information exchange of relevance to public transport services for passenger information and AVMS systems.
As for most data exchange standards, defining subsets of data and dedicated rules for some specific use case is of great help for implementers and for the overall interoperability. This subset is usually called profile and this profile targets passenger information as only use case.

1.1   General Scope of the Standard
The main objective of the present standard is to present the Reference Data Model for Public Transport, based on:
-   the Reference Data Model, EN 12896, known as Transmodel V5.1;
-   EN 28701:2012, Intelligent transport systems - Public transport - Identification of Fixed Objects in Public Transport (IFOPT), although note that this particular standard has been withdrawn as it is now included within Parts 1 and 2 of this standard (EN 12896-1:2016 and EN 12896-2:2016) following their successful publication;
incorporating the requirements of:
-   EN 15531-1 to -3 and CEN/TS 15531-4 and -5: Public transport - Service interface for real-time information relating to public transport operations (SIRI);
-   CEN/TS 16614-1 and -2: Public transport - Network and Timetable Exchange (NeTEx), in particular the specific needs for long distance train operation.
Particular attention is drawn to the data model structure and methodology:
-   the data model is described in a modular form in order to facilitate the understanding and the use of the model;
-   the data model is entirely described in UML.
The following functional domains are considered:
-   Network Description: routes, lines, journey patterns, timing patterns, service patterns, scheduled stop points and stop places;
-   Timing Information and Vehicle Scheduling (runtimes, vehicle journeys, day type-related vehicle schedules);
-   Passenger Information (planned and real-time);
-   Fare Management (fare structure, sales, validation, control);
-   Operations Monitoring and Control: operating day-related data, vehicle follow-up, control actions;
-   Driver Management:
-   Driver Scheduling (day-type related driver schedules),
-   Rostering (ordering of driver duties into sequences according to some chosen methods),
-   Driving Personnel Disposition (assignment of logical drivers to physical drivers and recording of driver performance);
-   Management Information and Statistics (including data dedicated to service performance indicators).
The data modules dedicated to cover most functions of the above domains will be specified.
Several concepts are shared by the different functional domains. This data domain is called "Common Concepts".
1.2   Functional Domain Description
The different functional domains (enumerated above) taken into account in the present document, and of which the data have been represented as the reference model, are described in EN 12896-1:2016, Public transport - Reference data model - Part 1: Common concepts.
1.3   Particular Scope of this Document
The present document entitled Public transport - Reference data model - Part 4: Operations monitoring and control incorporates the following data packages:
-   Dated Production Components MODEL;
-   Call MODEL;
-   Production Plan MODEL;
-   Detecting and Monitoring MODEL;
-   Control Action MODEL;
-   Event and Incident MODEL;
-   Messaging MODEL;
-   Situation MODEL; and
-   Facility Monitoring and Availability MODEL.
The data structures represented in this part form descriptions of data that are specific to operations for an operational day (as opposed to those planned for day types). They reference to structures as described in EN 12896-1:2016, such as version frames or generic grouping mechanisms, but also to EN 12896-2:2016 and EN 12896-3:2016.
This document itself is composed of the following parts:
-   Main document (normative) presenting the data model for the domain Operations Monitoring and Control;
-   Annex A (normative), containing the data dictionary, i.e. the list of all the concepts and attribute tables present in the main document together with the definitions;
-   Annex B (normative), providing a complement to EN 12896-1:2016, particularly useful for parts 4 to 8 of the Public Transport Reference Data Model;
-   Annex C (informative), indicating the data model evolutions; and
(...)

1.1   General Scope of the Standard
The main objective of the present standard is to present the Reference Data Model for Public Transport, based on:
-   the Reference Data Model, EN 12896, known as Transmodel V5.1;
-   EN 28701:2012, Intelligent transport systems - Public transport - Identification of Fixed Objects in Public Transport (IFOPT), although note that this particular standard has been withdrawn as it is now included within Parts 1 and 2 of this European Standard (EN 12896-1:2016 and EN 12896-2:2016) following their successful publication;
incorporating the requirements of:
-   EN 15531-1 to -3 and CEN/TS 15531-4 and -5: Public transport - Service interface for real-time information relating to public transport operations (SIRI);
-   CEN/TS 16614-1 and -2: Public transport - Network and Timetable Exchange (NeTEx), in particular the specific needs for long distance train operation.
Particular attention is drawn to the data model structure and methodology:
-   the data model is described in a modular form in order to facilitate the understanding and the use of the model;
-   the data model is entirely described in UML.
The following functional domains are considered:
-   Network Description: routes, lines, journey patterns, timing patterns, service patterns, scheduled stop points and stop places;
-   Timing Information and Vehicle Scheduling (runtimes, vehicle journeys, day type-related vehicle schedules);
-   Passenger Information (planned and real-time);
-   Fare Management (fare structure, sales, validation, control);
-   Operations Monitoring and Control: operating day-related data, vehicle follow-up, control actions;
-   Driver Management:
-   Driver Scheduling (day-type related driver schedules),
-   Rostering (ordering of driver duties into sequences according to some chosen methods),
-   Driving Personnel Disposition (assignment of logical drivers to physical drivers and recording of driver performance);
-   Management Information and Statistics (including data dedicated to service performance indicators).
The data modules dedicated to cover most functions of the above domains will be specified.
Several concepts are shared by the different functional domains. This data domain is called "Common Concepts".
1.2   Functional Domain Description
The different functional domains (enumerated above) taken into account in the present document, and of which the data have been represented as the reference model, are described in EN 12896-1, Public transport - Reference data model - Part 1: Common concepts.
1.3   Particular Scope of this Document
The present document entitled Public transport - Reference data model - Part 7: Driver management incorporates the following data packages:
-   Driver Scheduling;
   Rostering;
-   Personnel Disposition;
-   Driver Control Actions.
This document itself is composed of the following parts:
-   Main document (normative) presenting the data model for the concepts shared by the different domains covered by Transmodel,
-   Annex A (normative), containing the data dictionary, i.e. the list of all the concepts and attribute tables present in the main document together with the definitions,
-   Annex B (normative), providing a complement to EN 12896-1:2016, particularly useful for Parts 4 to 8 of the Public Transport Reference Data Model; and
-   Annex C (informative), indicating the data model evolutions.

1.1   General Scope of the Standard
The main objective of the present standard is to present the Reference Data Model for Public Transport, based on:
-   the Reference Data Model, EN 12896, known as Transmodel V5.1;
-   EN 28701:2012, Intelligent transport systems - Public transport - Identification of Fixed Objects in Public Transport (IFOPT), although note that this particular standard has been withdrawn as it is now included within Parts 1 and 2 of this standard (EN 12896-1:2016 and EN 12896-2:2016) following their successful publication.
incorporating the requirements of:
-   EN 15531-1 to -3 and CEN/TS 15531-4 and -5: Public transport - Service interface for real-time information relating to public transport operations (SIRI);
-   CEN/TS 16614-1 and -2: Public transport - Network and Timetable Exchange (NeTEx), in particular the specific needs for long distance train operation.
Particular attention is drawn to the data model structure and methodology:
-   the data model is described in a modular form in order to facilitate the understanding and the use of the model;
-   the data model is entirely described in UML.
The following functional domains are considered:
-   Network Description: routes, lines, journey patterns, timing patterns, service patterns, scheduled stop points and stop places;
-   Timing Information and Vehicle Scheduling (runtimes, vehicle journeys, day type-related vehicle schedules);
-   Passenger Information (planned and real-time);
-   Fare Management (fare structure, sales, validation, control);
-   Operations Monitoring and Control: operating day-related data, vehicle follow-up, control actions;
-   Driver Management:
-   Driver Scheduling (day-type related driver schedules),
-   Rostering (ordering of driver duties into sequences according to some chosen methods),
-   Driving Personnel Disposition (assignment of logical drivers to physical drivers and recording of driver performance);
-   Management Information and Statistics (including data dedicated to service performance indicators).
The data modules dedicated to cover most functions of the above domains will be specified.
Several concepts are shared by the different functional domains. This data domain is called "Common Concepts".
1.2   Functional Domain Description
The different functional domains (enumerated above) taken into account in the present standard, and of which the data have been represented as the reference model, are described in EN 12896-1:2016, Public transport - Reference data model - Part 1: Common concepts.
1.3   Particular Scope of this Document
The present document entitled Public transport - Reference data model - Part 5: Fare Management addresses Fare Information for Public Transport and incorporates the following data packages:
-   Fare Structure;
-   Access Right Assignment;
-   Fare Pricing;
-   Sales Description;
-   Sales Transaction;
-   Fare Roles;
-   Validation and Control;
-   Explicit Frames for Fares.
This document itself is composed of the following parts:
-   Main document (normative) representing the data model for the concepts shared by the different fare domains covered by Transmodel,
-   Annex A (normative), containing the data dictionary, i.e. the list of all the concepts and attribute tables present in the main document together with the definitions,
-   Annex B (normative), providing a complement to the "Common Concepts" domain, particularly useful for parts 4 to 8 of the Public Transport Reference Data Model,
Annex C (informative), indicating the data model evolutions from previous versions of Transmodel (EN 12896:2006).

1.1   General Scope of the Standard
The main objective of the present standard is to present the Reference Data Model for Public Transport, based on:
-   the Reference Data Model, EN 12896, known as Transmodel V5.1;
-   EN 28701:2012, Intelligent transport systems - Public transport - Identification of Fixed Objects in Public Transport (IFOPT), although note that this particular standard has been withdrawn as it is now included within Parts 1 and 2 of this standard (EN 12896 1:2016 and EN 12896 2:2016) following their successful publication;
incorporating the requirements of:
-   EN 15531-1 to −3 and CEN/TS 15531-4 and −5: Public transport - Service interface for real-time information relating to public transport operations (SIRI);
-   CEN/TS 16614-1 and -2: Network and Timetable Exchange (NeTEx), in particular the specific needs for long distance train operation.
Particular attention is drawn to the data model structure and methodology:
-   the data model is described in a modular form in order to facilitate the understanding and the use of the model;
-   the data model is entirely described in UML.
The following functional domains are considered:
-   Network Description: routes, lines, journey patterns, timing patterns, service patterns, scheduled stop points and stop places;
-   Timing Information and Vehicle Scheduling (runtimes, vehicle journeys, day type-related vehicle schedules);
-   Passenger Information (planned and real-time);
-   Fare Management (fare structure, sales, validation, control);
-   Operations Monitoring and Control: operating day-related data, vehicle follow-up, control actions;
-   Driver Management:
-   Driver Scheduling (day-type related driver schedules),
-   Rostering (ordering of driver duties into sequences according to some chosen methods),
-   Driving Personnel Disposition (assignment of logical drivers to physical drivers and recording of driver performance);
-   Management Information and Statistics (including data dedicated to service performance indicators).
The data modules dedicated to cover most functions of the above domains will be specified.
Several concepts are shared by the different functional domains. This data domain is called "Common Concepts".
1.2   Functional Domain Description
The different functional domains (enumerated above) taken into account in the present document, and of which the data have been represented as the reference model, are described in EN 12896-1:2016, Public transport - Reference data model - Part 1: Common Concepts.
1.3   Particular Scope of this Document
The present document entitled Public transport - Reference data model - Part 8: Management information & statistics describes how to structure data which refers to the planning stages (e.g. timetables, run times, driver rosters, etc.) and/or to the daily actual production, and which is registered for different purposes, in particular to build service performance indicators. The data model is based on a generic design pattern, Generic Loggable Objects Model (provided in the Additional Common Concepts part -  Annex B), and incorporates the following data packages:
-   Logging Time and Place, providing additions to the Generic Loggable Objects Model,
-   Recorded Objects,
-   Recorded Use of Services,
-   Service Journey Performance.
The last three packages show how the recorded data contributes to the implementation of indicators.
This document itself is composed of the following parts:
-   Main document (normative),
-   Annex A (normative), containing the data dictionary, i.e. the list of all the concepts and attribute tables present in the main document together with the definitions,
-   Annex B (normative), providing a complement to EN 12896-1:2016, particularly useful for Parts 4 to 8 of the Public Transport Reference Data Model;
-   Annex C (informative), indicating the data model evolution from the previous version.

1.1   General Scope of the Standard
The main objective of the present standard is to present the Reference Data Model for Public Transport, based on:
-   the Reference Data Model, EN 12896, known as Transmodel V5.1;
-   EN 28701:2012, Intelligent transport systems -) Public transport - Identification of Fixed Objects in Public Transport (IFOPT), although note that this particular standard has been withdrawn as it is now included within Parts 1 and 2 of this standard (EN 12896-1:2016 and EN 12896-2:2016) following their successful publication,
incorporating the requirements of:
-   EN 15531-1 to -3 and CEN/TS 15531-4 and -5: Public transport – Service interface for real-time information relating to public transport operations (SIRI);
-   CEN/TS 16614-1 and -2: Public transport - Network and Timetable Exchange (NeTEx), in particular the specific needs for long distance train operation.
Particular attention is drawn to the data model structure and methodology:
-   the data model is described in a modular form in order to facilitate the understanding and the use of the model;
-   the data model is entirely described in UML.
The following functional domains are considered:
-   Network Description: routes, lines, journey patterns, timing patterns, service patterns, scheduled stop points and stop places;
-   Timing Information and Vehicle Scheduling (runtimes, vehicle journeys, day type-related vehicle schedules);
-   Passenger Information (planned and real-time);
-   Fare Management (fare structure, sales, validation, control);
   Operations Monitoring and Control: operating day-related data, vehicle follow-up, control actions;
-   Driver Management:
-   Driver Scheduling (day-type related driver schedules),
-   Rostering (ordering of driver duties into sequences according to some chosen methods),
-   Driving Personnel Disposition (assignment of logical drivers to physical drivers and recording of driver performance);
-   Management Information and Statistics (including data dedicated to service performance indicators).
The data modules dedicated to cover most functions of the above domains will be specified.
Several concepts are shared by the different functional domains. This data domain is called "Common Concepts".
1.2   Functional Domain Description
The different functional domains (enumerated above) taken into account in the present standard, and of which the data have been represented as the reference model, are described in EN 12896-1:2016, Public transport - Reference data model - Part 1: Common concepts.
1.3   Particular Scope of this Document
The present document entitled Public transport - Reference data model - Part 6: Passenger information, incorporates the following main data packages:
-   Trip Description;
-   Passenger Queries.
This document itself is composed of the following parts:
-   Main document (normative) representing the data model for the concepts shared by the different fare domains covered by Transmodel;
-   Annex A (normative), containing the data dictionary, i.e. the list of all the concepts and attribute tables present in the main document together with the definitions;
-   Annex B (normative), providing a complement to EN 12896-1:2016, particularly useful for parts 4 to 8 of the Public Transport Reference Data Model;
-   Annex C (informative), indicating the data model evolutions;
-   Annex D (informative), indicating the high-level equivalences of the example passenger information functional requests to the capabilities of other standards;
-   Annex E (informative), providing an example set of commonly found passenger information functional requests and data dictionary for the elements used in the examples.

This document specifies the general rules for an on-board data communication system between the different systems that may be used within public transport vehicles, based on the Internet Protocol (IPv4, [3] and IPv6, [4]). This includes operational support systems, passenger information systems, fare collection systems, etc.
This document describes:
-   the requirements for an on board IP network;
-   the overview architecture and components for an IP based on-board network;
-   the modular structure of the network architecture;
-   the Service Oriented Architecture (SOA) approach, and approach to defining services.
Systems directly related to the safe operation of the vehicle (including propulsion management, brake systems, door opening systems) are excluded from the scope of this document and are dealt with in other standardization bodies. However, the architecture described in this document may be used for support services such as safety information messages. Interfaces to safety-critical systems should be provided through dedicated gateways with appropriate security provisions; for the purposes of this document, these are regarded as simply external information sources.
This document is designed primarily for vehicles with a fixed primary structure, where networks can be installed on a permanent basis and the system configuration task consists largely of the integration, adjustment or removal of the functional end systems that produce and/or consume data. Public transport vehicles consisting of units linked temporarily for operational purposes (specifically, trains in which individual engines, cars or consists are routinely connected and disconnected) require additional mechanisms to enable the communications network itself to reconfigure. Such mechanisms are provided through other standards, notably the IEC 61375 series [5].

This document constitutes the 3rd edition of CEN/TS 16794-1. It sets out the technical requirements to be met by contactless Public Transport (PT) devices in order to be able to interface together using the ISO/IEC 14443 series contactless communications protocol.
This document applies to PT devices:
-   PT readers which are contactless fare management system terminals acting as a PCD contactless reader based on the ISO/IEC 14443 series;
-   PT objects which are contactless fare media acting as a PICC contactless object based on the ISO/IEC 14443 series.
This edition addresses interoperability of consumer-market NFC mobile devices, compliant to NFC Forum specifications, with above mentioned PT devices, aligns with the 4th edition of the ISO/IEC 14443 series and maintains the possibility for PT readers to comply with the requirements from EMV Contactless Interface Specification [1] and the present document.
An interface–oriented test approach is used to evaluate the conformity of PT devices and is defined in CEN/TS 16794-2.
Application-to-application exchanges executed once contactless communication has been established at RF level fall outside the scope of this document. In line with the rules on independence between OSI protocol layers, this document works on the assumption that application-to-application exchanges are not contingent on the type of contactless communication established or the parameters used for the low-level protocol layers that serve as the platform for these application-to-application exchanges.

This document comes as a complement to the technical requirements expressed in CEN/TS 16794 1, for ensuring contactless communication interoperability between Public Transport (PT) devices or between PT devices compliant to CEN/TS 16794-1 and NFC mobiles devices compliant to NFC Forum specifications.
This document lists all the test conditions to be performed on a PT reader or a PT object in order to ensure that all the requirements specified in CEN/TS 16794 1 are met for the PT device under test.
This document applies to PT devices only:
-   PT readers which are contactless fare management system terminals acting as a PCD contactless reader based on the ISO/IEC 14443 series;
-   PT objects which are contactless fare media acting as a PICC contactless object based on the ISO/IEC 14443 series.
This document applies solely to the contactless communication layers described in Parts 1 to 4 of the ISO/IEC 14443 series. Application-to-application exchanges executed once contactless communication has been established at RF level fall outside the scope of this document. However, a test application will be used so as to make end-to-end transactions during tests on the RF communication layer.
This document does not duplicate the contents of the ISO/IEC 14443 series or ISO/IEC DIS 10373-6 standard. It makes reference to the ISO/IEC DIS 10373 6 applicable test methods, specifies the test conditions to be used and describes the additional specific test conditions that may be run.
The list of test conditions applicable to the PT device under test will be conditioned by the Information Conformance Statement (ICS) declaration made by the device manufacturer. For each test case, the test conditions are clearly specified in order to determine the pertinence to run or not the test case in accordance with the device capabilities or in accordance with the device manufacturer’s choice.
In order to facilitate the test report issuance, a test report template is included in Annex A of this document.
Although this document aims at becoming the primary basis for certification of contactless communication protocol applicable to PT readers and PT objects, it does not describe any certification or qualification processes as such processes should be defined between local or global transit industry stakeholders.

A Technical Report with informative and didactical material to users.

2.1 Introduction
The OpRa work scope is the definition of a minimum set of Public Transport raw data needed as PT quantitative analysis enabling factor. To obtain this considering all the several aspects involved in this complex domain, the work has been conducted through the following phases:
1) assessment;
2) use cases definition and classification;
3) indicators definition;
4) raw data identification.
OpRa work does not go into the field of service quality measurement and reporting: service quality analysis will of course use data provided by OpRa, but quality definition remains a contractual level issue between a Public Transport Authority and a Public Transport Operator or an operator’s internal choice for a purely private service. OpRa mainly only reports unbiased actual data (i.e. measured or observed), described and aggregated in a shared and understandable way.
The OpRa work documented in detail in this document is coherent with EU Directive 2010/40. In particular, it relates to the Article 4 of the Delegated Regulation EU 2017/1926, as regards the historic data. OpRa proposes to complement NeTEx (dedicated to the static scheduled information), for the historic data based on the underlying conceptual data reference model Transmodel EN 12896, similarly to the requirement of the Delegated Regulation EU 2017/1926 referring to the static scheduled information. (...)

The intention of this document is to review what was done to envision the limits of the proposed technique and related schemes which will be described and to define what could be submitted to standards. Concepts which are to be used for BLE in IFM are based on a highly spread technology which is BLE. This is not limited to any trademark or proprietary scheme. Therefore any person having a smartphone can use this technology with prerequisite to have a Bluetooth version greater than 4.0 and a dedicated application on board the smartphone.
The background of this document is related to usage in Account Based Ticketing frame (see related document made in ISO/TC 204/WG 8). There is no information related to the IFM itself.

1.1   General Scope of the Standard
The main objective of the present standard is to present the Reference Data Model for Public Transport, based on:
-   the Reference Data Model, EN12896, known as Transmodel V5.1,
-   CEN EN 28701, known as IFOPT,
incorporating the requirements  of
-   EN 15531-1 to -3 and TS 15531-4 and -5: Service interface for real-time information relating to public transport operations (SIRI),
-   TS 16614-1 and 2: Network and Timetable Exchange (NeTEx), in particular,  the specific needs for long distance train operation.
A particular attention is drawn to the data model structure and methodology:
-   the data model is described in a modular form in order to facilitate the understanding and the use of the model,
-   the data model is entirely described in UML.
In particular, a Reference Data Model kernel is described, referring to the data domain:
-   Network Description: routes, lines, journey patterns, timing patterns, service patterns, scheduled stop points and stop places.
This part corresponds to the Transmodel V5.1 Network Description extended by the IFOPT relevant parts.
Furthermore, the following functional domains are considered:
-   Timing Information and Vehicle Scheduling  (runtimes, vehicle journeys, day type-related vehicle schedules)  
-   Passenger Information (planned and real-time)
-   Fare Management (fare structure, sales, validation, control)
-   Operations Monitoring and Control: operating day-related data, vehicle follow-up , control actions
-   Management Information and Statistics (including data dedicated to service performance indicators).
-   Driver Management:
-   Driver Scheduling (day-type related driver schedules),
-   Rostering (ordering of driver duties into sequences according to some chosen methods),
-   Driving Personnel Disposition (assignment of logical drivers to physical drivers and recording of driver performance).  
The data modules dedicated to cover most functions of the above domains will be specified.
Several concepts are shared by the different functional domains. This data domain is called “Common Concepts”.
1.2   Functional Domain Description
The different functional domains taken into account in the present standard and of which the data have been represented as the reference data model are described in “Public Transport Reference Data Model - Part 1: Common Concepts”.
They are:
-   Public Transport Network and Stop Description
-   Timing Information and Vehicle scheduling
-   Passenger information
-   Fare Management
-   Operations monitoring and control
-   Management information
-   Personnel Management: Driver Scheduling, Rostering, Personnel Disposition.
The aspects of multi-modal operation and multiple operators’ environment are also taken into account.
1.3   Particular Scope of this Document
The present European Standard entitled “Reference Data Model for Public Transport – Part 3: Timing Information and Vehicle Scheduling”. incorporates
-   Journey and Journey Times Model: describes the time-related information at the level of vehicle journeys, i.e. planned timing for the vehicles at day-type level.
-   Dated Journey Model: describes the link of the timing information for a single operating day and the day type related timing,
-   Passing Times Model: describes all the different types of passing times for the day type related information,
-   Vehicle Service Model: describes the information related the work of vehicles as planned for days types. It constitutes the main part of the Vehicle Scheduling Data Domain.
-   Vehicle Journey Assignment Model: describes operational assignments (advertised vehicle labels, stopping positions) related to particular vehicle journeys.
This document itself is composed of the following parts:
-   Main document (normative) representing the data model,
(...)

1.1   General scope of the Standard
The main objective of the present Standard is to present the public transport reference data model based on:
-   the public transport reference data model published 2006 as EN 12896 and known as Transmodel V5.1;
-   the model for the Identification of Fixed Objects for Public transport, published 2009 as EN 28701and known as IFOPT;
incorporating the requirements of
-   EN 15531-1 to 3 and CEN/TS 15531-4 and CEN/TS 15531-5, Service interface for real-time information relating to public transport operations (SIRI);
-   CEN/TS 16614-1 and CEN/TS 16614-2, Network and Timetable Exchange (NeTEx);
in particular the specific needs for long distance train operation.
Particular attention is drawn to the data model structure and methodology:
-   the data model is described in a modular form in order to facilitate understanding and use of the model;
-   the data model is entirely described in UML.
In particular, a reference data model kernel is described, referring to the data domain:
-   network description: routes, lines, journey patterns, timing patterns, service patterns, scheduled stop points and stop places.
-   This part corresponds to the network description as in Transmodel V5.1 extended by the relevant parts of IFOPT.
-   Furthermore, the following functional domains are considered:
-   timing information and vehicle scheduling  (runtimes, vehicle journeys, day type-related vehicle schedules);
-   passenger information (planned and real-time);
-   operations monitoring and control: operating day-related data, vehicle follow-up, control actions;
-   fare management (fare structure and access rights definition, sales, validation, control);
-   management information and statistics (including data dedicated to service performance indicators);
-   driver management:
-   driver scheduling (day-type related driver schedules);
-   rostering (ordering of driver duties into sequences according to some chosen methods);
-   driving personnel disposition (assignment of logical drivers to physical drivers and recording of driver performance).
The data modules dedicated to cover most functions of the above domains will be specified. Several concepts are shared by the different functional domains. This data domain is called “common concepts”.
1.2   Functional domain description
The different functional domains taken into account in the present Standard and of which the data have been represented as the reference data model are described in “Public transport reference data model - Part 1: Common concepts”.
They are:
-   public transport network and stop description;
-   timing information and vehicle scheduling;
-   passenger information;
-   fare management;
-   operations monitoring and control;
-   management information;
-   personnel management: driver scheduling, rostering, personnel disposition.
The aspects of multi-modal operation and multiple operators’ environment are also taken into account.
(...)

1.1   General scope of the Standard
The main objective of this European Standard is to present the Public Transport Reference Data Model based on:
-   the Public Transport Reference Data Model published 2006 as EN12896 and known as Transmodel V5.1,
-   the model for the Identification of Fixed Objects for Public transport, published 2009 as EN 28701and known as IFOPT,
incorporating the requirements  of
-   EN15531-1 to 3 and TS15531-4 and 5: Service interface for real-time information relating to public transport operations (SIRI),
-   TS16614-1 and 2: Network and Timetable Exchange (NeTEx),
in particular the specific needs for long distance train operation.
Particular attention is drawn to the data model structure and methodology:
-   the data model is described in a modular form in order to facilitate understanding and use of the model,
-   the data model is entirely described in UML.
In particular, a Reference Data Model kernel is described, referring to the data domain:
-   Network Description: routes, lines, journey patterns, timing patterns, service patterns, scheduled stop points and stop places.
This part corresponds to the network description as in Transmodel V5.1 extended by the relevant parts of IFOPT.
Furthermore, the following functional domains are considered:
-   Timing Information and Vehicle Scheduling (runtimes, vehicle journeys, day type-related vehicle schedules)
-   Passenger Information (planned and real-time)
-   Operations Monitoring and Control: operating day-related data, vehicle follow-up , control actions
-   Fare Management (fare structure and access rights definition, sales, validation, control)
-   Management Information and Statistics (including data dedicated to service performance indicators).
-   Driver Management:
-   Driver Scheduling (day-type related driver schedules),
-   Rostering (ordering of driver duties into sequences according to some chosen methods),
-   Driving Personnel Disposition (assignment of logical drivers to physical drivers and recording of driver performance).
The data modules dedicated to cover most functions of the above domains will be specified. Several concepts are shared by the different functional domains. This data domain is called “Common Concepts”.
1.2   Functional domain description
1.2.1   Public transport network and stop description
The reference data model includes entity definitions for different types of points and links as the building elements of the topological network. Stop points, timing points and route points, for instance, reflect the different roles one point may have in the network definition: whether it is used for the definition of (topological or geographical) routes, as a point served by vehicles when operating on a line, or as a location against which timing information like departure, passing, or wait times are stored in order to construct the timetables.
The line network is the fundamental infrastructure for the service offer, to be provided in the form of vehicle journeys which passengers may use for their trips. The main entities describing the line network in the reference data model are the line, the route and the journey pattern, which refer to the concepts of an identified service offer to the public, the possible variants of itineraries vehicles would follow when serving the line, and the (possibly different) successions of stop points served by the vehicles when operating on the route.
The functional views of the network are described as layers. A projection is a mechanism enabling the description of the correspondence between the different layers. This mapping between the layers is particularly useful when spatial data from different environments (sources, functional domains) have to be combined. An example of such a situation is the mapping of the public transport network on the road network. (...)

This Technical Report provides a set of examples, white papers and explanatory material that makes it easy to understand how to use and deploy all parts of NeTEx. This will help EPTIS system providers and acquirers, providing functional scope, guidelines and terminology explanations needed to implement a system. It will also ease formalizing the requirements for the context of a procurement process.

This Technical Specification specifies the physical layer of an onboard data transmission bus between the different equipment for service operations and monitoring of the fleet. This applies to equipment installed on board vehicles that are operating as part of a public transport network, i.e. in operation under public service contracts. This equipment includes operation aid systems, automatic passenger information systems, fare collection systems, etc.
Equipment directly related to the safety-related functioning of the vehicle (propulsion management, brake systems, door opening systems, etc...) are excluded from the scope of this Technical Specification and are dealt with in other standardization bodies. Interfaces to such equipment or safety-critical networks can be provided through dedicated gateways.
Part 8 covers the link between equipment inside vehicles consisting of one carriage only, e.g. buses and trolleybuses, as well as a set of carriages, e.g. trams and trains.
For the described application, three communication systems are standardised under EN 13149. There is no ranking between the three communication systems.
- Parts 1, 2 and 3 describe the WORLDFIP communication system;
- Parts 4, 5 and 6 describe the CANopen communication system;
- Parts 7, 8 and 9 describe the IP-based communication system.
Part 7  of the 13149 series specifies the Network and System Architecture for onboard equipment. It describes basic principles of communications including a general description of the network topology, addresses schematics, basic network services, a system overview and basic device architecture.
Part 8 of the 13149 series specifies the Physical Layer for IP-communication networks onboard PT vehicles. This part specifies the cables, connectors and other equipment including pin assignment and environmental requirements.
Part 9  of the 13149 series specifies in detail the Profiles of basic and generic Services and Devices as well as profiles of specific services and devices.
This part 8-1 specifies wired communication networks onboard PT vehicles which are based on the Ethernet specification IEEE 802.3 — 10 Base T and 100 Base Tx.

ISO/TR 24014-2:2013 introduces a generic conceptual framework that can be applied to all Interoperable Fare Management Systems (IFMS) compliant with ISO 24014-1, as the basis for business practices relating to the conceptual framework for an IFMS, which is described in ISO 24014-1.
This generic conceptual framework comprises three parts:
structure of Set of Rules;
collaboration of functional models;
integration of Set of Rules.

ISO/TR 24014-3:2013 describes how to implement Interoperable Fare Management (IFM) applications in a multi-application environment, and the additional roles and use cases that appear.

This Technical Report is based on work undertaken to define the scope for a possible Technical Specification that would specify the information needed by blind and visually impaired people (VIP) when they are travelling. This information is primarily intended for users of road-based transport like buses, trolleybuses and trams, but it can also be used for subway, regional and inter-city trains.
The Technical Specification that is suggested would aim to define the contents of the information required at an urban or regional level. Its goal would be to make consistent information for VIP who are travelling anywhere in Europe. It would define the nature and the structure of the information for VIP using public transport to make it familiar, homogeneous and consistent.
The Technical Specification would be applicable to organisations and operators of facilities for Public Transport and related services, either urban or regional, who want to guarantee accessibility for all and comply with local laws and recommendations in that field. The suggested Technical Specification should comply with relevant laws and recommendations throughout European countries.
Such a Technical Specification should define the information and remotely controlled functions that should be available for VIPs at stops, platforms, access areas and inside/outside vehicles. The provision and the updating of the available information would be undertaken by the Public Transport operators or their partners. It would have to be linked with existing information and management systems.
A Technical Specification would identify the contents of the information, the events, the validity time periods and the information which should be offered by different classes of end-user devices.
The Technical Specification would state which information is to be provided by each one of the different classes of end-user devices.
Traveller information for Visually Impaired People is defined in a three layer top-down framework:
1.   Contents of the information: this should be in accordance with relevant standards and other Technical Specifications (Transmodel, IFOPT, SIRI, TPEG, etc.) to achieve consistency of end-user information. All information has to be defined (including events for triggering, devices on which the information is presented and validity time periods). This will be based on use-cases;
2.   Messaging and Dialogues: this part of the processing would have to comply with existing standards and Technical Specifications SIRI, TPEG, etc. to allow interoperability;
3.   Hardware or physical media: this would define how to implement the messaging system specified above with different technical solutions to assure delivery of traveller information to the end-user. This could include collaboration with ETSI (layer for radio-communication).
The work to develop such a Technical Specification may identify additional information elements that need to be added to existing standards and Technical Specifications.
It is suggested that the first part of the Technical Specification should encompass only the first upper layer “Contents of the information” – and it is on this layer that this report concentrates.
A trip from one location to another location, often described as “door to door” (PLACE to PLACE), of a VIP involves going through several steps and phases (using various transport modes). The Technical Specification would define the information linked to each step and area crossed during a trip of a VIP. It would also define the information supply-chain for the VIP’s traveller information and the updates needed. It would have to be based on the elements and objects which are described in Transmodel and/or IFOPT.
The Technical Specification would need to take into account:
- the various transport modes used during a PLACE to PLACE trip,
- the information needed at each step in the PLACE to PLACE trip,
- the different classes of end-user devices,
(...)

This standard applies to different IVMS systems mounted in public transport vehicles, like e.g. buses, tramways, trolleybuses, and specifies the installation location, dimensions, characteristics of the sign system, information contents and cabling.
At present there are several technologies for these kinds of IVMS (e.g. LCD, LED, VFD etc.)

This Technical Specification defines a schema for establishing an Open API for Distributed Journey Planning that can be implemented by any local, regional or national journey planning system in order to exchange journey planning information with any other participating local, regional or national journey planning system.

SIRI uses a consistent set of general communication protocols to exchange information between client and server. The same pattern of message exchange may be used to implement different specific functional interfaces as sets of concrete message content types.
Two well-known specific patterns of client server interaction are used for data exchange in SIRI: Request/Response and Publish/Subscribe.
—   Request/Response allows for the ad hoc exchange of data on demand from the client.
—   Publish/Subscribe allows for the repeated asynchronous push of notifications and data to distribute events and Situations detected by a Real-time Service.
The use of the Publish/Subscribe pattern of interaction follows that described in the Publish-Subscribe Notification for Web Services (WS-PubSub) specification, and as far as possible, SIRI uses the same separation of concerns and common terminology for publish/subscribe concepts and interfaces as used in WS-PubSub. WS-PubSub breaks down the server part of the Publish/Subscribe pattern into a number of separate named roles and interfaces (for example, Subscriber, Publisher, Notification Producer, and Notification Consumer): in an actual SIRI implementation, certain of these distinct interfaces may be combined and provided by a single entity. Although SIRI is not currently implemented as a full WS-PubSub web service, the use of a WS-PubSub architecture makes this straightforward to do in future.
Publish/Subscribe will not normally be used to support large numbers of end user devices.
For the delivery of data in responses (to both requests and subscriptions), SIRI supports two common patterns of message exchange, as realised in existent national systems:
—   A one step ‘Direct Delivery’, as per the classic client-server paradigm, and normal WS-PubSub publish subscribe usage; and;
—   A two-step ‘Fetched Delivery’ which elaborates the delivery of messages into a sequence of successive messages pairs to first notify the client, and then to send the data when the client is ready. Fetched Delivery is a stateful pattern in its own right.
Each delivery pattern allows different trade-offs for implementation efficiency to be made as appropriate for different target environments.
A SIRI implementation may support either or both delivery methods; in order to make the most efficient use of the available computational and communication resources. The delivery method may either be preconfigured and static for a given implementation, or each request or subscription may indicate the delivery method required by the client dynamically as part of the request policy, and the server may refuse a request if it does not support that method, giving an appropriate error code.
The Interaction patterns and the Delivery patterns are independent aspects of the SIRI protocol and may be used in any combination in different implementations.
For a given SIRI Functional Service type (Connection Monitoring, Stop Monitoring etc.), the message payload content is the same regardless of whether information is exchanged with a Request/Response or Publish/Subscribe pattern, or whether it is returned by Direct or Fetched Delivery.
The SIRI Publish/Subscribe Protocol prescribes particular mediation behaviour for reducing the number of notifications and the amount of network traffic arising from subscriptions.
The mediation groups the various subscriptions from a subscriber into one or more Subscriber Channels, and is able to manage notifications and updates for the aggregate.
Only partial updates to the data set since the last delivery for the subscription need to be sent.
The SIRI Communication protocols are designed to fail gracefully. Considerations for resilience and recovery are covered below.

The scope of this WI is to update CEN/TS 15531-5:2011 which describes structured incident model for disruptions to services, in terms that relate directly to the entities of other SIRI services. Incidents can then be directly linked to stops, lines, journeys, etc in two ways: as the cause of disruption or as the result of service problems.
The Incident Monitoring Service is capable of filtering on incident, service and location model attributes.
First implementations of the Situation Exchange Service have revealed a number of improvements and some minor enhancements necessary for a successful and uniform usage of the specification in the future.
The main elements out of this work item will be:
o Prepare an updated edition of the TS as a document
o Update the common XSD of SIRI parts 1-5
The new work item will consider the work of
o PT companies and IT-suppliers in Germany
o PT companies and IT-suppliers in France
o PT companies and IT-suppliers in Sweden
using Situation Exchange Service in their projects.

There are many potential ways for passenger transport operations centres to interact. The approach taken by SIRI is for an open-ended set of standard data structures, carried over a communications channel constructed using one of a small number of specific options.
Part 2 of this European Standard specifies the communications channel. Part 3 specifies a number of functional modules, based on the ‘use cases’ identified in Annex B to Part 1:
—   Production Timetable (PT): this service enables the provision of information on the planned progress of vehicles operating a specific service, identified by the vehicle time of arrival and departure at specific stops on a planned route for a particular Operational Day.
—   Estimated Timetable (ET): this service enables the provision of information on the actual progress of Vehicle Journeys operating specific service lines, detailing expected arrival and departure times at specific stops on a planned route. There will be recorded data for stops which have been passed, and predicted data for stops not yet passed. In addition the Estimated Timetable service allows Vehicle Journeys to be cancelled, added or changed.
—   Stop Timetable (ST): this service provides a stop-centric view of timetabled vehicle arrivals and departures at a designated stop. It can be used to reduce the amount of information that needs to be transmitted in real-time to stops and displays, as reference data for a Stop Monitoring Service; and provides a data feed of the static timetables.
—   Stop Monitoring (SM): this service provides a stop-centric view of vehicle arrivals and departures at a designated stop. It can be used by displays and other presentation services to provide departure board and other presentations of timetable and real-time journey information both at stops and at a distance.
—   Vehicle Monitoring (VM): this service enables the provision of information on the current location and status of a set of vehicles. It provides all the current relevant information from one AVMS relating to all vehicles fulfilling a set of selection criteria.
—   Connection Timetable (CT): this service may be used to provide information about the scheduled arrivals of a feeder vehicle to the operator of a connecting distributor service. The distributor operator can then plan how to guarantee the connection, either with the expected vehicle or a different vehicle.
—   Connection Monitoring (CM): this service is used to provide information about the expected arrival of a feeder vehicle to the operator of a connecting distributor service. The distributor operator can then manage the service to guarantee the connection, based on actual vehicle running.
—   General Message (GM): the SIRI "General Message” service is used to exchange informative messages between identified individuals in free or an arbitrary structured format. It enables messages to be sent and to be revoked. Messages are assigned validity periods in addition to the actual content.

1.1   Interfaces specified by this standard
1.1.1   Business context
Real-time information may be exchanged between a number of different organizations, or between different systems belonging to the same organization. Key interfaces include the following:
-   Between public transport vehicle control centres – generally, for fleet and network management.
-   Between a control centre and an information provision system – generally, to provide operational information for presentation to the public.
-   Between information provision systems – generally, sharing information to ensure that publicly available information is complete and comprehensive.
-   Between information provision systems – and data aggregation systems that collect and integrate data from many different sources and different types of data supplier and then distribute it onwards.
-   Between information provision systems and passenger information devices such as mobile phones, web browsers, etc.
Annex B describes the business context for SIRI in more detail.
SIRI is intended for wide scale, distributed deployment by a wide variety of installations. In such circumstances it is often not practical to upgrade all the systems at the same time. SIRI therefore includes a formal versioning system that allows for the concurrent operation of different levels at the same time and a disciplined upgrade process.
In this general framework, SIRI defines a specific set of concrete functional services. The services separate the communication protocols from the message content (‘functional services’). This allows the same functional content to be exchanged using different transport mechanisms, and different patterns of exchange. Figure 1 below shows this diagrammatically.
1.1.2   SIRI communications
SIRI provides a coherent set of functional services for exchanging data for different aspects of PT operation. A common data model, based on Transmodel 5.1, is used across all services.
A communication layer defines common procedures for the requesting and exchanging of data. Within SIRI, the same general communication protocols are used for all the different concrete functional interfaces, and specify a common infrastructure for message referencing, error handling, reset behaviour and so forth. The communications layer is defined in Part 2 of the SIRI document set.
To allow the most efficient use to be made of bandwidth and processing capacity, the SIRI communications architecture supports several different patterns of interaction. SIRI supports both request/response and publish/subscribe protocols between servers, allowing applications both to pull or to push data.
The SIRI publish/subscribe pattern of interaction follows the paradigm described in the W3C candidate standard ‘Publish-Subscribe Notification for Web Services (WS-PubSub)’. SIRI uses the same separation of concerns, and a similar terminology for Publish/Subscribe concepts as is used in WS-PubSub.
For the delivery of data in response to both requests and subscriptions, SIRI supports two common patterns of message exchange as realised in existent national systems:
-   one-step ‘direct’ delivery: allowing the simple rapid delivery of data;
-   two-step ‘fetched’ delivery: allowing a more optimised use of limited resources.
1.1.3   SIRI functional services
SIRI provides specific protocols for the following functional services, defined in Part 3 of the SIRI document set:
-   Production Timetable (PT) Service: to send daily information on the operational timetable and associated vehicle running information.
-   Estimated Timetable (ET) Service: to send real-time information on timetable, including changes based on the production service and on actual running conditions.
-   Stop Timetable (ST) Service: to provide a stop-centric view of timetabled vehicle arrivals and departures at a designated stop.
-   Stop Monitoring (SM) Service: to send real-time arrival & departure information relating to a specific stop.

This Technical Specification provides, in Clause 2, new and changed glossary items needed to define indirect fulfilment and its characteristics and to support the changes to the TAP-TSI and ERA Technical Document B5.
Clause 3 defines the layout formats used for international rail services fulfilled using the ticket on departure and print-at-home ticket methods.
Clause 4 provides the changes to ERA Technical Document B5 that are required to provide the generic indirect fulfilment framework, covering ticket on departure, print-at-home and e-ticket fulfilment methods, although the main use of the specification is expected to be for ticket on departure.
Clause 5 provides the analysis of the security requirements of indirect fulfilment, and the conclusion that no rail-specific specifications are needed.

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.

This Technical Specification specifies the choice and the general application's rules of an onboard data
transmission bus between the different equipment for service operations and monitoring of the fleet. This
applies to equipment installed onboard buses, trolley-buses and tramways only as part of a bus fleet operation.
It excludes tramways when they are operated as part of a train, subway or metro operation. This equipment
includes operation aid systems, automatic passenger information systems, fare collection systems, etc.
The equipment directly related to the safety-related functioning of the vehicle (propulsion management, brake
systems, door opening systems, etc...) are excluded from the scope of the present standard and are dealt with
in other standardisation bodies.
For the described application two bus systems are standardised. Part 1 to part 3 of EN 13149 describe the
WorldFIP bus system and part 4 to part 6 describe the CANopen bus system. There is no ranking between the
two bus systems.
The present Technical Specification covers the link between equipment inside a single vehicle. Although it
could be applied to multiple vehicles, this application is not explicitly covered by this standard.
Part 1 of EN 13149 specifies the WorldFIP-based network. This specification describes the general
architecture in terms of hierarchical layers according to the ISO reference model for Open Systems
Interconnection (OSI) specified in ISO 7498.
Part 2 of EN 13149 specifies in detail the connectors and the connector pin assignment and the cabling.
Part 3 (this Technical Specification) specifies in detail the application profiles for a simple network.

This Technical Specification specifies the choice and the general application's rules of an onboard data transmission bus between the different equipment for service operations and monitoring of the fleet. This applies to equipment installed onboard buses, trolley-buses and tramways only as part of a bus fleet operation. It excludes tramways when they are operated as part of a train, subway or metro operation. This equipment includes operation aid systems, automatic passenger information systems, fare collection systems, etc.
The equipment directly related to the safety-related functioning of the vehicle (propulsion management, brake systems, door opening systems, etc.) are excluded from the scope of the present standard and are dealt with in other standardisation bodies.
For the described application two bus systems are standardised. Part 1 to part 3 describe the WORLDFIP bus system and part 4 to part 6 describe the CANopen bus system. There is no ranking between the two bus systems.
This Technical Specification covers the link between equipment inside a single vehicle. Although it could be applied to multiple vehicles, this application is not explicitly covered by this standard.

This document specifies the choice and the general application's rules of an onboard data transmission bus between the different equipment for service operations and monitoring of the fleet. This applies to equipment installed onboard buses, trolleybuses and tramways only as part of a bus fleet operation. It excludes tramways when they are operated as part of a train, subway or metro operation. This equipment includes operation aid systems, automatic passenger information systems, fare collection systems, etc.
The equipment directly related to the safety-related functioning of the vehicle (propulsion management, brake systems, door opening systems, etc.) is excluded from the scope of the present document and are dealt with in other standardisation bodies.
For the described application two bus systems are standardised. Part 1 to part 3 describes the WORLDFIP bus system and part 4 to part 6 describes the CANopen bus system. There is no ranking between the two bus systems.
This document covers the link between equipments inside a single vehicle. Although it could be applied to multiple vehicles, this application is not explicitly covered by this document.
Part 4 of this document (this document) specifies the CANopen-based network. This specification describes the general architecture in terms of hierarchical layers according to the ISO reference model for Open Systems Interconnection (OSI) specified in ISO 7498.
Part 5 of this document specifies in detail the connectors and the connector pin assignment and the cabling.
Part 6 of this document specifies in detail the application profiles for the virtual devices in public transport

This document specifies the choice and the general application's rules of an onboard data transmission bus between the different equipment for service operations and monitoring of the fleet. This applies to equipment installed onboard buses, trolley buses and tramways only as part of a bus fleet operation. It excludes tramways when they are operated as part of a train, subway or metro operation. This equipment includes operation aid systems, automatic passenger information systems, fare collection systems, etc.
The equipment directly related to the safety-related functioning of the vehicle (propulsion management, brake systems, door opening systems, etc.) is excluded from the scope of the present document and are dealt with in other standardisation bodies.
For the described application two bus systems are standardised. Part 1 to part 3 describes the WORLDFIP bus system and part 4 to part 6 describes the CANopen bus system. There is no ranking between the two bus systems.
This document covers the link between equipment inside a single vehicle. Although it could be applied to multiple vehicles, this application is not explicitly covered by this document.
Part 4 of this document specifies the CANopen-based network. This specification describes the general architecture in terms of hierarchical layers according to the ISO reference model for Open Systems Interconnection (OSI) specified in ISO 7498.
Part 5 of this document specifies in detail the connectors and the connector pin assignment and the cabling.
Part 6 of this document specifies in detail the application profiles for the virtual devices in public transport.

The present document specifies the choice and the general application's rules of an onboard data transmission bus between the different equipment for service operations and monitoring of the fleet. This applies to equipment installed onboard buses, trolleybuses and tramways only as part of a bus fleet operation. It excludes tramways when they are operated as part of a train, subway or metro operation. The equipment includes operations aid systems, automatic passenger information systems, fare collection systems, etc....
The equipment directly related to the functioning of the vehicle (driver dashboard, engine management, brake systems, door opening systems, etc...) are excluded from the scope of the present document and are dealt with in other standardisation bodies.
Two alternative transmission buses will be accepted. This document refers to the so called WORLDFIP bus. A second set of documents will be published for the second solution (so called CAN). There is no ranking between the two solutions and the selected bus system, between the two standardised alternatives, shall be subject to an agreement between each transport operating organisation and its equipment providers.
The present document refers to the so called OSI transmission model and covers OSI layers 1,2,7, the other layers are not used in our applications.
The present document covers the link between equipment inside a single vehicle. Although it could be applied to multiple vehicles, this application is not explicitly covered by this document.
The present document is the first part of a set of standards, related to the onboard transmission bus, which will comprise, for each allowed transmission bus, the following set of documents:
a)   choice of the bus and general application's rules (EN 13149-1)
b)   cabling specifications (EN 13149-2)
c)   message's content specifications (prENV 13149-3)